[systemd-devel] User systemd unit files

[Chris Morgan]

On Wed, Oct 22, 2014 at 12:20 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Thu, 11.09.14 07:07, Chris Morgan (chmorgan at gmail.com) wrote:
>
>> Hmm. I figured that the environment was used when the systemd user
>> instance was started.
>>
>> I tried systemctl --user set-environment and it shows up if I use
>> show-environment but even if I use SYSTEMD_UNIT_PATH (I was typing on
>> mobile and mistakenly typed USER instead of UNIT), and reloaded the
>> daemon it doesn't appear to be taking effect, the test unit file I
>> created isn't located.
>
> SYSTEMD_UNIT_PATH should still work. You have to specify it in the
> user at .service template unit file, then reload the daemon and restart
> that service. Otherwise it will not take effect. Make sure to then
> check if it is properly set by looking at /proc/$PID/environ for the
> systemd user instance.
>
> That all said, for testing purposes systemd-nspawn is probably the
> much better idea. I mean, we wrote it only for the purpose of
> testing...
>
> Lennart
>
> --
> Lennart Poettering, Red Hat


I ended up getting pretty much everything working.

Right now we are using the same service files on desktop as on
embedded (albeit they are being partially generated by cmake's
configure_file() macro)

To recap, on the desktop we:
- Generate service files from blah.service.in files during the build,
this lets us put in hardcoded paths etc for things that need them.
- Run a script that uses 'systemctl link' to link to the users systemd folder
- Run another script to start the services

On embedded side we:
- Generate the service files...
- Run the normal 'systemctl enable xxx'
- Let the system start the services up at boot time.


The only wrinkle I've run into is that the version of systemd on f20
is old and doesn't appear to support things like 'systemctl start
company*', so we have to iterate through a manually built list of
service names. I'm hoping f21 resolves this.

Chris