[systemd-devel] Service unit file submission: fcron.service

[Lennart Poettering]

On Tue, 01.03.11 15:26, Pablo Hess (natunobilis at gentoobr.org) wrote:
> [Unit]
> Description=fcron Cron Daemon
> Wants=syslog.target

Wants? I'd guess fcron works fine if syslog is not around, right? Hence
Wants= is not really necessary. However, you want to make sure that
fcron is started after the syslog socket is created, hence After= is
necessary in any case. (Note that in systemd ordering deps (i.e. After=
and Before=) are completely ortogonal to requirement dependencies
(i.e. Wants= und Requires=) -- the latter does not imply any of the
former, and vice versa.)

> [Service]
> Type=forking

If possibly use Type=simple if you can configure a command line that
makes fcron not fork. This is much nicer than relying on services to
fork themselves. The forking mode is a useful tool only if there are
other sevices which rely on this one to be up to do their work, for
example since they talk to your daemon via some socket. However, I
don't think this applies to fcron: hence Type=simple.

> ExecStart=/usr/sbin/fcron
> ExecReload=/bin/kill -USR1 $MAINPID

I am not a particular fan of sending signals for stuff like reload,
since it is inherently asynchronous: i.e. ideally we want to be able to
rely that when a user calls "systemctl reload fcron.service" that the
moment this call returns the reload is complete. However, if you send a
signal it is just enqueued and the command returns immediately.

Some daemons do not have a synchronous way to trigger a reload. In this
case sending a signal is acceptable. Howeever, if there is some kind of
synchronous interface, please use that and don't use signals.

> ExecStop=/bin/kill -TERM $MAINPID

Similar problems here. On top of that systemd will actually kill all the
services processes anyway with SIGTERM, so you can just drop this line
completely and just rely on systemd doing what is necessary.

Otherwise looks good!

Please submit this to fcron upstream, and have a look in daemon(7) which
explains how to integrate service file installation best with a
project's build system. We have a strong interest in getting changes
like this into the upsgtream packages, so that they are useful for all
distributions.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.