All of lore.kernel.org
 help / color / mirror / Atom feed
* multipathd.init
@ 2005-04-01 20:40 Alasdair G Kergon
  2005-04-01 21:09 ` multipathd.init christophe varoqui
  0 siblings, 1 reply; 15+ messages in thread
From: Alasdair G Kergon @ 2005-04-01 20:40 UTC (permalink / raw)
  To: device-mapper development

[-- Attachment #1: Type: text/plain, Size: 1587 bytes --]

Attached is a cleaned-up version of multipathd init script - at least 
for Red Hat based systems.

While it uses the standard daemon-handling functions, it's still only 
suitable for a few situations though.

If you have / on dm-multipath, the daemon has to be started from
the initrd - so you don't want it stopping/starting from init.d,
but you might want to HUP it.

If you have other system parts of your filesystem (e.g. /usr) you 
want the daemon starting from rc.sysinit.

If you have data filesystems over multipath, you want something
to mount them after multipathd starts.

And you might also have cryptsetup, md, lvm2, kpartx involved
- in various combinations...

So you could have a multi-level startup with multiple instances
of multipathd each configured to manage only a subset of devices.
Then the init.d multipathd script would only kill the daemon
instance started during by the init.d script, and would leave
alone the instances managing / and /usr.

Or you could forget completely about init.d and /var/lock/subsys
and /var/run and just launch the daemon from the initrd or
failing that from rc.sysinit.

Then you would need a new mechanism to manage it.
(ie a dedicated client program that communicates with it e.g. via
shared memory)
I anticipate that something like this is the right way to go.

That client program could even be 'dmsetup' if the daemon functionality
could be incorporated into plug-ins: The various types of mirroring 
have similar requirements, so it's sensible to have a single
daemon infrastructure for them all.

Alasdair
-- 
agk@redhat.com

[-- Attachment #2: multipathd --]
[-- Type: text/plain, Size: 1196 bytes --]

#!/bin/bash

#
#	/etc/rc.d/init.d/multipathd
#
# Starts the multipath daemon
#
# chkconfig: 2345 13 87
# description: Manage device-mapper multipath devices
# processname: multipathd

DAEMON=/sbin/multipathd
prog=`basename $DAEMON`
initdir=/etc/rc.d/init.d
lockdir=/var/lock/subsys
sysconfig=/etc/sysconfig

 
system=redhat
 
if [ $system = redhat ]; then
	# Source function library.
	. $initdir/functions
fi
 
test -x $DAEMON || exit 0
test -r $sysconfig/$prog && . $sysconfig/$prog

RETVAL=0

#
# See how we were called.
#

start() {
	echo -n $"Starting $prog daemon: "
	daemon $DAEMON
	RETVAL=$?
	[ $RETVAL -eq 0 ] && touch $lockdir/$prog
	echo
}

stop() {
	echo -n $"Stopping $prog daemon: "
	killproc $DAEMON
	RETVAL=$?
	[ $RETVAL -eq 0 ] && rm -f $lockdir/$prog
	echo
}

restart() {
	stop
	start
}	

reload() {
	echo -n "Reloading $prog: "
	trap "" SIGHUP
	killproc $DAEMON -HUP
	RETVAL=$?
	echo
}	

case "$1" in
start)
	start
	;;
stop)
	stop
	;;
reload)
	reload
	;;
restart)
	restart
	;;
condrestart)
	if [ -f $lockdir/$prog ]; then
	    restart
	fi
	;;
status)
	status $prog
	RETVAL=$?
	;;
*)
	echo $"Usage: $0 {start|stop|status|restart|condrestart|reload}"
	RETVAL=1
esac

exit $RETVAL

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: multipathd.init
@ 2005-04-01 21:13 Igor Feoktistov
  0 siblings, 0 replies; 15+ messages in thread
From: Igor Feoktistov @ 2005-04-01 21:13 UTC (permalink / raw)
  To: dm-devel

Does it have to be running from initrd in case of root on dm-multipath?
Would not it be sufficient just run multipath from initrd and then run
multipathd from init scripts? This is exactly what I'm doing in the lab
so far...

>From: Alasdair G Kergon <agk@redhat.com>
>To: device-mapper development <dm-devel@redhat.com>
>Mail-Followup-To: device-mapper development <dm-devel@redhat.com>
>Content-Disposition: inline
>User-Agent: Mutt/1.4.1i
>X-loop: dm-devel@redhat.com
>Subject: [dm-devel] multipathd.init
>
>Attached is a cleaned-up version of multipathd init script - at least 
>for Red Hat based systems.
>
>While it uses the standard daemon-handling functions, it's still only 
>suitable for a few situations though.
>
>If you have / on dm-multipath, the daemon has to be started from
>the initrd - so you don't want it stopping/starting from init.d,
>but you might want to HUP it.
>
>If you have other system parts of your filesystem (e.g. /usr) you 
>want the daemon starting from rc.sysinit.
>
>If you have data filesystems over multipath, you want something
>to mount them after multipathd starts.
>
>And you might also have cryptsetup, md, lvm2, kpartx involved
>- in various combinations...
>
>So you could have a multi-level startup with multiple instances
>of multipathd each configured to manage only a subset of devices.
>Then the init.d multipathd script would only kill the daemon
>instance started during by the init.d script, and would leave
>alone the instances managing / and /usr.
>
>Or you could forget completely about init.d and /var/lock/subsys
>and /var/run and just launch the daemon from the initrd or
>failing that from rc.sysinit.
>
>Then you would need a new mechanism to manage it.
>(ie a dedicated client program that communicates with it e.g. via
>shared memory)
>I anticipate that something like this is the right way to go.
>
>That client program could even be 'dmsetup' if the daemon functionality
>could be incorporated into plug-ins: The various types of mirroring 
>have similar requirements, so it's sensible to have a single
>daemon infrastructure for them all.
>
>Alasdair
>-- 
>agk@redhat.com

^ permalink raw reply	[flat|nested] 15+ messages in thread
end of thread, other threads:[~2005-04-10 19:22 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-04-01 20:40 multipathd.init Alasdair G Kergon
2005-04-01 21:09 ` multipathd.init christophe varoqui
2005-04-01 21:19   ` multipathd.init Alasdair G Kergon
2005-04-01 21:25     ` multipathd.init christophe varoqui
2005-04-03  9:43       ` multipathd.init christophe varoqui
2005-04-03 19:59         ` multipathd.init christophe varoqui
2005-04-03 20:02           ` multipathd.init christophe varoqui
2005-04-04 20:52         ` multipathd.init Alasdair G Kergon
2005-04-04 22:08           ` multipathd.init christophe varoqui
2005-04-04 21:15         ` multipathd.init Alasdair G Kergon
2005-04-04 22:14           ` multipathd.init christophe varoqui
2005-04-04 23:06             ` multipathd.init christophe varoqui
2005-04-10 19:22           ` multipathd.init Lars Marowsky-Bree
2005-04-10 19:22     ` multipathd.init Lars Marowsky-Bree
  -- strict thread matches above, loose matches on Subject: below --
2005-04-01 21:13 multipathd.init Igor Feoktistov

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.