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 GENTOO_MIRRORS="http://gentoo.oregonstate.edu/ http://www.ibiblio.org/pub/Linux/ distributions/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/ kde/3/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="" 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" COMPILER="gcc3" CHOST="powerpc-unknown-linux-gnu" CFLAGS="-O2 -pipe" CXXFLAGS="" ACCEPT_KEYWORDS="ppc" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="ccache" everything is latest for ARCH="ppc" (world is up to date, no config files in need of updating) This has been a long standing problem and is rather annoying, and affects all arches :)
Try /etc/init.d/* zap, that will reset the state of that service to stopped.
Thanks vlad, that worked, but I'm going to reopen this bug and assign away from ppc to Gentoo in general. 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 :)
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?)
This bug is quite old now. I wasn't able to reproduce it. Please reopen and advise if the problem persists.
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).
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 runscript.sh 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
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
i see what you mean ... start() and stop() functions should explicitly return state rather than just relying on the last command run ... yes ?
