[Buildroot] Package Support with systemd (LIBFOO_INSTALL_INIT_SYSTEMD)

[Buildroot] Package Support with systemd (LIBFOO_INSTALL_INIT_SYSTEMD)

[James Knight]

Recent work I'm doing consists of building a target which uses
systemd. I've been cleaning up my target's file system; the specific
cleanup I want to mention is the location of my services and startup
(*-wants) locations. Some packages appear to install an
example/provided systemd service file into the "/etc/systemd/system/"
or configure automatic startup under a "/etc/systemd/system/*.wants/"
folder. Is there a reason why the /etc root path is being used instead
of /usr/lib (or /lib)?

From what I know, systemd will look up system services, targets and
more under the following paths:
 - /etc/systemd/system/*
 - /run/systemd/system/*
 - /usr/lib/systemd/system/*
 - /lib/systemd/system/*

(see http://www.freedesktop.org/software/systemd/man/systemd.unit.html)

On the manual page it notes that the /etc root location is for "local
configuration" versus "installed packages". Doesn't it make sense for
built target's to use a lib folder than the etc folder? This would
allow, on a persistable system, a user to "easily" override a built
target's services (without having to worry about saving the original;
ignoring any restriction the builder may want to impose). I would
imagine the following would be better approach:

```
$(INSTALL) -D -m 644 package/<package>/<package>.service \
$(TARGET_DIR)/usr/lib/systemd/system/<package>.service
mkdir -p $(TARGET_DIR)/usr/lib/systemd/system/multi-user.target.wants
ln -fs ../../../../usr/lib/systemd/system/<package>.service \
$(TARGET_DIR)/usr/lib/systemd/system/multi-user.target.wants/<package>.service
```

Examples]
 ntp installs service and auto-start into etc:
  http://git.buildroot.net/buildroot/tree/package/ntp/ntp.mk

 postgresql installs into lib and auto-start into etc:
  http://git.buildroot.net/buildroot/tree/package/postgresql/postgresql.mk

 new packages configuring auto-start into etc:
  https://patchwork.ozlabs.org/patch/475859/

ps>
I would have even suggested using the "/lib/systemd/system/" location
over "/usr/lib/systemd/system/" but I don't see any mention of the
path in the manual (although I do see the path used in systemd code
and the default install location of basic services/targets right now
is "/lib/systemd/system").

[Buildroot] Package Support with systemd (LIBFOO_INSTALL_INIT_SYSTEMD)

[Mike Williams]

James,

On Thu, May 28, 2015 at 1:56 PM, James Knight
<james.knight@rockwellcollins.com> wrote:
> Recent work I'm doing consists of building a target which uses
> systemd. I've been cleaning up my target's file system; the specific
> cleanup I want to mention is the location of my services and startup
> (*-wants) locations. Some packages appear to install an
> example/provided systemd service file into the "/etc/systemd/system/"
> or configure automatic startup under a "/etc/systemd/system/*.wants/"
> folder. Is there a reason why the /etc root path is being used instead
> of /usr/lib (or /lib)?

Putting services in /etc and /lib is probably just a result of
historical ambiguity over the correct path; there weren't really any
rules about where to place service files before. If you look through
the commit logs you'll see myself and others moving services a few at
a time to /usr/lib/systemd/system. buildroot's systemd itself has
flip-flopped from /usr/lib to /lib back and forth a few times as well.

I thought /lib was in theory only supported for systems that still
maintain an unmerged /usr (only Debian+derivatives now?), see here:
https://wiki.freedesktop.org/www/Software/systemd/TheCaseForTheUsrMerge/

Personally, I would like buildroot to merge those directories in the
base skeleton, as it would track what all distros seem headed towards,
but I don't know enough about other use cases to recommend it
categorically.

>
> From what I know, systemd will look up system services, targets and
> more under the following paths:
>  - /etc/systemd/system/*
>  - /run/systemd/system/*
>  - /usr/lib/systemd/system/*
>  - /lib/systemd/system/*
>
> (see http://www.freedesktop.org/software/systemd/man/systemd.unit.html)
>
> On the manual page it notes that the /etc root location is for "local
> configuration" versus "installed packages". Doesn't it make sense for
> built target's to use a lib folder than the etc folder? This would
> allow, on a persistable system, a user to "easily" override a built
> target's services (without having to worry about saving the original;
> ignoring any restriction the builder may want to impose). I would
> imagine the following would be better approach:
>
> ```
> $(INSTALL) -D -m 644 package/<package>/<package>.service \
> $(TARGET_DIR)/usr/lib/systemd/system/<package>.service
> mkdir -p $(TARGET_DIR)/usr/lib/systemd/system/multi-user.target.wants
> ln -fs ../../../../usr/lib/systemd/system/<package>.service \
> $(TARGET_DIR)/usr/lib/systemd/system/multi-user.target.wants/<package>.service
> ```

I guess it depends on if you view buildroot's default configuration as
'local configuration' or 'installed packages'. I approached it as
default local configuration, mostly because buildroot tries to use
unmodified upstream as much as possible, so only upstream service
files (and buildroot provided .service files for packages that do not
provide their own) should go in /usr/lib/systemd/system. Same thing
for those packages that have their own .wants links, those go in /usr.
This makes it clear which parts of the filesystem are stock upstream
and which are either buildroot or user customizations. Then, buildroot
provides default local configuration in /etc enabling services, along
with all other types of default configuration placed there.

Part of my motivation is that I basically rm -rf output/target/etc
before copying my fs-overlay/etc and fs-overlay/usr. This removes all
of buildroot's default configuration and lets me place my own in both
dirs. It's easier to do this than to keep track of which files in
/usr/lib/systemd/system have been put there by buildroot instead of
upstream, and then individually removing them in post-build.sh.

>
> Examples]
>  ntp installs service and auto-start into etc:
>   http://git.buildroot.net/buildroot/tree/package/ntp/ntp.mk
>
>  postgresql installs into lib and auto-start into etc:
>   http://git.buildroot.net/buildroot/tree/package/postgresql/postgresql.mk
>
>  new packages configuring auto-start into etc:
>   https://patchwork.ozlabs.org/patch/475859/
>
> ps>
> I would have even suggested using the "/lib/systemd/system/" location
> over "/usr/lib/systemd/system/" but I don't see any mention of the
> path in the manual (although I do see the path used in systemd code
> and the default install location of basic services/targets right now
> is "/lib/systemd/system").

Yeah, I started moving things to /usr/lib over /lib because of the man
pages, it seemed like it would make more sense to newcomers to
buildroot if their package's service files ended up where the man
pages say they should.

Mike

[Buildroot] Package Support with systemd (LIBFOO_INSTALL_INIT_SYSTEMD)

[James Knight]

Mike,

On Thu, May 28, 2015 at 3:21 PM, Mike Williams <mike@mikebwilliams.com> wrote:
> https://wiki.freedesktop.org/www/Software/systemd/TheCaseForTheUsrMerge/
>
> ...
>
> I guess it depends on if you view buildroot's default configuration as
> 'local configuration' or 'installed packages'. I approached it as
> default local configuration, mostly because buildroot tries to use
> unmodified upstream as much as possible, so only upstream service
> files (and buildroot provided .service files for packages that do not
> provide their own) should go in /usr/lib/systemd/system. Same thing
> for those packages that have their own .wants links, those go in /usr.

I guess my initial (incorrect) thoughts were that:
 /etc/systemd/system/     | Overrides
 /usr/lib/systemd/system/ | Buildroot's main playground.
 /lib/systemd/system/     | Primary systemd world.

Thanks for pointing me to the "TheCaseForTheUsrMerge" link.

> This makes it clear which parts of the filesystem are stock upstream
> and which are either buildroot or user customizations. Then, buildroot
> provides default local configuration in /etc enabling services, along
> with all other types of default configuration placed there.

For myself, the packages I want to have service definitions for I will
be moving them into my "/usr/lib/systemd/system" and
"/usr/lib/systemd/system/*-wants" locations. It makes it easier for my
own case if services are being installed to a default
"/usr/lib/systemd/system" location. I wonder though, you mention
identifying "which parts of the filesystem are stock upstream and
which are either buildroot or user customizations". If that is an
important point to follow (I assume yes), then wouldn't it be
"correct" to have any Buildroot-added service files installed to
"/etc/systemd/system/" instead?

I'm not suggesting we start transitioning stuff back to
"/etc/systemd/system/"; just curious what is the best approach long
term. I still think using the "/usr/lib/systemd/system" location is
better. I imagine it is more common for developers to want to
understand how Buildroot is assisting in service activation rather
than the service definitions themselves.

> Part of my motivation is that I basically rm -rf output/target/etc
> before copying my fs-overlay/etc and fs-overlay/usr. This removes all
> of buildroot's default configuration and lets me place my own in both
> dirs. It's easier to do this than to keep track of which files in
> /usr/lib/systemd/system have been put there by buildroot instead of
> upstream, and then individually removing them in post-build.sh.

This.

I like how you mention purging the entire 'etc' directory; I was
thinking about to do the same. As you've mentioned it, I've been
selectively tracking what files I want to remove from 'etc' rather
than just applying a desired 'etc' overlay. This lead to my initial
questions on how I could cleanup my 'etc' and what I want to move to
'usr'.