From m.seaman@infracaninophile.co.uk  Thu Nov 29 06:35:22 2007
Return-Path: <m.seaman@infracaninophile.co.uk>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 648CA16A41A
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 29 Nov 2007 06:35:22 +0000 (UTC)
	(envelope-from m.seaman@infracaninophile.co.uk)
Received: from smtp.infracaninophile.co.uk (ns0.infracaninophile.co.uk [IPv6:2001:8b0:151:1::1])
	by mx1.freebsd.org (Postfix) with ESMTP id EC4F713C467
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 29 Nov 2007 06:35:21 +0000 (UTC)
	(envelope-from m.seaman@infracaninophile.co.uk)
Received: from happy-idiot-talk.infracaninophile.co.uk (localhost.infracaninophile.co.uk [IPv6:::1])
	by smtp.infracaninophile.co.uk (8.14.1/8.14.1) with ESMTP id lAT6Z6AO066289
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 29 Nov 2007 06:35:06 GMT
	(envelope-from matthew@happy-idiot-talk.infracaninophile.co.uk)
Received: (from matthew@localhost)
	by happy-idiot-talk.infracaninophile.co.uk (8.14.1/8.14.1/Submit) id lAT6Z6IO066288;
	Thu, 29 Nov 2007 06:35:06 GMT
	(envelope-from matthew)
Message-Id: <200711290635.lAT6Z6IO066288@happy-idiot-talk.infracaninophile.co.uk>
Date: Thu, 29 Nov 2007 06:35:06 GMT
From: Matthew Seaman <m.seaman@infracaninophile.co.uk>
Reply-To: Matthew Seaman <m.seaman@infracaninophile.co.uk>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: periodic script to test statuses of daemons started via rc system
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         118325
>Category:       bin
>Synopsis:       [patch] [request] new periodic script to test statuses of daemons started via rc system
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-rc
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Thu Nov 29 06:40:02 UTC 2007
>Closed-Date:    
>Last-Modified:  Fri Jul 11 19:40:23 UTC 2008
>Originator:     Matthew Seaman
>Release:        FreeBSD 7.0-BETA1 i386
>Organization:
Infracaninophile
>Environment:
System: FreeBSD happy-idiot-talk.infracaninophile.co.uk 7.0-BETA1 FreeBSD 7.0-BETA1 #14: Thu Nov 1 23:25:45 GMT 2007 root@happy-idiot-talk.infracaninophile.co.uk:/usr/obj/usr/src/sys/HAPPY-IDIOT-TALK i386


	
>Description:

I submit for your consideration a periodic script which I've been
running for a month or so.  It checks on the status of all the daemons
started up by the rc system by using rcorder to get the list of all
enabled startup scripts exactly as the system initialisation does (as
in: I copied that chunk of code pretty much verbatim.)

I find this a useful double check after eg. a portupgrade session
where it's all too easy to forget to restart a particular daemon that
has been turned off for updating.

>How-To-Repeat:
	
>Fix:

	

--- 490.status-rc.shar begins here ---
# This is a shell archive.  Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file".  Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
#	490.status-rc
#
echo x - 490.status-rc
sed 's/^X//' >490.status-rc << 'END-of-490.status-rc'
X#!/bin/sh
X#
X# $Id: 490.status-rc,v 1.3 2007/10/21 11:25:25 matthew Exp $
X# $FreeBSD$
X#
X
X# Define these variables in either /etc/periodic.conf or
X# /etc/periodic.conf.local to override the default values.
X#
X# daily_status_rc_enable="YES" # run tests
X# daily_status_rc_exceptions="newsyslog bsdstats.sh othermta"
X#     # Startup scripts that don't give meaningful status output
X
Xdaily_status_rc_enable="YES"
Xdaily_status_rc_exceptions="newsyslog bsdstats.sh othermta"
X
X# If there is a global system configuration file, suck it in.
X#
Xif [ -r /etc/defaults/periodic.conf ]
Xthen
X    . /etc/defaults/periodic.conf
X    source_periodic_confs
Xfi
X
Xall_startup() {
X    # Cribbed shamelessly from /etc/rc
X
X    if [ -r /etc/rc.subr ]
X    then
X	. /etc/rc.subr
X	load_rc_config 'XXX'
X    fi
X
X    skip="-s nostart"
X    if [ $( /sbin/sysctl -n security.jail.jailed ) -eq 1 ]; then
X        skip="$skip -s nojail"
X    fi
X
X    case ${local_startup} in
X	[Nn][Oo] | '') ;;
X	*)             find_local_scripts_new ;;
X    esac
X
X    files=$( /sbin/rcorder ${skip} /etc/rc.d/* ${local_rc} 2>/dev/null )
X
X    # Now loop over all of the rc files and query their status
X    for _rc_elem in ${files}; do
X	output=$( run_rc_script $_rc_elem status 2>&1 )
X	result=$?
X
X	if [ $result -ne 0 ] ; then
X
X	    # Many of the system rc-scripts do not support 'status' as
X	    # a command line flag. Most, if not all, of the ports
X	    # rc-cripts do.
X
X	    if echo $output | \
X		grep -F "unknown directive 'status'" >/dev/null 2>&1 ; then
X		continue
X	    fi
X
X	    # Some rc-scripts do not start long-running processes but
X	    # still provide the default 'status' action.  This doesn't
X	    # make a great deal of sense given the default action is
X	    # to test that some process is alive.
X
X	    if echo $daily_status_rc_exceptions | \
X		grep -F $( basename ${_rc_elem} ) >/dev/null 2>&1 ; then
X		continue
X	    fi
X
X	    echo "==>> $_rc_elem"
X	    echo $output
X	    rc=1
X	fi
X    done
X}
X
X
X
Xrc=0
X
Xcase "$daily_status_rc_enable" in
X    [Yy][Ee][Ss])
X        echo ""
X        echo "RC Script Status Problems:"
X
X	all_startup
X	;;
X    *)
X        ;;
Xesac
X
Xexit $rc
END-of-490.status-rc
exit
--- 490.status-rc.shar ends here ---


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-rc 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Thu Nov 29 06:45:00 UTC 2007 
Responsible-Changed-Why:  
Over to maintainer(s) for discussion. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=118325 
State-Changed-From-To: open->analyzed 
State-Changed-By: dougb 
State-Changed-When: Mon Dec 3 22:17:55 UTC 2007 
State-Changed-Why:  

I like this idea, and I have some feedback for it. 


Responsible-Changed-From-To: freebsd-rc->dougb 
Responsible-Changed-By: dougb 
Responsible-Changed-When: Mon Dec 3 22:17:55 UTC 2007 
Responsible-Changed-Why:  

I'd like to manage this one. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=118325 

From: Doug Barton <dougb@FreeBSD.org>
To: bug-followup@FreeBSD.org, m.seaman@infracaninophile.co.uk
Cc:  
Subject: Re: bin/118325: [patch] new periodic script to test statuses of daemons
 started via rc system
Date: Mon, 03 Dec 2007 14:46:45 -0800

 I like this idea a lot, I think it would be a good addition to
 periodic. I do have some feedback for you, which I hope you will take
 in the constructive manner in which it's offered.
 
 First some meta-feedback. I am disturbed to hear that some of our
 system scripts don't support the 'status' argument. I'm moderately
 disturbed that some of the ones that don't start services return
 something that could be interpreted as meaningful for it. Could you
 work up a list for both categories, and send it to
 freebsd-rc@freebsd.org? Bonus points if you include patches. :)
 
 Now the feedback for your script. A general comment is that a very
 important rule of shell scripting is that you always want to avoid
 forking a subshell if you can. Thus I'd like to see your 'echo foo |
 grep' statements converted to use case. You can take a look at
 mergemaster if you need examples, I use that trick a lot.
 
 In terms of style, while I wouldn't hold it up for this the style we
 use most often is 'if [ blah ]; then' rather than putting 'then' on
 its own line. It saves a little space is the primary reason, although
 in the case of contributing code to an existing project maintaining a
 consistent style is its own reward. And while I'm picking nits,
 "result" is usually spelled "rc" (return code).
 
 In terms of what the script actually outputs, I'm torn. On the one
 hand I can't help feeling that it shouldn't output anything if the
 service is running. On the other I know some people will want that
 warm fuzzy feeling. So I'd like to propose that you add a _verbose
 variable to this mix. There are a few examples in /etc/periodic/daily
 you can take a look at. I also don't think that you should duplicate
 the name of the service if it's running, I think that's wasted space.
 What I have in mind is something like this:
 
 output=$( foo )
 rc=$?
 
 case "$rc" in
 0)	case "$daily_status_rc_verbose" in
 	yes)	echo "$output" ;;
 	esac
 	;;
 *)	echo "$output" ;;
 esac
 
 Now, that's the simple version. :) If you really want to get fancy,
 what I'd do is to run a counter for problem scripts, and increment it
 if you find any, and save the outputs of the various status commands.
 Then at the end you would do something like:
 
 case "verbose" in
 yes)	echo "Services running normally:"
 	echo "outputs"
 	;;
 esac
 
 case "number_of_problem_scripts" in
 0)	case "verbose" in
 	yes)	echo "No problems found!" ;;
 	esac
 *)	echo "Services not running:"
 	echo "bad-outputs"
 	;;
 esac
 
 There is another meta-message here, which is an output of "rc script
 status problems" followed by no output would probably be alarming to
 users, so one way or another you should find a way around that.
 
 
 hope this helps,
 
 Doug
 
 PS, if you're only submitting one file, it doesn't have to be a shar
 archive. :)
 
 -- 
 
     This .signature sanitized for your protection
 

From: Matthew Seaman <m.seaman@infracaninophile.co.uk>
To: Doug Barton <dougb@FreeBSD.org>
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/118325: [patch] new periodic script to test statuses of daemons
 started via rc system
Date: Sun, 09 Dec 2007 14:50:17 +0000

 This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
 --------------enigA30C8240C37266D79BC704A6
 Content-Type: multipart/mixed;
  boundary="------------060208010600060401090707"
 
 This is a multi-part message in MIME format.
 --------------060208010600060401090707
 Content-Type: text/plain; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 Doug Barton wrote:
 
 > First some meta-feedback. I am disturbed to hear that some of our
 > system scripts don't support the 'status' argument. I'm moderately
 > disturbed that some of the ones that don't start services return
 > something that could be interpreted as meaningful for it. Could you
 > work up a list for both categories, and send it to
 > freebsd-rc@freebsd.org? Bonus points if you include patches. :)
 
 I'll respond to this on the freebsd-rc list.
 
 > Now the feedback for your script. A general comment is that a very
 > important rule of shell scripting is that you always want to avoid
 > forking a subshell if you can. Thus I'd like to see your 'echo foo |
 > grep' statements converted to use case.=20
 
 No problem.  Two greps and a basename are gone.
 
 >                          I also don't think that you should duplicate
 > the name of the service if it's running, I think that's wasted space.
 
 Not all rc sripts status outputs indicate what service they were
 called for -- /etc/rc.d/pf is an example:
 
 # /etc/rc.d/pf status=20
 Password:
 Last login: Sun Dec  9 11:27:26 from happy-idiot-talk
 Status: Enabled for 6 days 09:37:51           Debug: Urgent
 
 State Table                          Total             Rate
   current entries                       42              =20
   searches                        11484397           20.8/s
   inserts                           243208            0.4/s
   removals                          243166            0.4/s
 Counters
   match                             243845            0.4/s
   bad-offset                             0            0.0/s
   fragment                               0            0.0/s
   short                                  0            0.0/s
   normalize                              0            0.0/s
   memory                                 0            0.0/s
   bad-timestamp                          0            0.0/s
   congestion                             0            0.0/s
   ip-option                              0            0.0/s
   proto-cksum                            7            0.0/s
   state-mismatch                        83            0.0/s
   state-insert                           0            0.0/s
   state-limit                            0            0.0/s
   src-limit                             10            0.0/s
   synproxy                               0            0.0/s
 
 The default action for the status command is to test whether a process
 is running, which will normally print the name of the process it just
 pinged with a 'kill -0', however a) sometimes the output is something
 completely different (as with pf) and b) the command name is not
 necessarily the same as the name given to the rc script that starts
 everything up.
 
 It is quite a common practice when you want to run multiple instances
 of a particular service to copy the rc script to a new name and do a
 global substitution of the variable prefix inside it.  We do this quite
 commonly with mysql -- a backup server will have several slave instances
 of mysql replicated on to it, so we can do database dumps  without interr=
 upting
 the live service.  It's not very good just  saying 'mysql is not running'=
 
 if there are several instances of mysql on the same machine.  Which one
 has the problem?
 
 Support for multiple profiles as seen in /etc/rc.d/jail or
 /usr/local/etc/rc.d/apache22 would be cleaner, but most rc scripts do
 not provide this.
 
 > What I have in mind is something like this:
 >=20
 > output=3D$( foo )
 > rc=3D$?
 
 $rc is already used as the overall script status, as is standard in
 periodic scripts, but I take your meaning.
 
 > case "$rc" in
 > 0)	case "$daily_status_rc_verbose" in
 > 	yes)	echo "$output" ;;
 > 	esac
 > 	;;
 > *)	echo "$output" ;;
 > esac
 
 Arrgh!  No.  I'm sorry, but bloating the nightly e-mail with a zillion
 repetitions of 'everything is OK' simply defeats the point, which is to
 highlight the problems.  It's a lot easier to hear the one small voice
 crying 'help' if everything else keeps silent.
 
 I'd have made the script produce no output at all if everything was OK,
 except that there is already a provision to prune the nightly output
 according to the periodic script exit status by the use of
 daily_show_{success,info,badconfig} [and the weekly and monthly
 equivalents].
 
 > There is another meta-message here, which is an output of "rc script
 > status problems" followed by no output would probably be alarming to
 > users, so one way or another you should find a way around that.
 
 Done.
 
 	Matthew
 
 --=20
 Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                   Flat 3
 PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
                                                   Kent, CT11 9PW
 
 --------------060208010600060401090707
 Content-Type: text/plain;
  name="490.status-rc"
 Content-Transfer-Encoding: quoted-printable
 Content-Disposition: inline;
  filename="490.status-rc"
 
 #!/bin/sh
 #
 # $Id: 490.status-rc,v 1.5 2007/12/09 11:27:16 matthew Exp $
 # $FreeBSD$
 #
 
 # Define these variables in either /etc/periodic.conf or
 # /etc/periodic.conf.local to override the default values.
 #
 # daily_status_rc_enable=3D"YES" # run tests
 # daily_status_rc_exceptions=3D"newsyslog bsdstats.sh othermta"
 #     # Startup scripts that don't give meaningful status output
 
 daily_status_rc_enable=3D"YES"
 daily_status_rc_exceptions=3D"newsyslog bsdstats.sh othermta"
 
 # If there is a global system configuration file, suck it in.
 #
 if [ -r /etc/defaults/periodic.conf ]; then
     . /etc/defaults/periodic.conf
     source_periodic_confs
 fi
 
 all_startup() {
     # Cribbed shamelessly from /etc/rc
 
     if [ -r /etc/rc.subr ]; then
 	. /etc/rc.subr
 	load_rc_config 'XXX'
     fi
 
     skip=3D"-s nostart"
     if [ $( /sbin/sysctl -n security.jail.jailed ) -eq 1 ]; then
         skip=3D"$skip -s nojail"
     fi
 
     case ${local_startup} in
 	[Nn][Oo] | '') ;;
 	*)             find_local_scripts_new ;;
     esac
 
     files=3D$( /sbin/rcorder ${skip} /etc/rc.d/* ${local_rc} 2>/dev/null =
 )
 
     # Now loop over all of the rc files and query their status
     for _rc_elem in ${files}; do
 	output=3D$( run_rc_script $_rc_elem status 2>&1 )
 
 	if [ $? -ne 0 ]; then
 
 	    # Many of the system rc-scripts do not support 'status' as
 	    # a command line flag. Most, if not all, of the ports
 	    # rc-cripts do.
 
 	    case $output in
 		*unknown\ directive\ \'status\'*)
 		    continue ;;
 		* ) ;;
 	    esac
 
 	    # Some rc-scripts do not start long-running processes but
 	    # still provide the default 'status' action.  This doesn't
 	    # make a great deal of sense given the default action is
 	    # to test that some process is alive.
 	   =20
 	    case ${daily_status_rc_exceptions} in
 		*${_rc_elem##*/}*)
                 continue ;;
 		*) ;;
 	    esac
 
 	    echo "=3D=3D>> $_rc_elem"
 	    echo $output
 	    rc=3D1
 	fi
     done
 
     if [ $rc -eq 0 ]; then
 	echo "No problems encountered"
     fi
 }
 
 
 
 rc=3D0
 
 case "$daily_status_rc_enable" in
     [Yy][Ee][Ss])
         echo ""
         echo "RC Script Status Problems:"
 
 	all_startup
 	;;
     *)
         ;;
 esac
 
 exit $rc
 
 --------------060208010600060401090707--
 
 --------------enigA30C8240C37266D79BC704A6
 Content-Type: application/pgp-signature; name="signature.asc"
 Content-Description: OpenPGP digital signature
 Content-Disposition: attachment; filename="signature.asc"
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.4 (FreeBSD)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
 iD8DBQFHXACv8Mjk52CukIwRCJsxAJ0Sc9uQPw2xqIugZg47LLPve94iNgCfRSX+
 lyPErF8tojm3CRCH00wVg44=
 =ciPQ
 -----END PGP SIGNATURE-----
 
 --------------enigA30C8240C37266D79BC704A6--

From: Matthew Seaman <m.seaman@infracaninophile.co.uk>
To: Doug Barton <dougb@FreeBSD.org>
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/118325: [patch] new periodic script to test statuses of daemons
 started via rc system
Date: Mon, 31 Dec 2007 10:46:19 +0000

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA256
 
 
 It seems there is a problem with /etc/rc.d/tmp which does not use the
 normal /etc/rc.subr machinery.  Effectively all calls to /etc/rc.d/tmp
 cause the 'start' action.  Most of the time this is harmless unless $tmpmfs
 is set to "YES" in /etc/rc.conf -- in that case, the script will create and
 mount yet another mfs over /tmp each time it is called.
 
 This just adds 'tmp' to the exceptions list and changes the logic slightly
 so that the scripts in the exceptions list are never called.  I'll send-pr
 about the tmp script separately.
 
 	Matthew
 
 % cvs diff -u 490.status-rc 
 Index: 490.status-rc
 ===================================================================
 RCS file: /home/matthew/cvsroot/scripts/490.status-rc,v
 retrieving revision 1.5
 diff -u -u -r1.5 490.status-rc
 - --- 490.status-rc       9 Dec 2007 11:27:16 -0000       1.5
 +++ 490.status-rc       31 Dec 2007 10:37:59 -0000
 @@ -8,11 +8,11 @@
  # /etc/periodic.conf.local to override the default values.
  #
  # daily_status_rc_enable="YES" # run tests
 - -# daily_status_rc_exceptions="newsyslog bsdstats.sh othermta"
 - -#     # Startup scripts that don't give meaningful status output
 +# daily_status_rc_exceptions="tmp newsyslog bsdstats.sh othermta"
 +#     # Startup scripts not to call 'status' on
  
  daily_status_rc_enable="YES"
 - -daily_status_rc_exceptions="newsyslog bsdstats.sh othermta"
 +daily_status_rc_exceptions="tmp newsyslog bsdstats.sh othermta"
  
  # If there is a global system configuration file, suck it in.
  #
 @@ -43,6 +43,19 @@
  
      # Now loop over all of the rc files and query their status
      for _rc_elem in ${files}; do
 +
 +       # Some rc-scripts do not start long-running processes but
 +       # still provide the default 'status' action.  Worse:
 +       # /etc/rc.d/tmp does the 'start' action even when called as
 +       # 'status', which is harmful if $tmpmfs is defined in
 +       # /etc/rc.conf. Skip the known problem cases.
 +
 +       case ${daily_status_rc_exceptions} in
 +           *${_rc_elem##*/}*)
 +               continue ;;
 +           *) ;;
 +        esac
 +
         output=$( run_rc_script $_rc_elem status 2>&1 )
  
         if [ $? -ne 0 ]; then
 @@ -57,17 +70,6 @@
                 * ) ;;
             esac
  
 - -           # Some rc-scripts do not start long-running processes but
 - -           # still provide the default 'status' action.  This doesn't
 - -           # make a great deal of sense given the default action is
 - -           # to test that some process is alive.
 - -           
 - -           case ${daily_status_rc_exceptions} in
 - -               *${_rc_elem##*/}*)
 - -                continue ;;
 - -               *) ;;
 - -           esac
 - -
             echo "==>> $_rc_elem"
             echo $output
             rc=1
 
 
 - -- 
 Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                   Flat 3
 PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
                                                   Kent, CT11 9PW
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.4 (FreeBSD)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
 iD8DBQFHeMh78Mjk52CukIwRCKQFAJ4wVbdum79ZDzIGxKewAmTfwUG6EgCfW0Js
 faR1N+0Ck1Sdr3E8KtKYrNc=
 =iZAD
 -----END PGP SIGNATURE-----

From: Matthew Seaman <m.seaman@infracaninophile.co.uk>
To: Doug Barton <dougb@FreeBSD.org>
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/118325: [patch] new periodic script to test statuses of daemons
 started via rc system
Date: Mon, 31 Dec 2007 11:05:08 +0000

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA256
 
 Matthew Seaman wrote:
 
 Dammit.  Scratch the previous patch.  /etc/rc.d/var does the same
 thing as /etc/rc.d/tmp.
 
 	Matthew
 
 % cvs diff -u 490.status-rc
 Index: 490.status-rc
 ===================================================================
 RCS file: /home/matthew/cvsroot/scripts/490.status-rc,v
 retrieving revision 1.5
 diff -u -u -r1.5 490.status-rc
 - --- 490.status-rc       9 Dec 2007 11:27:16 -0000       1.5
 +++ 490.status-rc       31 Dec 2007 11:02:50 -0000
 @@ -8,11 +8,11 @@
  # /etc/periodic.conf.local to override the default values.
  #
  # daily_status_rc_enable="YES" # run tests
 - -# daily_status_rc_exceptions="newsyslog bsdstats.sh othermta"
 - -#     # Startup scripts that don't give meaningful status output
 +# daily_status_rc_exceptions="tmp var newsyslog bsdstats.sh othermta"
 +#     # Startup scripts not to call 'status' on
  
  daily_status_rc_enable="YES"
 - -daily_status_rc_exceptions="newsyslog bsdstats.sh othermta"
 +daily_status_rc_exceptions="tmp var newsyslog bsdstats.sh othermta"
  
  # If there is a global system configuration file, suck it in.
  #
 @@ -43,6 +43,19 @@
  
      # Now loop over all of the rc files and query their status
      for _rc_elem in ${files}; do
 +
 +       # Some rc-scripts do not start long-running processes but
 +       # still provide the default 'status' action.  Worse:
 +       # /etc/rc.d/{tmp,var} do the 'start' action even when called
 +       # as 'status', which is harmful if $tmpmfs or $varmfs is
 +       # defined in /etc/rc.conf. Skip the known problem cases.
 +
 +       case ${daily_status_rc_exceptions} in
 +           *${_rc_elem##*/}*)
 +               continue ;;
 +           *) ;;
 +        esac
 +
         output=$( run_rc_script $_rc_elem status 2>&1 )
  
         if [ $? -ne 0 ]; then
 @@ -57,17 +70,6 @@
                 * ) ;;
             esac
  
 - -           # Some rc-scripts do not start long-running processes but
 - -           # still provide the default 'status' action.  This doesn't
 - -           # make a great deal of sense given the default action is
 - -           # to test that some process is alive.
 - -           
 - -           case ${daily_status_rc_exceptions} in
 - -               *${_rc_elem##*/}*)
 - -                continue ;;
 - -               *) ;;
 - -           esac
 - -
             echo "==>> $_rc_elem"
             echo $output
             rc=1
 
 - -- 
 Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                   Flat 3
 PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
                                                   Kent, CT11 9PW
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.4 (FreeBSD)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
 iD8DBQFHeMzk8Mjk52CukIwRCGh/AJ4/QCGHWycLmyWnlm6+GQlntwdgWgCff5tO
 Mmy7/HtPqW8J098kbWQHi3o=
 =K87v
 -----END PGP SIGNATURE-----
State-Changed-From-To: analyzed->open 
State-Changed-By: dougb 
State-Changed-When: Fri Jul 11 19:39:49 UTC 2008 
State-Changed-Why:  

Cast this one back into the pool, unfortunately I won't have 
time to give it proper attention any time soon. 


Responsible-Changed-From-To: dougb->freebsd-rc 
Responsible-Changed-By: dougb 
Responsible-Changed-When: Fri Jul 11 19:39:49 UTC 2008 
Responsible-Changed-Why:  

Cast this one back into the pool, unfortunately I won't have 
time to give it proper attention any time soon. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=118325 
>Unformatted:
