Need some advices moving a fedora package from sysVinit to systemd t

[Lennart Poettering]

On Mon, 17.06.13 19:50, Jean-Marc Pigeon (jmp at safe.ca) wrote:

> I just understood I need "Requires=" instead of "After=" as the application
> "require" the data-base daemon to be up and running in order to be
> operational.

Requirement dependencies and ordering dependencies in systemd are
orthogonal, meaning that Requires= alone has no effect on ordering, and
might result in the two services being started
simultaneously. Conversely, After= alone has no effect on requiring, and
it won't pull in any units if not conbined with Requires=.

After= alone is hence useful to order units against others without
needing that other ones to be enabled or even installed. 

> Then (to do some testing), I required "spamassassin.service
> dovecot.service bigre.service"
> sure enough "bigre.service" is unknown (as expected) and systemctl complain
> "Failed to issue method call: Unit bigre.service failed to load: No
> such file or directory"
> (as it should).
> Such I can't require a service the sysadmin don't want to use (lets
> say he want just
> use Posgresql but not want to start Mysqld at all and didn't bother to
> install it).
> So it will be nice to have a way to do "conditional require", if not,
> we are asking the
> sysadmin to "mess up" with the service definition file (which is not
> good)...

As suggested before, use After=, and that's it. Also, please read the
documentation, such as systemd.unit(5).

> >It's usually a bad idea to run systemctl from ExecStartPre= since that
> >hides dependencies. With Wants= and After= you should have all you need
> >to make these depdendencies explicit
> 
> Agreed, dependency are nicely resolved by "Requires=" directive, but while
> doing the first start config I need (at least) to restart httpd.service
> once a new WEB interface is automatically defined by application first
> start config.

You really shouldn't do stuff like that as part of the normal boot
process. Starting and then restarting things in the same boot process is
really the wrong thing to do. What exactly are you trying to do here?

> >Use Type=forking. That will cause systemd wait for the initial process
> >to exit before checking for the PID file.
> >
> Was already with Type=forking, the initial process start, initiate the
> daemon itself, starting in background (which set-up a lock file with
> its own process PID)
> once some checking is done.
> Timing are such, systemctl check for pid befor lock file is in place.
> A timer capability of some kind, would be nice?.

The parent process needs to wait until the PID file is fully written
before exiting. If it exits earlier than that things are racy, and that
not only on systemd but the same on sysv too because "service foo start
; service foo stop" might fail because the stop might not be able to
read the PID file. Please get the service in question fixed first, in
the meantime you can remove the PIDFile= setting in the unit file. That
way systemd might not be able to recognize what the main process of your
daemon is, but it should mostly work.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.