[gentoo-dev] init script guidelines

[gentoo-dev] init script guidelines

[Eric Brown]

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

Services that use Gentoo init scripts often report a status of [started]
or
[OK] even though they fail to start.  The most recent bug like this that
I've
found is with snort.  If you have a bad rule, snort will initialize, the
rc-scripts will give it an [OK] status, and then it will die once it
parses the
rules.
 
The real problem is not that the daemons don't return errors, but that
our init
scripts do not make reasonable attempts to verify service startup.  If a
Gentoo
init script claims that a service started, it should make an effort to
check
that the processes are actually running shortly after the script is run,
even if
start-stop-daemon says the parent process initialized.  Relying on the
return
value of start-stop-daemon is simply insufficient for some services.
 
I am aware that there are services that can monitor the status of other
services
(app-admin/mon?) but I think this issue is a little different.  If an
ebuild
developer is aware of an error condition can commonly occur shortly
after a
daemon initializes, why not attempt to catch those errors?  Most of them
could
probably be caught by simply checking to see if the process is still
running
shortly after the script is run.
 
I propose increasing developer awareness of this problem, perhaps
through some
formal guidelines for ebuild developers.  At the very least, I would
like to see
these bugs being acknowledged in bugs.gentoo.org instead of getting the
same old
upstream/it's not our fault response.  We are responsible for our init
scripts,
and they are important to our users.
 
I have 2 ideas for the actual implementation:
 
1) Some kind of check() function in the init.d script, or a generic
check() function
that just checks with ps | grep.  This might typically be called after
having the
init script sleep for a certain amount of time.
 
2) Some kind of special init script that checks registered daemons after
all services
have started. (i.e. it depends on all daemons, or they are put into it's
config file).
With this scheme we could avoid excessive sleeping during startup (to
keep it fast),
And perhaps even keep using service specific check() functions
 
 
Does anyone else think this idea is worth looking into?

 

 

  

 


[-- Attachment #2: Type: text/html, Size: 8233 bytes --]

Re: [gentoo-dev] init script guidelines

[Chris Gianelloni]

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

On Tue, 2005-07-19 at 12:42 -0400, Eric Brown wrote:
> Services that use Gentoo init scripts often report a status of [started] or
> [OK] even though they fail to start.  The most recent bug like this that I've
> found is with snort.  If you have a bad rule, snort will initialize, the
> rc-scripts will give it an [OK] status, and then it will die once it parses the
> rules.

So snort shouldn't be giving the OK until it really is OK.
>  
> The real problem is not that the daemons don't return errors, but that our init
> scripts do not make reasonable attempts to verify service startup.  If a Gentoo
> init script claims that a service started, it should make an effort to check
> that the processes are actually running shortly after the script is run, even if
> start-stop-daemon says the parent process initialized.  Relying on the return
> value of start-stop-daemon is simply insufficient for some services.

Not really.  An init script is simply a script.  It doesn't guarantee
anything other than what the service told it.  If a service is returning
status codes when it really isn't completed its initialization, that is
a bug in that service, not in the init script code.  While code might
need to be adjusted in the init script, this will most likely require
patches to the upstream sources.
>  
> I am aware that there are services that can monitor the status of other services
> (app-admin/mon?) but I think this issue is a little different.  If an ebuild
> developer is aware of an error condition can commonly occur shortly after a
> daemon initializes, why not attempt to catch those errors?  Most of them could
> probably be caught by simply checking to see if the process is still running
> shortly after the script is run.

I agree with you that we should catch the errors, but running another
check is simply a waste of time.  The service should not ever show a
completed state until it is completed.  It shouldn't ever be like "Yes,
snort worked.......... oh wait, no it didn't."  That is even more
confusing for users.

> I propose increasing developer awareness of this problem, perhaps through some
> formal guidelines for ebuild developers.  At the very least, I would like to see
> these bugs being acknowledged in bugs.gentoo.org instead of getting the same old
> upstream/it's not our fault response.  We are responsible for our init scripts,
> and they are important to our users.

You really need to take this up with the developers in question, as this
is not a global matter, but really a matter with specific packages.
Those are bugs in those packages.  If the ebuild maintainers are
refusing to resolve issues in the init scripts, which are definitely
Gentoo works, please take it up with user relations or attempt to
provide a fix for the problem.
>  
> I have 2 ideas for the actual implementation:
>  
> 1) Some kind of check() function in the init.d script, or a generic check() function
> that just checks with ps | grep.  This might typically be called after having the
> init script sleep for a certain amount of time.

I would object to this.  Having a function to check the status of a
service for all of the possible services, when it is only a few that are
showing this error, is a bad idea.  It adds extra load on all developers
that have any init scripts, and is unnecessary in most cases.
>  
> 2) Some kind of special init script that checks registered daemons after all services
> have started. (i.e. it depends on all daemons, or they are put into it’s config file).
> With this scheme we could avoid excessive sleeping during startup (to keep it fast),
> And perhaps even keep using service specific check() functions

This would require much more knowledge on the end-user's part.  Plus, it
will need to be aware of init script dependencies.  All in all, it
sounds like a bad patch for a situation.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] init script guidelines

[Mike Frysinger]

On Tuesday 19 July 2005 12:42 pm, Eric Brown wrote:
> The real problem is not that the daemons don't return errors, but that
> our init scripts do not make reasonable attempts to verify service startup.

i'd disagree ... if a service sucks, it sucks

adding some code to try and guess whether the service actually started is a 
roundabout (and by no means fool proof) way of doing things ... it may result 
in correct results sometimes, but i imagine it'll also be susceptible to 
false positives

> If a Gentoo init script claims that a service started, it should make an
> effort to check that the processes are actually running shortly after the
> script is run

how do you define 'short' ?  really anything that relies on sometime out value 
like this is a flawed design ... just cause your smokin fast amd64 should 
complete in .1 seconds doesnt mean my not-very-smokin-fast-at-all arm 
netwinder can complete inside of 3 seconds

> Relying on the return
> value of start-stop-daemon is simply insufficient for some services.

then those services should not be using ssd

> I propose increasing developer awareness of this problem, perhaps
> through some formal guidelines for ebuild developers.

this seems to be the only feasible approach (and one i'm all for)
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] init script guidelines

[Roy Marples]

On Tue, 2005-07-19 at 12:42 -0400, Eric Brown wrote:


> The real problem is not that the daemons don't return errors, but that our init
> scripts do not make reasonable attempts to verify service startup.  If a Gentoo
> init script claims that a service started, it should make an effort to check
> that the processes are actually running shortly after the script is run, even if
> start-stop-daemon says the parent process initialized.  Relying on the return
> value of start-stop-daemon is simply insufficient for some services.

I agree.

Infact, rc-services.sh (/lib/rcscripts/sh) has been totally re-written
for the baselayout-1.12.x branch. It now intercepts calls to
start-stop-daemon and checks if the daemon is still active after a
default time of 0.1 (adjustable) seconds. If not, the we assume the
daemon failed. This solves many existing bugs :)

Also, we kill any rogue processes and other such checks when a stop call
to start-stop-daemon is made - which is handy for when asterisk fails to
start and leaves mpg123 processes lying around :)

Check it out when baselayout-1.12.0pre1 hits portage!

Caveat: - some init scripts abuse start-stop-daemon. One example are all
courier scripts which pass the env program as a daemon. This is easily
worked around, but we fail badly if env then calls a shell script which
in turn launches a daemon. Of all the server stuff I run, only couier
has this issue - but there may be other programs too. Basically
start-stop-daemon should only call daemons!

http://bugs.gentoo.org/show_bug.cgi?id=98745

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] init script guidelines

[Francesco R]

Roy Marples wrote:

>On Tue, 2005-07-19 at 12:42 -0400, Eric Brown wrote:
>
>
>  
>
>>The real problem is not that the daemons don't return errors, but that our init
>>scripts do not make reasonable attempts to verify service startup.  If a Gentoo
>>init script claims that a service started, it should make an effort to check
>>that the processes are actually running shortly after the script is run, even if
>>start-stop-daemon says the parent process initialized.  Relying on the return
>>value of start-stop-daemon is simply insufficient for some services.
>>    
>>
>
>I agree.
>
>Infact, rc-services.sh (/lib/rcscripts/sh) has been totally re-written
>for the baselayout-1.12.x branch. It now intercepts calls to
>start-stop-daemon and checks if the daemon is still active after a
>default time of 0.1 (adjustable) seconds. If not, the we assume the
>daemon failed. This solves many existing bugs :)
>
>Also, we kill any rogue processes and other such checks when a stop call
>to start-stop-daemon is made - which is handy for when asterisk fails to
>start and leaves mpg123 processes lying around :)
>
>Check it out when baselayout-1.12.0pre1 hits portage!
>
>Caveat: - some init scripts abuse start-stop-daemon. One example are all
>courier scripts which pass the env program as a daemon. This is easily
>worked around, but we fail badly if env then calls a shell script which
>in turn launches a daemon. Of all the server stuff I run, only couier
>has this issue - but there may be other programs too. Basically
>start-stop-daemon should only call daemons!
>
>http://bugs.gentoo.org/show_bug.cgi?id=98745
>
>Roy
>  
>

what about to define two additional functions

check_startup() and check_shutdown()

intended to be filled from package mantainer.
The rc scripts can call these one to check if a service is
started/stopped or not.
If not it wait and retry untill a timeout is reached.

This open the road also to centralized policies of waits between check
like :
(1,1,1,1,1,1) (1,2,3,4,5,6) (1,2,4,8,16,32) and other nice stuff.

Francesco
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] init script guidelines

[Paul de Vrieze]

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

On Tuesday 19 July 2005 20:00, Roy Marples wrote:
> On Tue, 2005-07-19 at 12:42 -0400, Eric Brown wrote:
> > The real problem is not that the daemons don't return errors, but
> > that our init scripts do not make reasonable attempts to verify
> > service startup.  If a Gentoo init script claims that a service
> > started, it should make an effort to check that the processes are
> > actually running shortly after the script is run, even if
> > start-stop-daemon says the parent process initialized.  Relying on
> > the return value of start-stop-daemon is simply insufficient for some
> > services.
>
> I agree.
>
> Infact, rc-services.sh (/lib/rcscripts/sh) has been totally re-written
> for the baselayout-1.12.x branch. It now intercepts calls to
> start-stop-daemon and checks if the daemon is still active after a
> default time of 0.1 (adjustable) seconds. If not, the we assume the
> daemon failed. This solves many existing bugs :)
>
> Also, we kill any rogue processes and other such checks when a stop
> call to start-stop-daemon is made - which is handy for when asterisk
> fails to start and leaves mpg123 processes lying around :)
>
> Check it out when baselayout-1.12.0pre1 hits portage!
>
> Caveat: - some init scripts abuse start-stop-daemon. One example are
> all courier scripts which pass the env program as a daemon. This is
> easily worked around, but we fail badly if env then calls a shell
> script which in turn launches a daemon. Of all the server stuff I run,
> only couier has this issue - but there may be other programs too.
> Basically start-stop-daemon should only call daemons!

What I would really like to see in the init system is a way that 
initscripts can check whether the services they are responsible for are 
still running and then adjust their status accordingly, along with some 
nice output. This would then allow the execution of rc-status to give 
proper information of actually running daemons, and the "rc" command the 
possibility to actually bring online all daemons that should be running.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] init script guidelines

[Roy Marples]

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

On Tue, 2005-08-23 at 16:09 +0200, Paul de Vrieze wrote:
> What I would really like to see in the init system is a way that 
> initscripts can check whether the services they are responsible for are 
> still running and then adjust their status accordingly, along with some 
> nice output. This would then allow the execution of rc-status to give 
> proper information of actually running daemons, and the "rc" command the 
> possibility to actually bring online all daemons that should be running.
> 
> Paul
> 

Attached is a patch to baselayout-1.12.0_pre6-r3 that allows this.
Basically when an init script calls start-stop-daemon --start then we
log what it started (and hopefully a pidfile) in
${svcdir}/daemons/${myservice}

When it's status is asked for (either init.d/foo status or rc-status)
then we load this daemon file and check to see if the given daemons are
still running. If not then we call init.d/foo stop. We do this instead
of just marking the daemon as stopped in-case there is any clean-up code
that's needed to be run by the init script.

For this to work well, start-stop-daemon needs to be used correctly, not
just to stop it (like most init scripts seem to). sshd is a popular init
script and on most Gentoo'ers systems, so I've attached a patch so show
how init script should use start-stop-daemon so this works correctly.

What do people think about this? Is this worthfile and fixing all the
init scripts in the tree to use start-stop-daemon correctly AND for
starting up?

Thanks

Roy

[-- Attachment #2: rc-init-status.patch --]
[-- Type: text/x-patch, Size: 5126 bytes --]

--- rc-status	2005-08-01 21:26:00.000000000 +0100
+++ /bin/rc-status	2005-08-31 07:57:15.000000000 +0100
@@ -31,6 +31,7 @@
 
 # grab settings from conf.d/rc
 source /etc/conf.d/rc
+source "${svclib}/sh/rc-daemon.sh"
 
 ################################################################################
 #  Parse command line options                                                  #
@@ -157,10 +158,19 @@
 #  Now collect information about the status of the various services; whether   #
 #  they're started, broken, or failed.  Put all of this into arrays.           #
 ################################################################################
-# Read services from ${svcdir}/{started,failed,broken}
+if [[ -x ${svcdir}/started ]]; then
+    started=$(ls ${svcdir}/started)
+    # If we're root then update service statuses incase any naughty daemons
+    # stopped running without our say so
+    if [[ ${EUID} == 0 ]]; then
+	for service in ${started}; do
+	    update_service_status "${service}"
+	done
+	started=$(ls ${svcdir}/started)
+    fi
+fi
 [[ -x ${svcdir}/starting ]] && starting=$(ls ${svcdir}/starting)
 [[ -x ${svcdir}/inactive ]] && inactive=$(ls ${svcdir}/inactive)
-[[ -x ${svcdir}/started ]] && started=$(ls ${svcdir}/started)
 [[ -x ${svcdir}/stopping ]] && stopping=$(ls ${svcdir}/stopping)
 
 ################################################################################
--- runscript.sh	2005-08-21 18:08:24.000000000 +0100
+++ /sbin/runscript.sh	2005-08-31 07:59:30.000000000 +0100
@@ -413,6 +413,10 @@
 	# to work with the printed " * status:  foo".
 	local efunc="" state=""
 
+	# If we are effectively root, check to see if required daemons are running
+	# and update our status accordingly
+	[[ ${EUID} == 0 ]] && update_service_status "${myservice}"
+
 	if service_starting "${myservice}" ; then
 		efunc="einfo"
 		state="starting"
--- rc-daemon.sh	2005-08-30 07:22:39.000000000 +0100
+++ /lib/rcscripts/sh/rc-daemon.sh	2005-08-31 07:53:14.000000000 +0100
@@ -19,6 +19,7 @@
 RC_GOT_DAEMON="yes"
 
 [[ ${RC_GOT_FUNCTIONS} != "yes" ]] && source /sbin/functions.sh
+[[ ${RC_GOT_SERVICES} != "yes" ]] && source "${svclib}/sh/rc-services.sh"
 
 RC_RETRY_KILL="no"
 RC_RETRY_TIMEOUT=1
@@ -285,14 +286,45 @@
 	return "${retval}"
 }
 
+# void update_service_status(char *service)
+#
+# Loads the service state file and ensures that all listed daemons are still
+# running - hopefully on their correct pids too
+# If not, we stop the service
+update_service_status() {
+	local service="$1" daemonfile="${svcdir}/daemons/$1" i
+	local -a RC_DAEMONS=() RC_PIDFILES=()
+
+	# We only care about marking started services as stopped if the daemon(s)
+	# for it are no longer running
+	! service_started "${service}" && return
+	[[ ! -f ${daemonfile} ]] && return
+
+	# OK, now check that every daemon launched is active
+	# If the --start command was any good a pidfile was specified too
+	source "${daemonfile}"
+	for (( i=0; i<${#RC_DAEMONS[@]}; i++ )); do
+		if ! is_daemon_running ${RC_DAEMONS[i]} "${RC_PIDFILES[i]}" ; then
+			if [[ -e "/etc/init.d/${service}" ]]; then
+				/etc/init.d/"${service}" stop &>/dev/null
+				break
+			fi
+		fi
+	done
+}
+
 # int start-stop-daemon(...)
 #
 # Provide a wrapper to start-stop-daemon
 # Return the result of start_daemon or stop_daemon depending on
 # how we are called
 start-stop-daemon() {
-	local args=$( requote "$@" )
-	local cmd pidfile pid stopping signal nothing=false
+	local args=$( requote "$@" ) result i
+	local cmd pidfile pid stopping signal nothing=false 
+	local daemonfile="${svcdir}/daemons/${myservice}"
+	local -a RC_DAEMONS=() RC_PIDFILES=()
+
+	[[ -e ${daemonfile} ]] && source "${daemonfile}"
 
 	rc_setup_daemon_vars
 
@@ -303,10 +335,49 @@
 	fi
 
 	if ${stopping}; then
-		rc_stop_daemon 
+		rc_stop_daemon
+		result="$?"
+		if [[ ${result} == "0" ]]; then
+			# We stopped the daemon successfully
+			# so we remove it from our state
+			for (( i=0; i<${#RC_DAEMONS[@]}; i++ )); do
+				# We should really check for valid cmd AND pidfile
+				# But most called to --stop only set the pidfile
+				if [[ ${RC_DAEMONS[i]} == "{cmd}" \
+					|| ${RC_PIDFILES[i]}="${pidfile}" ]]; then
+					unset RC_DAEMONS[i] RC_PIDFILES[i]
+					RC_DAEMONS=( "${RC_DAEMONS[@]}" )
+					RC_PIDFILES=( "${RC_PIDFILES[@]}" )
+					break
+				fi
+			done
+		fi
 	else
 		rc_start_daemon
+		result="$?"
+		if [[ ${result} == "0" ]]; then
+			# We started the daemon sucessfully
+			# so we add it to our state
+			local max="${#RC_DAEMONS[@]}"
+			RC_DAEMONS[max]="${cmd}"
+			RC_PIDFILES[max]="${pidfile}"
+		fi
+	fi
+
+	# Write the new list of daemon states for this service
+	if [[ ${#RC_DAEMONS[@]} == "0" ]]; then
+		[[ -f ${daemonfile} ]] && rm -f "${daemonfile}"
+	else
+		echo "RC_DAEMONS[0]=\"${RC_DAEMONS[0]}\"" > "${daemonfile}"
+		echo "RC_PIDFILES[0]=\"${RC_PIDFILES[0]}\"" >> "${daemonfile}"
+
+		for (( i=1; i<${#RC_DAEMONS[@]}; i++ )); do
+			echo "RC_DAEMONS[${i}]=\"${RC_DAEMONS[i]}\"" >> "${daemonfile}"
+			echo "RC_PIDFILES[${i}]=\"${RC_PIDFILES[i]}\"" >> "${daemonfile}"
+		done
 	fi
+
+	return "${result}"
 }
 
 # vim:ts=4

[-- Attachment #3: sshd-ssd.patch --]
[-- Type: text/x-patch, Size: 490 bytes --]

--- sshd.orig	2005-08-31 08:07:05.000000000 +0100
+++ sshd	2005-08-31 08:08:05.000000000 +0100
@@ -40,12 +40,14 @@
 start() {
 	checkconfig || return 1
 	ebegin "Starting sshd"
-	/usr/sbin/sshd
+	start-stop-daemon --start --exec /usr/sbin/sshd \
+	    --pidfile /var/run/sshd.pid
 	eend $?
 }
 
 stop() {
 	ebegin "Stopping sshd"
-	start-stop-daemon --stop --quiet --pidfile /var/run/sshd.pid
+	start-stop-daemon --stop --exec /usr/bin/sshd \
+	    --pidfile /var/run/sshd.pid
 	eend $?
 }

Re: [gentoo-dev] init script guidelines

[Roy Marples]

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

On Wed, 2005-08-31 at 08:13 +0100, Roy Marples wrote:
> Attached is a patch to baselayout-1.12.0_pre6-r3 that allows this.
> Basically when an init script calls start-stop-daemon --start then we
> log what it started (and hopefully a pidfile) in
> ${svcdir}/daemons/${myservice}

Forgot to attach a patch for depscan.sh

Roy

[-- Attachment #2: depscan.patch --]
[-- Type: text/x-patch, Size: 340 bytes --]

--- depscan.sh	2005-08-17 22:04:34.000000000 +0100
+++ /sbin/depscan.sh	2005-08-31 06:25:11.000000000 +0100
@@ -16,7 +16,7 @@
 	fi
 fi
 
-for x in softscripts snapshot options \
+for x in softscripts snapshot options daemons \
 	started starting inactive stopping failed \
 	exclusive exitcodes ; do
 	if [[ ! -d "${svcdir}/${x}" ]] ; then

Re: [gentoo-dev] init script guidelines

[Georgi Georgiev]

maillog: 31/08/2005-09:05:51(+0100): Roy Marples types
> On Wed, 2005-08-31 at 08:13 +0100, Roy Marples wrote:
> > Attached is a patch to baselayout-1.12.0_pre6-r3 that allows this.
> > Basically when an init script calls start-stop-daemon --start then we
> > log what it started (and hopefully a pidfile) in
> > ${svcdir}/daemons/${myservice}
> 
> Forgot to attach a patch for depscan.sh

Not related, but why not apply this as well, while you're at it:

--- /sbin/depscan.sh	2005-08-25 17:28:51.000000000 +0900
+++ /sbin/depscan.sh	2005-08-31 17:21:37.000000000 +0900
@@ -1,7 +1,7 @@
 #!/bin/bash
 # Copyright 1999-2004 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
-# $Header$
+# $Header: $
 
 source /etc/init.d/functions.sh
 
-- 
 /   Georgi Georgiev    / Depart in pieces, i.e., split.                /
\     chutz@gg3.net    \                                               \
 /  +81(90)2877-8845    /                                               /
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] OT: cvs $Header not substituted

[Georgi Georgiev]

maillog: 31/08/2005-17:24:36(+0900): Георги Георгиев types
> maillog: 31/08/2005-09:05:51(+0100): Roy Marples types
> > On Wed, 2005-08-31 at 08:13 +0100, Roy Marples wrote:
> > > Attached is a patch to baselayout-1.12.0_pre6-r3 that allows this.
> > > Basically when an init script calls start-stop-daemon --start then we
> > > log what it started (and hopefully a pidfile) in
> > > ${svcdir}/daemons/${myservice}
> > 
> > Forgot to attach a patch for depscan.sh
> 
> Not related, but why not apply this as well, while you're at it:
> 
> --- /sbin/depscan.sh	2005-08-25 17:28:51.000000000 +0900
> +++ /sbin/depscan.sh	2005-08-31 17:21:37.000000000 +0900
> @@ -1,7 +1,7 @@
>  #!/bin/bash
>  # Copyright 1999-2004 Gentoo Foundation
>  # Distributed under the terms of the GNU General Public License v2
> -# $Header$
> +# $Header: $

Seems it's not needed. Anyone has any idea, why the $header is not
substituted?

-- 
()   Georgi Georgiev   () Confession is good for the soul only in the  ()
()    chutz@gg3.net    () sense that a tweed coat is good for          ()
()  +81(90)2877-8845   () dandruff. -- Peter de Vries                  ()
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] OT: cvs $Header not substituted

[Brian Harring]

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

On Wed, Aug 31, 2005 at 05:32:09PM +0900, Georgi Georgiev wrote:
> Anyone has any idea, why the $header is not
> substituted?
svn by chance? :)
Just did the conversion for portage branches for that...
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] OT: cvs $Header not substituted

[Roy Marples]

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

On Wed, 2005-08-31 at 03:42 -0500, Brian Harring wrote:
> On Wed, Aug 31, 2005 at 05:32:09PM +0900, Georgi Georgiev wrote:
> > Anyone has any idea, why the $header is not
> > substituted?
> svn by chance? :)
> Just did the conversion for portage branches for that...
> ~harring

bingo :)

I'll remove it

-- 
Roy Marples <uberlord@gentoo.org>
Gentoo Linux Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] OT: cvs $Header not substituted

[Paul de Vrieze]

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

On Wednesday 31 August 2005 10:54, Roy Marples wrote:
> On Wed, 2005-08-31 at 03:42 -0500, Brian Harring wrote:
> > On Wed, Aug 31, 2005 at 05:32:09PM +0900, Georgi Georgiev wrote:
> > > Anyone has any idea, why the $header is not
> > > substituted?
> >
> > svn by chance? :)
> > Just did the conversion for portage branches for that...
> > ~harring
>
> bingo :)
>
> I'll remove it

You can do substitutions in svn too. You just need to enable it for the 
file. It's one of the svn:???? attributes.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] OT: cvs $Header not substituted

[Roy Marples]

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

On Wed, 2005-08-31 at 12:05 +0200, Paul de Vrieze wrote:
> You can do substitutions in svn too. You just need to enable it for the 
> file. It's one of the svn:???? attributes.

However, individual file versions are non-existent in svn so imo removal
is the best option.

-- 
Roy Marples <uberlord@gentoo.org>
Gentoo Linux Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] OT: cvs $Header not substituted

[Mike Frysinger]

On Wednesday 31 August 2005 06:05 am, Paul de Vrieze wrote:
> On Wednesday 31 August 2005 10:54, Roy Marples wrote:
> > On Wed, 2005-08-31 at 03:42 -0500, Brian Harring wrote:
> > > On Wed, Aug 31, 2005 at 05:32:09PM +0900, Georgi Georgiev wrote:
> > > > Anyone has any idea, why the $header is not
> > > > substituted?
> > >
> > > svn by chance? :)
> > > Just did the conversion for portage branches for that...
> > > ~harring
> >
> > bingo :)
> >
> > I'll remove it
>
> You can do substitutions in svn too. You just need to enable it for the
> file. It's one of the svn:???? attributes.

$Header isnt supported though

i dont think we really need it ... it's never served any useful purpose and 
just been a pita to people running `etc-update`
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] init script guidelines

[Roy Marples]

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

On Wed, 2005-08-31 at 08:13 +0100, Roy Marples wrote:
> Attached is a patch to baselayout-1.12.0_pre6-r3 that allows this.
> Basically when an init script calls start-stop-daemon --start then we
> log what it started (and hopefully a pidfile) in
> ${svcdir}/daemons/${myservice}

in pre7 :)

-- 
Roy Marples <uberlord@gentoo.org>
Gentoo Linux Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] init script guidelines

[Francesco R]

Eric Brown wrote:

> Services that use Gentoo init scripts often report a status of [started] or   
>
> [OK] even though they fail to start.  The most recent bug like this that I've   
>
> found is with snort.  If you have a bad rule, snort will initialize, the   
>
> rc-scripts will give it an [OK] status, and then it will die once it parses the   
>
> rules.   
>
>     
>
> The real problem is not that the daemons don't return errors, but that our init   
>
> scripts do not make reasonable attempts to verify service startup.  If a Gentoo   
>
> init script claims that a service started, it should make an effort to check   
>
> that the processes are actually running shortly after the script is run, even if   
>
> start-stop-daemon says the parent process initialized.  Relying on the return   
>
> value of start-stop-daemon is simply insufficient for some services.   
>
>     
>
> I am aware that there are services that can monitor the status of other services   
>
> (app-admin/mon?) but I think this issue is a little different.  If an ebuild   
>
> developer is aware of an error condition can commonly occur shortly after a   
>
> daemon initializes, why not attempt to catch those errors?  Most of them could   
>
> probably be caught by simply checking to see if the process is still running   
>
> shortly after the script is run.   
>
>     
>
> I propose increasing developer awareness of this problem, perhaps through some   
>
> formal guidelines for ebuild developers.  At the very least, I would like to see   
>
> these bugs being acknowledged in bugs.gentoo.org instead of getting the same old   
>
> upstream/it's not our fault response.  We are responsible for our init scripts,   
>
> and they are important to our users.   
>
>     
>
> I have 2 ideas for the actual implementation:   
>
>     
>
> 1) Some kind of check() function in the init.d script, or a generic check() function   
>
> that just checks with ps | grep.  This might typically be called after having the   
>
> init script sleep for a certain amount of time.   
>
>     
>
> 2) Some kind of special init script that checks registered daemons after all services   
>
> have started. (i.e. it depends on all daemons, or they are put into it’s config file).   
>
> With this scheme we could avoid excessive sleeping during startup (to keep it fast),   
>
> And perhaps even keep using service specific check() functions   
>
>   
>
> Does anyone else think this idea is worth looking into?   
>

http://bugs.gentoo.org/show_bug.cgi?id=90471

We managed this checking for the socket mysql always create on *nix .
But whit a timeout of five seconds if there is no error message nor
socket in that time the script assume the server started.
I'm the first to say that this need to be improved but it's a start.


-- 
gentoo-dev@gentoo.org mailing list