[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion Init script

From: S.H.Mohanjith <moha_at_mohanjith.net>
Date: 2007-08-02 08:16:46 CEST

Peter Samuelson wrote:
> [S.H.Mohanjith]
>> I have attached an Init script for subversion. The script should be
>> placed in /etc/init.d/.
> And yet it mentions /etc/rc.d/init.d/. That is a legacy location.
>> I didn't get the chance to test on many distros. :-( I would like to
>> correct any portability issues, let me know if there are any.
> There are lots of portability issues.
> 1) source /etc/rc.d/init.d/functions
> I guess this is for the 'daemon', 'success' and 'failure' functions.
> But in any case, that file doesn't exist on most systems. Also,
> "source" is a bashism - see 3).
> 2) [ -x /usr/bin/svnserve ] || exit 1
> Not everybody installs svnserve to /usr/bin. Use autoconf.
> 3) SYSCONFIG="/etc/sysconfig/subversion"
> Pretty sure /etc/sysconfig is Red Hat-specific. Debian, for
> example, uses /etc/default. I don't know whether there is a
> standard location for this sort of thing.
> 4) echo -n $"Starting $desc ($prog): "
> echo -n $"Shutting down $desc ($prog): "
> echo $"Usage: $0 {start|stop|forcestop|restart|condrestart|status}"
> I have no idea why you want to use the $"" construct here, but it is
> a bashism. On other POSIX shells, it won't do what you think. I
> suppose it's acceptable to use bashisms in a script labeled
> #!/bin/bash, but is there a need to require bash to be installed on
> every Subversion user's system?
> 5) touch /var/lock/subsys/$prog
> /var/lock/subsys doesn't exist on most systems.
> 6) daemon $prog -d $OPTIONS --pid-file $pidfile
> [ $RETVAL -eq 0 ] && success || failure
> See 1).
> 7) pidstr=`pgrep $prog`
> I think pgrep is specific to Linux (in particular, procps).
> 8) kill -s 3 $pid
> I think "kill -QUIT" is more portable - if you think SIGQUIT is
> appropriate here. I think the default kill signal, SIGTERM, is
> better. That is the traditional way to ask a process to die.
> 9) I know the LSB is a Linux-specific issue, but your script is in
> several ways not LSB-compliant (see
> http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html).
> Some LSB-related issues I noticed:
> 9a) You don't support the required 'force-reload' action.
> 9b) The 'status' and 'stop' actions do not return the documented
> error codes. ('start' may or may not be compliant; I don't know
> the return values for the Red Hat 'daemon' function.)
> 9c) The script fails if svnserve is not installed - the LSB says it
> should silently succeed.
> 9d) There are no LSB header comments. (Yes, I know, these are
> optional.)
> 9e) You don't use LSB facilities for status messages. This is a
> problem for LSB compliance, but OTOH, those facilities are not
> portable beyond LSB platforms, so what you're doing now may be
> better.
>> Please let me know if there are any other issues in the Init script as well.
> Hmmmm.
> 1) # pidfile: /var/lock/subsys/svnserve
> While this is just a comment, it isn't accurate. You use
> /var/run/svnserve.pid elsewhere.
> 2) if [ $pid ]; then
> If you're "fluent in shell scripting", I hope I don't need to point
> out the problem with this line.... (:
> 3) As the LSB notes, admins may run init scripts with strange values in
> PATH and other shell variables. You should set your own PATH if you
> need it - which you do.
> 4) Stylistically, I don't like your mixed $VARIABLE vs. $variable
> names. And you should probably define a variable for
> /var/lock/subsys/$prog, especially since that's the wrong path on
> some systems anyway.
> 5) You don't provide a facility for running svnserve as a non-root
> user. I suspect most admins would prefer to specify a dedicated
> user. Use 'su' for this.
Hi Peter,
Thanks for pointing out the problems. I will make the changes necessary
for the Init script to be LSB and to make it portable.
I'll post it as soon as I complete it.

This was my first Init script. That's why it of such a bad quality. I'm
sorry for that.

Received on Thu Aug 2 08:15:25 2007

This is an archived mail posted to the Subversion Dev mailing list.