On Thu, Sep 01, 2011 at 08:23:26AM +0200, Hannes Reinecke wrote: > On 09/01/2011 05:00 AM, Benjamin Marzinski wrote: >> Here is a systemd unit file for managing multipathd. >> > [ .. ] >> Index: multipath-tools-110831/multipathd/multipathd.service >> =================================================================== >> --- /dev/null >> +++ multipath-tools-110831/multipathd/multipathd.service >> @@ -0,0 +1,14 @@ >> +[Unit] >> +Description=Device-Mapper Multipath Device Controller >> +Before=iscsi.service iscsid.service >> +After=syslog.target >> + >> +[Service] >> +Type=forking >> +PIDFile=/var/run/multipathd.pid >> +ExecStart=/sbin/multipathd >> +ExecReload=/bin/kill -HUP $MAINPID >> +#ExecStop=/path/to/scrip delete-me if not necessary >> + >> +[Install] >> +WantedBy=multi-user.target >> > Hmm. First of all, I'm trying to get rid of the PID file, as with it it's > quite hard to start multipathing when /var/run isn't mounted. > Plus it's not actually needed; everything can be done via multipathd -k > nowadays. At least on fedora, The systemd people changed /var/run so that it's now just a symlink to /run, which is a tmpfs filesystem. > > So may I suggest to use > ExecReload=/sbin/multipathd -k'reconfigure' Makes sense. Sure. > here? > And do we actually need > PIDFile= > for systemd? > If not I'd rather remove that line, too. To comply with the Systemd Daemon best practices (in man systemd.service(5)), I appears so. But I don't believe that it's strictly necessary. If you don't add it, systemd will try to guess the mainpid, and since multipath multi-thread instead of multi-process, I'm pretty sure it will guess correctly. But if /var/run becomes a tmpfs, then I don't see a need to remove the pidfile. -Ben > Cheers, > > Hannes > -- > Dr. Hannes Reinecke zSeries & Storage > hare@xxxxxxx +49 911 74053 688 > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg > GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) > > -- > dm-devel mailing list > dm-devel@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/dm-devel -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
