[systemd-devel] user units and system units behavior

[Alison Chaiken]

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 "user at 1000.service" 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 at fedora21]$ sudo systemctl status -l user at 1000.service
● user at 1000.service - User Manager for UID 1000
   Loaded: loaded (/usr/lib/systemd/system/user at .service; static;
vendor preset: disabled)
   Active: inactive (dead)

[achaiken at fedora21]$ sudo systemctl enable user at 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 at fedora21]$ sudo systemctl start user at 1000.service
[achaiken at 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 user at 1000.service' 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                           alison at she-devel.com
650-279-5600                            http://{she-devel.com,
exerciseforthereader.org}
Never underestimate the cleverness of advertisers, or mischief makers,
or criminals.  -- Don Norman