Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 20228 - runscript and failed startups leave bad state
Summary: runscript and failed startups leave bad state
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Martin Schlemmer (RETIRED)
Depends on:
Reported: 2003-04-30 14:00 UTC by mark guertin
Modified: 2003-12-09 13:30 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description mark guertin 2003-04-30 14:00:26 UTC
if you execute /etc/init.d/* (pick an option) .. and it fails for any reason you are left with 
problems.  it should possibly flush out or ensure that the service did start correctly before 
it lables it as started.

Solution: reboot (not a great solution)

Reproducible: Always
Steps to Reproduce:
1. fire up any init script, make sure it fails at startup
2. try to stop it (won't happen cause there is no pid to stop)
3. try to stop or start that init script

Actual Results:  
ftpbox root # /etc/init.d/sendmail start
 * WARNING:  "sendmail" has already been started.
ftpbox root # /etc/init.d/sendmail stop 
 * Stopping sendmail...
sendmail: no process killed
ftpbox root # /etc/init.d/sendmail start
 * WARNING:  "sendmail" has already been started.

Expected Results:  
sendmail will start after the issues have been corrected.

Portage 2.0.47-r10 (default-ppc-1.4, gcc-3.2.1, glibc-2.3.1-r4)
System uname: 2.4.20-ppc-r4 ppc 
CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/
CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d"
USE="gpm jpeg mitshm motif ppc gdbm berkdb slang readline mysql tcpd pam libwww 
ssl perl -dvd -esd -gif -gnome -gtk -imlib -kde -mozilla -nls -oggvorbis -opengl -oss -png -
python -qt -sdl -truetype -X -xv"
CFLAGS="-O2 -pipe"

everything is latest for ARCH="ppc" (world is up to date, no config files in need of 

This has been a long standing problem and is rather annoying, and affects all arches :)
Comment 1 Graham Forest 2003-04-30 16:56:56 UTC
Try /etc/init.d/* zap, that will reset the state of that service to stopped.
Comment 2 mark guertin 2003-04-30 19:03:14 UTC
Thanks vlad, that worked, but I'm going to reopen this bug and assign away from ppc to Gentoo in 

if a service fails, it really should not register as started, and in this case it blatantly failed, therefore 
is still a bug in my eyes.

Thanks for the fast answer though :)
Comment 3 Pieter Van den Abeele (RETIRED) gentoo-dev 2003-06-13 03:52:29 UTC
reassigning to bugwranglers, this evolved into a gentoo-all-platforms suggestion/bugreport and should be assigned to the team maintaining the startupscripts. (azarah I think?)
Comment 4 Andrew Cooks (RETIRED) gentoo-dev 2003-12-08 08:40:12 UTC
This bug is quite old now. I wasn't able to reproduce it.

Please reopen and advise if the problem persists.
Comment 5 Mark Guertin 2003-12-08 09:50:08 UTC
I just verified this ...

Here's a simple way to reproduce:

1) edit an init script (any one, it doesn't matter) to somehow make sure that the launch fails , change a path etc ... (note: this applies to things that fail in normal procedures but this is easiest way to trigger this behaviour)

2) start with /etc/init.d/blah start

3) watch it fail to startup, then try to do /etc/init.d/blah stop .. at this point it will tell you that the service is already running when it is not.

To workaround you can do /etc/init.d/blah zap to 'reset' this init.

The point is that the inits should capture whether or not the process actually starts... right now they blidnly run a command and assume things are started and tells the system that they are in fact running (when they are not).
Comment 6 SpanKY gentoo-dev 2003-12-08 10:23:21 UTC
imo it's up to each script to tell runscript that it failed ...
usually this works because an init.d script is simple like this:
start() {
    ebegin "blah blah"
    <some app>
    eend $?
when eend is given a non-0 value it too returns the $? and since it is the last value start() returns the value $? at which point sets up the correct state

however, if you have something like 'eend 0' then the script will always fail to leave the init system in the correct state

to try and get runscript to detect the return values of all apps run in start() is just way more work than it's worth imo and that creates a bad state of things ... some scripts can work with the fact that something in start() errored and still recover correctly ...

please file a bug about each specific script/package that fails to work properly
Comment 7 Mark Guertin 2003-12-08 10:59:30 UTC
thnks but no thanks, not my problem.

if I filed bugs on all the bad init scripts it would be most if not all of them.  Not a single one I have on 3 machines does it the 'right way'.  it might be better IMHO to follow other OS models, and have the init scripts return success or failure as a monditory part of the design.

There are some that are done so badly it's scary , and I can't even use them any more.  For an example of how NOT to do things see the mysql init ... specifically the way it just _kills_ the PID for a stop (when there is in fact a command that should be used thats included with mysql)... this can result in lost data and corrupted tables on a kill style shutdown as this.

worksforme is quite inaccurate, I'm going to mark it as CLOSED instead.

anyway ... enjoy I suppose, ciao
Comment 8 SpanKY gentoo-dev 2003-12-09 13:30:16 UTC
i see what you mean ...

start() and stop() functions should explicitly return state rather than just relying on the last command run ... yes ?