On Mon, 17.06.13 19:50, Jean-Marc Pigeon (jmp@xxxxxxx) 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
