Support for systemd user services

[vilgotf]

I'm using rootless podman containers when possible (configured with podman generate systemd) and having them always run by enabling linger on my account. Transitioning to a FCOS setup using fcct was easily possible, but I'm forced to use a awkward workaround.

I use trees to import ~/.config/systemd/user and then create a service on first boot that relabels ~/ to the correct owner. My setup would be easier written using the systemd sugar in fcct if user-services were supported.

[vilgotf]

Should this be added to ignition? I see now that ignition has a "systemd" key, a "user": "<username>" value seems good

[travier]

I think this is the right place to add support. We currently have a workaround in the documentation: https://docs.fedoraproject.org/en-US/fedora-coreos/tutorial-user-systemd-unit-on-boot/

[Nemric]

Should this be added to ignition? I see now that ignition has a "systemd" key, a "user": "<username>" value seems good

The scope is too limited as systemctl enable can have more arguments
I would add in butane/systemd/units/ a "scope" or "enable_arg" key with options like system, user, runtime, or global with default to system

user won't work as is and could be a list of users ... or each created user ( butane/passwd/users/ ) could have a link to the unit ^^ up to you
Can't really say if runtime would be useful

[travier]

https://github.com/containers/quadlet > This might be of help here.

[Nemric]

thanks @travier

I came to this issue because I wanted to run ssh-agent service

[Unit]
Description=SSH key agent

[Service]
Type=simple
Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
ExecStart=/usr/bin/ssh-agent -D -a $SSH_AUTH_SOCK

[Install]
WantedBy=default.target

created in /etc/systemd/user/ssh-agent.service and enabled globaly for users sudo systemctl --global enable ssh-agent.service

It seems that your (@travier) link to quadlet doesn't handle this case ... I didn't try it before writing, you can blame me ^^

as far as I know butane (and ignition process) are creating units file in /etc/systemd/system and enable services (or not) without arguments like system, user, runtime, or global

Let me know if i'm wrong

[travier]

Indeed, looks like this does not yet support user-level systemd services. That could be a nice future feature 🙂.

[lucab]

From the IRC meeting: while this feature is eventually going to be exposed through a Butane config entry, the core logic does not need to live inside Butane as transpiler sugar.
In fact, it seems to be reasonable to directly let Ignition aware of the system/user/runtime/global "scope". That way, we don't have to fiddle with hardcoded paths here, and Ignition get some wiggle room to internally implement this as it prefers without being constrained to raw filepaths.

[dustymabe]

There seems to be some agreement and no known objections to implementing this directly in Ignition. I'll attempt to move this issue to that repository.

[dustymabe]

There seems to be some agreement and no known objections to implementing this directly in Ignition. I'll attempt to move this issue to that repository.

@Nemric @JaimeMagiera FYI ^^

[bgilbert]

The current draft implementation in #1303 only handles systemwide user units in /etc/systemd/user, and not user-specific units in ~/.config/systemd/user as originally requested by @vilgotf. It'd be possible to write systemwide units with one or more ConditionUser=|foo triggering conditions, but I'm not sure whether that meets everyone's needs. Thoughts?

[dustymabe]

My expectation was the units would be written out under ~/.config/systemd/user but let's think about this a bit more.

If they get written to /etc/systemd/user they are system-wide and would need ConditionUser=|foo (as you mention) or else they would run for all users.. They also aren't configurable any longer by the user IIUC.

If we flip that and write them to ~/.config/systemd/user then we'd need a way in the spec to specify which user we want it to apply to right?

Maybe we should support both? Add a spec entry for user and if the user specifies it write it to ~/.config/systemd/user and if they don't write it to /etc/systemd/user.

[Nemric]

I think this won't be so hard to support both, as my first need was running a user ssh-agent globally and @vilgotf wanted specific user services.

[eriksjolund]

There is a Systemd feature request for supporting ~/.config/systemd/user with a preset file

• auto-preset on firstboot is not support for --user instances systemd/systemd#16558

Maybe such a feature would be useful when implementing support for
~/.config/systemd/user in Ignition?

If I understand correctly Ignition uses preset files for the system services.

[Nemric]

It seems that units written in ~/.config/systemd/user are aware of /etc/systemd/user-preset/*.preset files
But can't really know if it works

my test :
create a user unit in ~/.config/systemd/user/sleeper.service

[Unit]
Description=A systemd user unit demo
After=network-online.target
Wants=network-online.target
[Service]
ExecStart=/usr/bin/sleep infinity
[Install]
WantedBy=multi-user.target

create /etc/systemd/user-preset/20-test.preset with
enable sleeper.service
ask systemctl
systemctl --user status sleeper

I get

○ sleeper.service - A systemd user unit demo
     Loaded: loaded (/var/home/core/.config/systemd/user/sleeper.service; disabled; vendor preset: enabled)
     Active: inactive (dead)

As you can see, vendor preset is set to enable

I assume, for developments, that it will work as expected until I can dig deeper

[bgilbert]

systemctl says the vendor preset is enabled because it sees the preset file, but that's no guarantee that systemd will actually apply that preset. You'll need to test this in an actual OS image.