[systemd-devel] System units packaging and rpmlint

[Mathieu Bridon]

On Sun, 2013-05-19 at 11:21 +0200, Michael Scherer wrote:
> Le samedi 18 mai 2013 à 23:50 -0700, David Strauss a écrit :
> > 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.
[... snip ...]
> > That's not correct. Doing Type=simple services is generally
> > undesirable because they lack proper support for dependent units only
> > starting after startup completes
[... snip ...]
> In this case, that's Type=simple vs Type=forking. IE, is Type=forking
> better in term of having the startup being complete in the general
> case ? ( of course, there is always exception, but  ).
> 
> Type=notify is better, but that requires patching daemon.
> 
> However, I could check if the binary is linked with libsystemd-daemon
> and trigger a warning for using Type=notify.
> 
> > 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.
> 
> Socket activated is another beast, and I do not know how I can check if
> a binary can be socket activated to trigger a warning.

It's not really another beast in fact, it's all quite related.

What David was trying to say is that depending on the service type,
systemd will wait for a specific event to consider the service as
"started", and proceed with the units ordered after it.

For a Type=forking service, systemd will consider that the service is
started as soon as the parent process exits. That's the signal for "this
service is now running and ready to handle requests, other services
which need it can be started.

For a Type=dbus service, that signal is that the BusName=org.foo.bar
appeared on the Bus.

For a Type=notify service, that signal is that the service notified
systemd.

For a Type=simple service, there is no such signal, systemd starts the
service and considers it ready right away, which can cause trouble if
the service takes a long time to be actually ready.

That's why Type=simple is generally not desirable, unless the service
happens to be socket-activated.

So I don't think you can have such a binary "forking vs simple" point of
view. The actual task that is provided by the service needs to be taken
into account, as well as how long it takes to be ready, do other
services need it, etc...

> > > - 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.
> 
> For /etc, yes, that's planned.
> 
> But as said in the thread, my issue is :
> 
> A package ship /usr/lib/systemd/system/foo.wants/bar.service as a link
> to /usr/lib/systemd/system/bar.service
> 
> instead of using WantedBy=bar.service 
> 
> Is there one technical reason to prefer the former to the latter ?
> I would be tempted to mandate to use WantedBy because that would be more
> consistant with most packages, and hardcoding that setting on the FS
> forbid to override it in /etc, but maybe that's the goal. 

Exactly.

Some units really shouldn't ever be disabled, and as such they are valid
candidates for installing directly
a /usr/lib/systemd/system/foo.wants/bar.unit


-- 
Mathieu