On Tue, 01.03.11 15:26, Pablo Hess (natunobi...@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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
