Re: service helper package
Great. I was hoping for this answer :) On Nov 26, 2007 5:25 PM, Raphael Geissert [EMAIL PROTECTED] wrote: On 25/11/2007, C.J. Adams-Collier [EMAIL PROTECTED] wrote: is there something like a service-common package that provides a helper script like the following for services to source? I'm thinking that it would belong somewhere like /usr/share/service-common/init.sh. I have not tested the following yet, and I'm a sucky bash programmer. Ever heard about lsb-base and /lib/lsb/init-functions? :) That's exactly what you are looking for. dh_make provides an example init.d script using the LSB init functions (but it isn't very compliant as it is now[1]) [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=450898 Regards, -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Say NO to Microsoft Office broken standard. See http://www.noooxml.org/petition -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- moo.
Re: service helper package
Hallo C.J.,
C.J. Adams-Collier [EMAIL PROTECTED] wrote:
On Mon, 2007-11-26 at 12:32 +, Jörg Sommer wrote:
C.J. Adams-Collier [EMAIL PROTECTED] wrote:
# Fully qualified paths to required programs
START_STOP_DAEMON=/sbin/start-stop-daemon
CAT=/bin/cat
ECHO=/bin/echo
Why not use echo and cat? Calling echo this way the shell can't use the
builtin echo command and must spawn a new process.
Is there a test to determine whether there is a builtin for a given
command?
Try to call it with the prefix builtin and test if it fails.
% builtin echo
% builtin ls
zsh: no such builtin: ls
if [ -z $SERVICE_NAME ] || \
[ -z $SERVICE_DESC ] || \
[ -z $SERVICE_DAEMON ]; then
fatal( Environment not configured correctly.\n\tService requires
definition of the following variables:\nSERVICE_NAME\nSERVICE_DESC\n
SERVICE_DAEMON )
fi
Why you want to test these values everytime? If the maintainer forgot
them one time, they are missing everytime.
Maybe they exist one time but get removed before the next run?
Who should remove them? They are in the init script? This looks more
like a check for lintian.
# We do not want to be affected by PATH tampering. All calls to
# external programs will be fully qualified
PATH=
You know what you are doing here? PATH is necessary for the daemon to
find subcommands.
Yep. I don't want to execute any but the fully qualified commands.
Did you really understood that your daemon can't restart itself or run
another program.
# Check whether we were configured to not start the services.
check_for_no_start() {
if [ $SERVICE_DISABLED = yes ]; then
This is such a broken behavior. Initscripts are enabled and disabled in
the configuration of the init system.
I agree... but existing scripts use such a beast,
Doing one thing often doesn't make it right. What you want is to disable
the start of the daemon. It's started by init. So tell init it shouldn't
start it. This leaves the possibilities to start it by hand via
/etc/init.d/FOO start or run it only in some run levels, e.g. in 3 but
not in 2.
Bye, Jörg.
--
“Science is the game we play with God to find out what his rules are.”
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: service helper package
On Sun, Nov 25, 2007 at 09:01:50PM -0800, C.J. Adams-Collier wrote:
is there something like a service-common package that provides a helper
script like the following for services to source?
I think the current solution is provide a template with dh_make,
which is somewhat more general since the init.sh might need to be
overhauled to be useful for some given app.
I'm thinking that it would belong somewhere like
/usr/share/service-common/init.sh. I have not tested the following yet, and
I'm a sucky bash programmer.
# Fully qualified paths to required programs
START_STOP_DAEMON=/sbin/start-stop-daemon
CAT=/bin/cat
ECHO=/bin/echo
. /etc/default/$SERVICE_NAME
In general, you'd want to test for the existance and only source it if
it's there.
# Kill me on all errors
set -e
Put this early as possible.
# If the daemon binary does not exist, report the error and exit
if [ ! -f $SERVICE_DAEMON ]; then
fatal( Service daemon, '$SERVICE_DAEMON' does not exist. )
fi
Actually, this is usually:
[ -x $DAEMON ] || exit 0
since the conffiles (such as the initscript) are present after
removing (but not purging) the package, and this keeps them from
spewing noisy errors about the daemon not starting or such.
# Make sure the RUNDIR exists with correct permissions
if [ ! -d $RUNDIR ]; then
Any reason not to include the rundir in the pacakge? Then you don't
have to manually remove it in the initscripts.
# Check whether we were configured to not start the services.
check_for_no_start() {
if [ $SERVICE_DISABLED = yes ]; then
This is probably a good idea to be generally and consistently
supported. OTOH removing the execute bit or renaming the daemon file
already works most (90%) of the time.
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: service helper package
On Mon, Nov 26, 2007 at 04:49:26AM -0500, Justin Pryzby wrote:
On Sun, Nov 25, 2007 at 09:01:50PM -0800, C.J. Adams-Collier wrote:
# Make sure the RUNDIR exists with correct permissions
if [ ! -d $RUNDIR ]; then
Any reason not to include the rundir in the pacakge? Then you don't
have to manually remove it in the initscripts.
Spot the person who has never run a system with a tmpfs /var/run. grin
# Check whether we were configured to not start the services.
check_for_no_start() {
if [ $SERVICE_DISABLED = yes ]; then
This is probably a good idea to be generally and consistently
supported. OTOH removing the execute bit or renaming the daemon file
already works most (90%) of the time.
No, this is a bad idea and should never be supported. If you don't want
something to start at boot, then shuffle the symlinks in /etc/rc?.d. If you
never want the possibility of the service being run, then remove the
package.
These disable-the-service-in-/etc/default hacks preclude the ability to
disable a service at boot but sometimes start it manually, and work around
the existing mechanisms for avoiding starting a daemon at boot time.
- Matt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: service helper package
Hallo C.J.,
C.J. Adams-Collier [EMAIL PROTECTED] wrote:
is there something like a service-common package that provides a helper
script like the following for services to source?
I'm thinking that it would belong somewhere like
/usr/share/service-common/init.sh. I have not tested the following yet, and
I'm a sucky bash programmer.
Init scripts should not use Bash, they should be Posix Shell scripts!
# Fully qualified paths to required programs
START_STOP_DAEMON=/sbin/start-stop-daemon
CAT=/bin/cat
ECHO=/bin/echo
Why not use echo and cat? Calling echo this way the shell can't use the
builtin echo command and must spawn a new process.
if [ -z $SERVICE_NAME ] || \
[ -z $SERVICE_DESC ] || \
[ -z $SERVICE_DAEMON ]; then
fatal( Environment not configured correctly.\n\tService requires
definition of the following variables:\nSERVICE_NAME\nSERVICE_DESC\n
SERVICE_DAEMON )
fi
Why you want to test these values everytime? If the maintainer forgot
them one time, they are missing everytime.
# We do not want to be affected by PATH tampering. All calls to
# external programs will be fully qualified
PATH=
You know what you are doing here? PATH is necessary for the daemon to
find subcommands.
# echo an error message and quit
fatal() {
echo - failed:
You should get familiar with LSB log function. See lsb-base.
# Check whether we were configured to not start the services.
check_for_no_start() {
if [ $SERVICE_DISABLED = yes ]; then
This is such a broken behavior. Initscripts are enabled and disabled in
the configuration of the init system.
IMO there's no need for such a script. Use /etc/init.d/skeleton as a
template and adapt it to your service.
Bye, Jörg.
--
Es liegt in der Natur des Menschen, vernünftig zu denken und
unlogisch zu handeln! Das Gesagte ist nicht das Gemeinte und das Gehörte
nicht das Verstandene!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: service helper package
This one time, at band camp, Jörg Sommer said:
Init scripts should not use Bash, they should be Posix Shell scripts!
Not strictly true. A script written for use with #!/bin/sh should use
the POSIX superset allowed by policy. A script aimed at bsah should
just declare it's interpreter as #!/bin/bash. Generally, you don't need
to do that, but you are allowed to.
# Check whether we were configured to not start the services.
check_for_no_start() {
if [ $SERVICE_DISABLED = yes ]; then
This is such a broken behavior. Initscripts are enabled and disabled in
the configuration of the init system.
That's not quite true - many packages in debian use an enable/disable
variable in an /etc/default/package file.
--
-
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
signature.asc
Description: Digital signature
interpretted scripts (Re: service helper package)
On Mon, Nov 26, 2007 at 02:13:42PM +, Stephen Gran wrote: This one time, at band camp, Jörg Sommer said: Init scripts should not use Bash, they should be Posix Shell scripts! Not strictly true. A script written for use with #!/bin/sh should use the POSIX superset allowed by policy. A script aimed at bsah should By superset of posix I guess you mean posix + echo -n. just declare it's interpreter as #!/bin/bash. Generally, you don't need its to do that, but you are allowed to. Do you mean because bash is the default sh? It's still required to declare the interpretter: | If a script requires non-POSIX features from the shell interpreter, | the appropriate shell must be specified in the first line of the | script (e.g., `#!/bin/bash') Justin
Re: interpretted scripts (Re: service helper package)
This one time, at band camp, Justin Pryzby said: On Mon, Nov 26, 2007 at 02:13:42PM +, Stephen Gran wrote: This one time, at band camp, Jörg Sommer said: Init scripts should not use Bash, they should be Posix Shell scripts! Not strictly true. A script written for use with #!/bin/sh should use the POSIX superset allowed by policy. A script aimed at bsah should By superset of posix I guess you mean posix + echo -n. IIRC policy also allows [ $this -a $that ] and [ $this -o $that ] although I might be confused in thinking those aren't POSIX. just declare it's interpreter as #!/bin/bash. Generally, you don't need to do that, but you are allowed to. Do you mean because bash is the default sh? No, I mean that bash specific features are not generally necessary in writing something as simple as an init script. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: service helper package
Stephen Gran wrote:
# Check whether we were configured to not start the services.
check_for_no_start() {
if [ $SERVICE_DISABLED = yes ]; then
This is such a broken behavior. Initscripts are enabled and disabled in
the configuration of the init system.
That's not quite true - many packages in debian use an enable/disable
variable in an /etc/default/package file.
Not talking about any policy, but I personally hate it. Why on earth
would you want to have a package NOT to work if you install it? This is
insane...
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: interpretted scripts (Re: service helper package)
On Mon, Nov 26, 2007 at 03:53:33PM +, Stephen Gran wrote: This one time, at band camp, Justin Pryzby said: On Mon, Nov 26, 2007 at 02:13:42PM +, Stephen Gran wrote: This one time, at band camp, Jörg Sommer said: Init scripts should not use Bash, they should be Posix Shell scripts! Not strictly true. A script written for use with #!/bin/sh should use the POSIX superset allowed by policy. A script aimed at bsah should By superset of posix I guess you mean posix + echo -n. IIRC policy also allows [ $this -a $that ] and [ $this -o $that ] although I might be confused in thinking those aren't POSIX. -a and -o are XSI which AIUI is an (very common) extension of posix (see standards.7). dash allows them but posh does not. just declare it's interpreter as #!/bin/bash. Generally, you don't need to do that, but you are allowed to. Do you mean because bash is the default sh? No, I mean that bash specific features are not generally necessary in Ah, ok; I didn't think that could be right :) Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: service helper package
Stephen Gran wrote: This one time, at band camp, Jörg Sommer said: Init scripts should not use Bash, they should be Posix Shell scripts! Not strictly true. A script written for use with #!/bin/sh should use the POSIX superset allowed by policy. A script aimed at bsah should just declare it's interpreter as #!/bin/bash. Generally, you don't need to do that, but you are allowed to. Just bear in mind that packages using such scripts will generate bug reports if/when someone needs to use the package on a low resource or embedded system where bash is not available. Yes, you are allowed to use #!/bin/bash but, IMHO, it is unwise to do so unless the package itself depends on bash (pre-depends if in preinst) or is directly related to bash in some other way. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: OpenPGP digital signature
Re: service helper package
On Tue, 27 Nov 2007 01:47:31 +0800 Thomas Goirand [EMAIL PROTECTED] wrote: Stephen Gran wrote: That's not quite true - many packages in debian use an enable/disable variable in an /etc/default/package file. Not talking about any policy, but I personally hate it. Why on earth would you want to have a package NOT to work if you install it? This is insane... Disabled != not-working Haven't you had to disable a service for testing purposes or whatever? Or when comparing similar services . . . -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpyk9WI14NQ3.pgp Description: PGP signature
Re: service helper package
Hi,
Thomas Goirand wrote:
Stephen Gran wrote:
# Check whether we were configured to not start the services.
check_for_no_start() {
if [ $SERVICE_DISABLED = yes ]; then
This is such a broken behavior. Initscripts are enabled and disabled in
the configuration of the init system.
That's not quite true - many packages in debian use an enable/disable
variable in an /etc/default/package file.
Not talking about any policy, but I personally hate it. Why on earth
would you want to have a package NOT to work if you install it? This is
insane...
You might want to disable _temporarily_ a certain application? It's
easier/quicker than to reconfigure the init system and you don't loose
the information about run-levels where the program is meant to start.
Eric
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: service helper package
On Tue, 2007-11-27 at 01:47 +0800, Thomas Goirand wrote:
Stephen Gran wrote:
# Check whether we were configured to not start the services.
check_for_no_start() {
if [ $SERVICE_DISABLED = yes ]; then
This is such a broken behavior. Initscripts are enabled and disabled in
the configuration of the init system.
That's not quite true - many packages in debian use an enable/disable
variable in an /etc/default/package file.
Not talking about any policy, but I personally hate it. Why on earth
would you want to have a package NOT to work if you install it? This is
insane...
Thomas
This tends to be used for packages that cannot provide a reasonable
default configuration, and would need to be hand edited before
activating the service.
--
David Watson - Debian GNU/Linux Developer
[EMAIL PROTECTED], [EMAIL PROTECTED]
Jabber: [EMAIL PROTECTED]
Web: http://planetwatson.co.uk/blog
signature.asc
Description: This is a digitally signed message part
Re: service helper package
On Tue, 27 Nov 2007, Thomas Goirand wrote:
Stephen Gran wrote:
# Check whether we were configured to not start the services.
check_for_no_start() {
if [ $SERVICE_DISABLED = yes ]; then
This is such a broken behavior. Initscripts are enabled and disabled in
the configuration of the init system.
That's not quite true - many packages in debian use an enable/disable
variable in an /etc/default/package file.
Not talking about any policy, but I personally hate it. Why on earth
would you want to have a package NOT to work if you install it? This is
insane...
Because there are some times when a package works just fine without a
daemon running.
As a trivial example, see spamassassin.
That said, unless you have a really good reason the init script should
be enabled by default.
Don Armstrong
--
Clothes make the man. Naked people have little or no influence on
society.
-- Mark Twain
http://www.donarmstrong.com http://rzlab.ucr.edu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: service helper package
On Mon, 2007-11-26 at 12:32 +, Jörg Sommer wrote:
Hallo C.J.,
C.J. Adams-Collier [EMAIL PROTECTED] wrote:
is there something like a service-common package that provides a helper
script like the following for services to source?
I'm thinking that it would belong somewhere like
/usr/share/service-common/init.sh. I have not tested the following yet, and
I'm a sucky bash programmer.
Init scripts should not use Bash, they should be Posix Shell scripts!
Sure.. by bash I mean POSIX shell
# Fully qualified paths to required programs
START_STOP_DAEMON=/sbin/start-stop-daemon
CAT=/bin/cat
ECHO=/bin/echo
Why not use echo and cat? Calling echo this way the shell can't use the
builtin echo command and must spawn a new process.
Is there a test to determine whether there is a builtin for a given
command? If so, we could test for that and use it if it exists.
Otherwise, use the fully qualified version
if [ -z $SERVICE_NAME ] || \
[ -z $SERVICE_DESC ] || \
[ -z $SERVICE_DAEMON ]; then
fatal( Environment not configured correctly.\n\tService requires
definition of the following variables:\nSERVICE_NAME\nSERVICE_DESC\n
SERVICE_DAEMON )
fi
Why you want to test these values everytime? If the maintainer forgot
them one time, they are missing everytime.
Maybe they exist one time but get removed before the next run?
# We do not want to be affected by PATH tampering. All calls to
# external programs will be fully qualified
PATH=
You know what you are doing here? PATH is necessary for the daemon to
find subcommands.
Yep. I don't want to execute any but the fully qualified commands.
It's a security thing.
# echo an error message and quit
fatal() {
echo - failed:
You should get familiar with LSB log function. See lsb-base.
I will. Thanks.
# Check whether we were configured to not start the services.
check_for_no_start() {
if [ $SERVICE_DISABLED = yes ]; then
This is such a broken behavior. Initscripts are enabled and disabled in
the configuration of the init system.
IMO there's no need for such a script. Use /etc/init.d/skeleton as a
template and adapt it to your service.
I agree... but existing scripts use such a beast, so I put it in here.
Bye, Jörg.
Cheers,
C.J.
signature.asc
Description: This is a digitally signed message part
Re: service helper package
On 25/11/2007, C.J. Adams-Collier [EMAIL PROTECTED] wrote: is there something like a service-common package that provides a helper script like the following for services to source? I'm thinking that it would belong somewhere like /usr/share/service-common/init.sh. I have not tested the following yet, and I'm a sucky bash programmer. Ever heard about lsb-base and /lib/lsb/init-functions? :) That's exactly what you are looking for. dh_make provides an example init.d script using the LSB init functions (but it isn't very compliant as it is now[1]) [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=450898 Regards, -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Say NO to Microsoft Office broken standard. See http://www.noooxml.org/petition -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: service helper package
On Mon, Nov 26, 2007 at 11:03:57PM +0100, Eric Lavarde wrote:
Thomas Goirand wrote:
Stephen Gran wrote:
# Check whether we were configured to not start the services.
check_for_no_start() {
if [ $SERVICE_DISABLED = yes ]; then
This is such a broken behavior. Initscripts are enabled and disabled in
the configuration of the init system.
That's not quite true - many packages in debian use an enable/disable
variable in an /etc/default/package file.
Not talking about any policy, but I personally hate it. Why on earth
would you want to have a package NOT to work if you install it? This is
insane...
You might want to disable _temporarily_ a certain application? It's
easier/quicker than to reconfigure the init system and you don't loose
the information about run-levels where the program is meant to start.
If you *really* need to knobble an init script temporarily, an 'exit 0' at
the top works perfectly well. That's a very, very rare occurance, though.
- Matt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: service helper package
Eric Lavarde schrieb:
Hi,
Thomas Goirand wrote:
Stephen Gran wrote:
# Check whether we were configured to not start the services.
check_for_no_start() {
if [ $SERVICE_DISABLED = yes ]; then
This is such a broken behavior. Initscripts are enabled and disabled in
the configuration of the init system.
That's not quite true - many packages in debian use an enable/disable
variable in an /etc/default/package file.
Not talking about any policy, but I personally hate it. Why on earth
would you want to have a package NOT to work if you install it? This is
insane...
You might want to disable _temporarily_ a certain application? It's
easier/quicker than to reconfigure the init system and you don't loose
the information about run-levels where the program is meant to start.
Just use a tool like sysv-rc-conf which manages the symlinks for you.
sysv-rc-conf $service on|off
It can't be easier than that and it works the way it's meant to be.
I also hate the enable/disable flags in /etc/default/$service.
Cheers,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
Re: service helper package
On Mon, Nov 26, 2007 at 04:51:38PM -0800, C.J. Adams-Collier wrote: On Mon, 2007-11-26 at 12:32 +, Jörg Sommer wrote: C.J. Adams-Collier [EMAIL PROTECTED] wrote: # Fully qualified paths to required programs START_STOP_DAEMON=/sbin/start-stop-daemon CAT=/bin/cat ECHO=/bin/echo Why not use echo and cat? Calling echo this way the shell can't use the builtin echo command and must spawn a new process. Is there a test to determine whether there is a builtin for a given command? If so, we could test for that and use it if it exists. Otherwise, use the fully qualified version There's type and command and which and whatis (see the policy huge long bug about this things) but I don't know why you would use them at runtime (except I guess how debhelper does it with if [ `which ... 2/null` ]; ...) Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: service helper package
This one time, at band camp, C.J. Adams-Collier said: On Mon, 2007-11-26 at 12:32 +, Jörg Sommer wrote: Why not use echo and cat? Calling echo this way the shell can't use the builtin echo command and must spawn a new process. Is there a test to determine whether there is a builtin for a given command? If so, we could test for that and use it if it exists. Otherwise, use the fully qualified version It's recommended not to use full paths in general. Sometimes it becomes necessary to move binaries from one path to another, and hard coding full paths breaks that. Resetting PATH is more useful than hard coding full paths to binaries if you're worried about security. You know what you are doing here? PATH is necessary for the daemon to find subcommands. Yep. I don't want to execute any but the fully qualified commands. It's a security thing. No, it's really not. Resetting PATH to some small subset is useful, but breaking your child processes' ability to run call popen isn't all that great. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: service helper package
Eric Lavarde wrote:
Hi,
Thomas Goirand wrote:
Stephen Gran wrote:
# Check whether we were configured to not start the services.
check_for_no_start() {
if [ $SERVICE_DISABLED = yes ]; then
This is such a broken behavior. Initscripts are enabled and disabled in
the configuration of the init system.
That's not quite true - many packages in debian use an enable/disable
variable in an /etc/default/package file.
Not talking about any policy, but I personally hate it. Why on earth
would you want to have a package NOT to work if you install it? This is
insane...
You might want to disable _temporarily_ a certain application? It's
easier/quicker than to reconfigure the init system and you don't loose
the information about run-levels where the program is meant to start.
Eric
I'm ok with that, but not *BY DEFAULT*. IMHO, by default, a package
should just run...
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
service helper package
is there something like a service-common package that provides a helper
script like the following for services to source?
I'm thinking that it would belong somewhere like
/usr/share/service-common/init.sh. I have not tested the following yet, and
I'm a sucky bash programmer.
# Fully qualified paths to required programs
START_STOP_DAEMON=/sbin/start-stop-daemon
CAT=/bin/cat
ECHO=/bin/echo
# Ensure that all required programs exist on the system
for REQUIRED_PROGRAM in $START_STOP_DAEMON $CAT $ECHO ; do
if [ ! -f $REQUIRED_PROGRAM ]; then
fatal( Required program, '$REQUIRED_PROGRAM' does not exist. )
fi
done
if [ -z $SERVICE_NAME ] || \
[ -z $SERVICE_DESC ] || \
[ -z $SERVICE_DAEMON ]; then
fatal( Environment not configured correctly.\n\tService requires
definition of the following variables:\nSERVICE_NAME\nSERVICE_DESC\n
SERVICE_DAEMON )
fi
# We do not want to be affected by PATH tampering. All calls to
# external programs will be fully qualified
PATH=
SERVICE_RUNDIR=/var/run/$SERVICE_NAME
SERVICE_PIDFILE=$SERVICE_RUNDIR/$SERVICE_NAME.pid
SERVICE_CONFDIR=/etc/$SERVICE_NAME
SERVICE_SENTINEL_FILE=$SERVICE_CONFDIR/disable
SERVICE_ENABLED=yes
SERVICE_PARAMS=
SERVICE_INIT_SCRIPT=/etc/init.d/$SERVICE_NAME
# Source service-specific default values
. /etc/default/$SERVICE_NAME
# Kill me on all errors
set -e
# If the daemon binary does not exist, report the error and exit
if [ ! -f $SERVICE_DAEMON ]; then
fatal( Service daemon, '$SERVICE_DAEMON' does not exist. )
fi
# Make sure the RUNDIR exists with correct permissions
if [ ! -d $RUNDIR ]; then
mkdir -p $RUNDIR
# If a service user is not zero length, chown the rundir
if [ -n $SERVICE_USER ]; then
chown -R $SERVICE_USER $RUNDIR
fi
# If a service group is not zero length, chown the rundir
if [ -n $SERVICE_GROUP ]; then
chgrp -R $SERVICE_GROUP $RUNDIR
fi
# Only allow $RUNDIR to be read/written/entered by root or service
# user/group
chmod 770 $RUNDIR
fi
# main switch statement - process service state change request
case $1 in
start)
start_service()
;;
stop)
stop_service()
;;
reload)
reload_service()
;;
restart)
restart_service()
;;
force-reload)
if [ x$SERVICE_GRACEFUL_RELOAD ]; then
reload_service()
else
restart_service()
fi
;;
*)
echo Usage: $INIT_SCRIPT {start|stop|restart|reload|force-reload}
2
exit 1
;;
esac
exit 0
# echo an error message and quit
fatal() {
echo - failed:
if [ -z $1 ]; then
echo $1
else
$CAT EOF
The operation failed but no output was produced. For hints on what went
wrong please refer to the system's logfiles (e.g. /var/log/syslog) or
try running the daemon in Debug mode like via $SERVICE_DAEMON
$SERVICE_DEBUG_ARGS (warning: this may create copious output).
EOF
fi
exit 1
}
# Check whether we were configured to not start the services.
check_for_no_start() {
if [ $SERVICE_DISABLED = yes ]; then
echo Not starting $SERVICE_NAME: SERVICE_DISABLED set in
/etc/default/$SERVICE_NAME 2
exit 0
fi
if [ -n $SERVICE_SENTINEL_FILE ] [ -e $SERVICE_SENTINEL_FILE ];
then
echo Not starting $SERVICE_NAME: $SERVICE_SENTINEL_FILE exists 2
exit 0
fi
}
start_service() {
check_for_no_start();
echo -n Starting $SERVICE_DESC:
$START_STOP_DAEMON \
--start \
--quiet \
--background \
--make-pidfile \
--pidfile $SERVICE_PIDFILE \
--chdir $SERVICE_RUNDIR \
--exec $SERVICE_DAEMON -- $SERVICE_PARAMS
echo $SERVICE_NAME.
}
stop_service() {
echo -n Stopping $SERVICE_DESC:
if [ ! -f $SERVICE_PIDFILE ]; then
echo not running.
exit 0
fi
$START_STOP_DAEMON \
--stop \
--oknodo \
--quiet \
--pidfile $SERVICE_PIDFILE \
--exec $SERVICE_DAEMON -- $SERVICE_PARAMS
echo $SERVICE_NAME.
}
reload_service() {
# If the service does not support graceful reload, tell the user
# and fail
if [ x$SERVICE_GRACEFUL_RELOAD = xno ]; then
fatal( Service does not support graceful reload. Try 'restart'
instead. )
fi
# If the daemon responds to changes in its config file directly
# anyway, make this a do-nothing entry.
if [ x$SERVICE_AUTO_REREADS_CONFIG = yes ]; then
echo Service '$SERVICE_NAME' reloads configuration automatically.
exit 0
fi
# If the daemon can reload its config files on the fly for example
# by sending it SIGHUP, do it here.
echo -n Sending SIGHUP to $SERVICE_DESC:
$START_STOP_DAEMON \
--stop \
--signal 1 \
--quiet \
--pidfile $SERVICE_PIDFILE \
--exec $SERVICE_DAEMON
echo $SERVICE_NAME.
}
restart_service() {
stop_service()
sleep 1
