[systemd-devel] System units packaging and rpmlint

[Lennart Poettering]

On Sat, 18.05.13 23:44, Michael Scherer (misc at zarb.org) wrote:

> Hi,
> 
> After the last discussion on fedora-devel about boot times[1], I have
> been looking at the various units on my disk and if I could code
> something in rpmlint ( tool to verify a rpm against a set of guidelines
> ) to have packagers follow some best practices.

It would be fantastic to get rpmlint updated to do a a couple of systemd
unit file checks.

> So I have been writing various checks that emit Warning/Errors, and
> would like to get some feedback on a few assumption I made when writing
> the checks :
> 
> - pid file should be in /run, or in a subdirectory of /run
> I have seen a few service who still use /var/run, but can I safely
> assume that anything booting with systemd would have /run?
> (and so warn if something is using /run for that) 

Yes, systemd strictly requires /run to be around. 

> - unit file should be in %_unitdir, which is on /usr/lib for
> distribution with merged /usr ( at least, on Fedora and Mageia )

Correct.

> So I planned to warn if the unit are directly in /lib, but I know there
> is some distribution that didn't choose this path yet. So when /usr is
> not merged, what is the canonical location ( ie, for Opensuse, Mandriva,
> since they are both rpm based ) ?

I'd recommend adding a warning for all units that aren't located in
%_unitdir. 

> - we should avoid as much as possible to use Type=forking when we can
> avoid it. 

Well, the rule should be, in order of preference:

1) for bus services, please use Type=dbus and specify BusName=

2) for socket-activatable services, please use Type=simple

3) for one-shot services use Type=oneshot

4) for other services use Type=notify if they support it

5) otherwise use Type=forking, but if you do please make sure to specify
   PIDFile=, too.

I figure the only things rpmlint could check here is that Type=dbus has
BusName=, and Type=forking has PIDFile=, everything else is probably
nothing we could automatically check.

> - some package install directly file in /usr/lib/systemd/system/*.wants
> There is some special case ( like plymouth ), but usually, that
> shouldn't be done directly in the package, but better done in %post, and
> in /etc ?

Installing something into /usr/lib/systemd/system/*.wants is only OK for
very special system components, but not for normal packages. I think
it's OK to add a check for this, and then tell the Plymouth maintainers
(and similar low-level folks) to just ignore it.

> I was also interested into checking the syntax of systemd file, but
> since systemd is moving quite fast, I doubt to be able to keep a up to
> date parser of unit/service/timer/snapshot files. And duplicating code
> of systemd in python do not seems like a smart move. 

There have been requests to add a unit file validator to systemd. It
shouldn't be too hard to do that actually, simply reusing systemd's own
parsing code, instead of writing a second parser. I'd be happy to merge
a patch that adds "systemd-validate" or so, which instantiates a
throw-away Manager object (as defined by systemd's core), then tries to
load specified unit files into it, and shows all warnings, then freeing
things immediately.

Other things I'd like to see checked:

Packages should *never* install symlinks or unit files into
/etc/systemd/...

Packages should *never* install their own preset files. That's something
for fedora-release.rpm and systemd.rpm, but nobody else. (the various
display managers ended up doing this, which is really broken).

The unit files should have 644 access mode.

Packages should only install symlinks in
/usr/lib/systemd/system/*.wants/ and they should point to unit files in
/usr/lib/systemd/system/.

Service files with WantedBy=sysinit.target, WantedBy=local-fs.target or
WantedBy=basic.target should have DefaultDependencies=no.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.