[systemd-devel] System units packaging and rpmlint

[David Strauss]

I'm skipping to the questions I can answer.

On Sat, May 18, 2013 at 2:44 PM, Michael Scherer <misc at zarb.org> wrote:
> - we should avoid as much as possible to use Type=forking when we can
> avoid it.
>
> This one is likely the one that will be met with resistance from
> packagers, so before adding it as warning, I would like to be sure that
> I am not totally wrong.
>
> A standard daemon will fork ( likely twice ) in the background,  do
> various stuff and then write the pidfile on /run.
>
> By not going in the background, we can :
> - avoid forking 1 or 2 times for nothing,
> - avoid taking memory for /run, and avoid taking a inode
>
> So that's should be a little bit better in most case, or do I miss
> anything ?
> ( ie, something like "this is so negligible that we shouldn't care" )

That's not correct. Doing Type=simple services is generally
undesirable because they lack proper support for dependent units only
starting after startup completes (versus when startup begins, which is
all systemd knows about a Type=simple unit). Type=notify is the most
desirable because it gives the benefits you list for Type=simple but
still allows proper dependency effects. However, Type=notify requires
use of systemd APIs from the daemon's own code.

If a service is socket-activiated, though, dependencies on the service
itself are generally unnecessary, as units can depend on the socket
instead. In such situations, Type=simple is quite good, with
Type=notify offering almost only academic advantages over Type=simple.

> - if using Type=forking, it is better to use PIDFile,
> While systemd seems to support fine to guess the main pid, I think this
> should be avoided when possible , according to
> http://lists.freedesktop.org/archives/systemd-devel/2011-June/002690.html .
> So does it make sense to send a warning if there is a service that do
> not use PIDFile and of type Forking ?

Absolutely. While the guessing behavior is solid, any packager should
be able to set this explicitly.

> - 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 ?

No, the systemd ideal is that packages should not ever install systemd
units or settings into /etc. Lennart's long-term goal is for daemons
to not install anything by default to /etc, but I think our scope of
authority in this discussion ends with systemd-related matters.

> IE, is this right to make a warning or a error when that occurs ?

It should be an error.

> 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.

It should be possible to invoke something in systemd to sanity-check
the included unit files.

Is it okay if the Python invokes a subprocess? If not, I work to add
unit file sanity checking to the C APIs and extend our Python
bindings.

> I didn't found any way to reuse systemd code, but I think that a tool
> like desktop-file-validate would be quite useful for all distributions.

Agreed.

--
David Strauss
   | david at davidstrauss.net
   | +1 512 577 5827 [mobile]