Unit tray.target not found

[jlesquembre]

Issue description

On current master, I get the error Unit tray.target not found when I try to start some systemd units (like udiskie or blueman).
I'm using waybar, I think this error is related to #2027

Meta

Maintainer CC

@berbiche @NickHu

Technical details

[berbiche]

Unfortunately, the tray.target is only created if xsession management is enabled in HM.

The creation of said systemd target should be moved elsewhere.

In the meantime, you can create the systemd target manually from the xsession.nix? file and add Install.WantedBy = [ "graphical-session-pre.target" ] to the target definition. (untested)

[sumnerevans]

Unfortunately, the tray.target is only created if xsession management is enabled in HM.

Ah, this explains why I encountered that error on my wayland system. We should definitely fix that.

[zeorin]

I have this problem on X11. flameshot includes a service that wants the tray.target.

[vyorkin]

Can confirm the problem on X11 with flameshot, subscribed to this issue exactly for this reason

[zeorin]

@vyorkin I should probably mention that I worked around this for the time being with the following in my home.nix:

	systemd.user.targets.tray = {
		Unit = {
			Description = "Home Manager System Tray";
			Requires = [ "graphical-session-pre.target" ];
		};
	};

which I lifted from home-manager's source somewhere.

[DavHau]

Still an issue. The home-manager udiskie service doesn't work on my nixos 21.05.
I'm using i3wm on x11 and there is no tray target

[zeorin]

I've since enabled xsession management, but I'm assuming that with this change, someone that's not running sway nor xsession management will still have this issue?

[aruZeta]

What I noticed is that I can't start any service in $XDG_CONFIG_HOME/systemd/user, so services like the ones created from services.emacs or services.gpg-agent can't be started. Searching a bit I didn't find any issue directly talking about it. systemd-analyze --user unit-paths shows $XDG_CONFIG_HOME/systemd/user, which makes the fact that it can't find services there even more strange.

[AshleyYakeley]

I believe this should be reopened? I'm using marco (rather than sway) without xsession management, and I'm coming across this issue.

[ncfavier]

I can see two solutions:

• change Requires directives on tray.target to Wants instead; @NickHu is there a specific reason you used Requires?
• define the tray target in the systemd module, regardless of whether xsession or sway is enabled

[Mikilio]

Just some thought to add:

I've been trying to wrap my head around what this target is for and how it's supposed to be used for. By the description it seems like the target being active indicates that there is a system tray active. This caused a lot of confusion for me because all 3rd party bars providing a system tray out there actually start after graphical-session.target creating dependency cycles on most desktops. Then again apps that use a system tray will request the tray from the dbus, which most likely will start the bar for the tray which makes their systemd service only a backup in case dbus hasn't started them yet. As far as I understand the only requirement for tray.target to be met seems to be dbus.service and possibly (xdg-desktop-portal.service ?). Am I right so far?

[Nebucatnetzer]

Wasn't able to start network manager applet because of the missing tray.target with qtile WM.

[arduano]

Interestingly, using @zeorin's fix for flameshot, it doesn't appear in the tray even though it runs fine in the background. It appears in the tray when I run systemctl --user restart flameshot.

[Kreyren]

Doesn't seem to work on NixOS 24.05 with GNOME using wayland either.

Cross-Referencing: NiXium-org/NiXium#115

[ciferkey]

Confirming I'm seeing this on unstable now with udiskie. System info:

❯ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.10.0, NixOS, 24.11 (Vicuna), 24.11.20240719.1d9c2c9`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.5`
 - nixpkgs: `/etc/nix/path/nixpkgs`

Any other details I can provide that would help debug this?

[worthalex]

i too am encountering this issue on unstable after an update

activating the configuration...
setting up /etc...
reloading user units for alex...
restarting sysinit-reactivation.target
the following new units were started: systemd-hostnamed.socket
warning: the following units failed: home-manager-alex.service

× home-manager-alex.service - Home Manager environment for alex
     Loaded: loaded (/etc/systemd/system/home-manager-alex.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Wed 2024-07-31 10:19:55 NZST; 70ms ago
   Duration: 4min 4.193s
 Invocation: 877dc7faf55849d3981a0504b9655bdb
    Process: 136236 ExecStart=/nix/store/877sla6xf6kngfzaabmqm4r5al918h9f-hm-setup-env /nix/store/5rkb4h56ggpqddf0v3v8r6zm7s5jqgql-home-manager-generation (code=exited, status=1/FAILURE)
   Main PID: 136236 (code=exited, status=1/FAILURE)
         IP: 0B in, 0B out
   Mem peak: 35.9M
        CPU: 853ms

Jul 31 10:19:55 sage-ice-cream hm-activate-alex[136236]: Activating reloadSystemd
Jul 31 10:19:55 sage-ice-cream hm-activate-alex[136642]: Starting units: udiskie.service
Jul 31 10:19:55 sage-ice-cream hm-activate-alex[136642]: Error: Error switching
Jul 31 10:19:55 sage-ice-cream hm-activate-alex[136642]: Caused by:
Jul 31 10:19:55 sage-ice-cream hm-activate-alex[136642]:     0: Failed to perform post-reload tasks
Jul 31 10:19:55 sage-ice-cream hm-activate-alex[136642]:     1: Failed to start unit udiskie.service
Jul 31 10:19:55 sage-ice-cream hm-activate-alex[136642]:     2: org.freedesktop.systemd1.NoSuchUnit: Unit tray.target not found.
Jul 31 10:19:55 sage-ice-cream systemd[1]: home-manager-alex.service: Main process exited, code=exited, status=1/FAILURE
Jul 31 10:19:55 sage-ice-cream systemd[1]: home-manager-alex.service: Failed with result 'exit-code'.
Jul 31 10:19:55 sage-ice-cream systemd[1]: Failed to start Home Manager environment for alex.
warning: error(s) occurred while switching to the new configuration

@vyorkin I should probably mention that I worked around this for the time being with the following in my home.nix:

	systemd.user.targets.tray = {
		Unit = {
			Description = "Home Manager System Tray";
			Requires = [ "graphical-session-pre.target" ];
		};
	};

which I lifted from home-manager's source somewhere.

This fixed it