<div dir="ltr">Have you looked into using sd_notify to update MAINPID? </div><div class="gmail_extra"> <div><div dir="ltr"><div> </div>-- Кирилл Елагин</div></div> <div class="gmail_quote">On Mon, May 5, 2014 at 1:19 AM, Gerd v. Egidy <<a href="mailto:lists@egidy.de" target="_blank">lists@egidy.de</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi, I'm one of the developers of the Icinga monitoring system. We want to provide a .service file for our monitoring daemon with the next major release (Icinga 2). Due to technical reasons, the daemon can't reload it's configuration files within one process. So we implement reload like this: 1. daemon process detects a SIGHUP or reload request on a control channel 2. a new process is forked & execed with a special commandline argument indicating a reload 3. the old daemon continues it's normal work 4. the new process loads and checks the configuration (this can be time consuming) 5. a) on config errors the new process terminates. the old daemon detects the SIGCHLD, logs error messages and so on 5. b) when the config is ok the new process sends a SIGTERM to the old daemon 6. the old daemon shuts down due to the SIGTERM 7. the new process detects when the old daemon is gone, activates it's config and starts it's work This is much better than a regular restart: a) the time consuming config check is done in background b) service is not interrupted if the new config is invalid But this scheme seems not to work well with systemd: After reload systemd thinks the daemon has ended and declares the whole service "inactive (dead)", usually killing the remaining daemon. After diving into the systemd manpages and trying some options, I found that I could make it work with GuessMainPID=no: [Unit] Description=Icinga host/service/network monitoring system After=syslog.target postgresql.service mariadb.service [Service] Type=forking EnvironmentFile=/etc/sysconfig/icinga2 ExecStart=/usr/sbin/icinga2 -c ${ICINGA2_CONFIG_FILE} -d -e ${ICINGA2_ERROR_LOG} -u ${ICINGA2_USER} -g ${ICINGA2_GROUP} ExecReload=/bin/sh -c '/bin/kill -HUP `cat ${ICINGA2_STATE_DIR}/run/icinga2/icinga2.pid`' GuessMainPID=no [Install] WantedBy=multi-user.target Systemd seems to successfully detect the daemon pids and some short tests with systemd-208-16.fc20.x86_64 were successful. But I'm not sure about the downsides of GuessMainPID=no or if there are some problems with older versions of systemd or if future changes in systemd will pose problems. Can you describe the downsides of GuessMainPID=no more specific than "failure detection and automatic restarting of a service will not work reliably"? Can you recommend a better alternative for the reload scheme outlined above? I'd prefer if I could tell systemd about the pidfile. Systemd should then either automatically detect updates of the pidfile (e.g. via inotify) or at least re-read it if it thinks the service has changed state. Kind regards, Gerd _______________________________________________ systemd-devel mailing list <a href="mailto:systemd-devel@lists.freedesktop.org">systemd-devel@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/systemd-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/systemd-devel</a> </blockquote></div> </div>