[systemd-devel] System units packaging and rpmlint

[Michael Scherer]

Le samedi 18 mai 2013 à 23:50 -0700, David Strauss a écrit :
> 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.

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.

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

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

It is ok. Bonus point for a parsable output, but just having a exit code
would be ok for integration and let people run the binary and read
errors.

> If not, I work to add
> unit file sanity checking to the C APIs and extend our Python
> bindings.

I think since lintian ( a similar tool for debian package ) is in perl,
so having it in a external binary would be better for them.

Now, from a deployment point of view, desktop-file-validate was
backported on stable version for our builders at Mageia, and since the
tool was self contained, that was ok, but pulling over a complete
systemd backport on the server would likely be refused by any sysadmins,
so if the tool could be compiled as a standalone without interfering
with existing systemd installation, that would be nice. 
( if not, I guess they can use some chroot tricks as i do for others
quality checking tools )

-- 
Michael Scherer