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?