Mantas offers: > I think the idea was that the user instance would be started automatically > when the user first logged in. > > (Which it is, at least on Arch: logind starts "[email protected]" for me as > soon as pam_systemd tells it that I've logged in. > > Some distros break it, either intentionally or by accident. Not sure about > Fedora.)
On Fedora 21, I see [achaiken@fedora21]$ sudo systemctl status -l [email protected] ● [email protected] - User Manager for UID 1000 Loaded: loaded (/usr/lib/systemd/system/[email protected]; static; vendor preset: disabled) Active: inactive (dead) [achaiken@fedora21]$ sudo systemctl enable user@service The unit files have no [Install] section. They are not meant to be enabled using systemctl. Possible reasons for having this kind of units are: 1) A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory. 2) A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. 3) A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...). [achaiken@fedora21]$ sudo systemctl start [email protected] [achaiken@fedora21]$ systemctl start --user gnome-weather.service Failed to start gnome-weather.service: Process org.freedesktop.systemd1 exited with status 1 I wrote: >> In the spirit of 'systemctl cat' and >> 'systemctl edit' commands that find the applicable unit even when the >> invoker doesn't know the complete path, I would hope that non-SUID >> users could type 'systemctl start foo.service' and it would "just >> work". Mantas answers: > Not sure how that's at all related to knowing the complete path? I meant only that expecting users to know that they have to type "systemctl --user" is undesirable if it's not necessary. Mantas: > It's not broken on stock systemd. As long as your `systemd --user` instance > is running, systemctl can contact it directly over the > "$XDG_RUNTIME_DIR/systemd/private" socket, so there's no hard dependency on > on any D-Bus bus either (neither system nor session nor user). > > So if you see `systemctl --user` trying to contact systemd over the bus, it > only does so after it has given up trying to contact it over the private > socket. Does that socket exist? No, I gather that's the problem: 'ls $XDG_RUNTIME_DIR' shows no systemd sub-directory at all. > Also check if the system service "user@<your uid>.service" is active, if it > has logged any errors. Try starting that .service manually too. 'systemctl start [email protected]' shows no errors in the journal; it just seems to 'exit 0' with no lasting effects. I suppose that gnome-session is supposed to create $XDG_RUNTIME_DIR/systemd/private and for some reason, silently fails to do so. gnome-session shows no associated errors in the journal either. Thanks, Alison -- Alison Chaiken [email protected] 650-279-5600 http://{she-devel.com, exerciseforthereader.org} Never underestimate the cleverness of advertisers, or mischief makers, or criminals. -- Don Norman _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
