All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Marzinski <bmarzins@redhat.com>
To: device-mapper development <dm-devel@redhat.com>
Subject: Re: [PATCH] multipath: systemd unit file
Date: Thu, 1 Sep 2011 09:46:24 -0500	[thread overview]
Message-ID: <20110901144624.GH11793@ether.msp.redhat.com> (raw)
In-Reply-To: <4E5F24DE.50004@suse.de>

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@suse.de			      +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@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel

      parent reply	other threads:[~2011-09-01 14:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-01  3:00 [PATCH] multipath: systemd unit file Benjamin Marzinski
2011-09-01  6:23 ` Hannes Reinecke
2011-09-01  7:04   ` Christophe Varoqui
2011-09-01  7:11     ` Hannes Reinecke
2011-09-01 17:08     ` [PATCH v2] " Benjamin Marzinski
2011-09-01 14:46   ` Benjamin Marzinski [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110901144624.GH11793@ether.msp.redhat.com \
    --to=bmarzins@redhat.com \
    --cc=dm-devel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.