Bug 111347 – init.d service scripts fail on restart with several packages

• Product: Gentoo Linux
• Status: RESOLVED INVALID

[Description Chuck 2005-11-03 04:28:47 UTC]

With many packages, especially named and clamd which are variably slow to exit,  
when attempting /etc/init.d/servicename restart, causes the start portion to  
fail most if not all of the time.   
  
The problem lies with 2 places.   
   
if there is a restart() routine in the init script with no delay between stop   
and start, and if there is no restart() routine forcing runscript.sh to take   
over for restart.   
   
This is reproducable on many different machines all below 1ghz processor speed.   
I do not have faster machines available to test this with but I suspect it may   
work better on the faster machines.   
  
A 100% reliable solution is to modify runscript.sh in svc_restart to change the  
sleep 1 to sleep 4 and remove restart() from the init script, or add a sleep  
between its stop and start.  
  
Since I have removed the restart() routines from all scripts on all servers and  
modified /etc/init.d/runscript.sh for a sleep 4 in svc_resart I have never had  
a problem with restarting any service/application.  
   
I would have classified this as minor except that it severely affects those who 
use cron jobs to restart certain services for whatever reasons. They invariably 
fail without the additional delay time. 
   

Reproducible: Always
Steps to Reproduce:
1. /etc/init.d/named restart 
2. 
3. 
 
Actual Results:  
service fails to start 

Expected Results:  
it should start

[Comment 1 SpanKY 2005-11-03 19:15:32 UTC]

neglected to post `emerge info` like the bug report page told you to

adding random amounts of 'sleep' isnt acceptable

[Comment 2 Chuck 2005-11-03 21:21:40 UTC]

(In reply to comment #1)  
> neglected to post `emerge info` like the bug report page told you to  
>   
> adding random amounts of 'sleep' isnt acceptable  
  
fine.  here is for my workstation below. i can't post all 30 machines.. they  
are mostly all different mixtures of hardware with the same behavior. a sleep 4  
cures the problem totally and completely. your delay of sleep 1 simply is not  
enough time to allow some processes to be killed as some will not leave memory  
until they finish their current task. This behavior has always been there that  
I can remember but I simply did not have the time or inclination to fix it  
until now since in 3 years no one has bothered. And it is not just me, I have  
several friends around the globe who experience similar problems, and they  
replaced the sleep 1 with sleep 4 and it has cured their problems as well.  
  
emerge info report:  
  
  
 Portage 2.0.51.22-r3 (default-linux/x86/2005.1, gcc-3.3.6, glibc-2.3.5-r2, 
2.6.13.3-vs2.1.0-rc4 i686) 
================================================================= 
System uname: 2.6.13.3-vs2.1.0-rc4 i686 Pentium III (Coppermine) 
Gentoo Base System version 1.6.13 
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) 
[enabled] 
dev-lang/python:     2.3.5-r2, 2.4.2 
sys-apps/sandbox:    1.2.11 
sys-devel/autoconf:  2.13, 2.59-r6 
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 
sys-devel/binutils:  2.15.92.0.2-r10 
sys-devel/libtool:   1.5.20 
virtual/os-headers:  2.6.11-r2 
ACCEPT_KEYWORDS="x86" 
AUTOCLEAN="yes" 
CBUILD="i686-pc-linux-gnu" 
CFLAGS="-march=pentium3 -O3 -funroll-loops -fprefetch-loop-arrays -pipe" 
CHOST="i686-pc-linux-gnu" 
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/bind /var/qmail/control" 
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" 
CXXFLAGS="-march=pentium3 -O3 -funroll-loops -fprefetch-loop-arrays -pipe" 
DISTDIR="/usr/portage/distfiles" 
FEATURES="autoconfig distcc distlocks sandbox sfperms strict" 
GENTOO_MIRRORS="ftp://ftp.ussg.iu.edu/pub/linux/gentoo 
http://gentoo.seren.com/gentoo" 
LINGUAS="en_US" 
MAKEOPTS="-j8" 
PKGDIR="/usr/portage/packages" 
PORTAGE_TMPDIR="/var/tmp" 
PORTDIR="/usr/portage" 
SYNC="rsync://eron/gentoo-portage" 
USE="x86 X aac aalib aim alsa apm arts avi berkdb bitmap-fonts browserplugin 
cdparanoia cdr cpudetection crypt cups curl dga doc dts dv dvb dvd dvdr eds 
emboss encode esd fam flash foomaticdb fortran gd gdbm gif gnome gphoto2 gpm 
gstreamer gtk gtk2 gtkhtml icq imagemagick imlib java jikes jpeg kde ldap 
libg++ libgda libwww mad mikmod mmx motif mozilla mp3 mpeg msn ncurses nls 
nvidia ogg oggvorbis opengl oss pam pdflib perl pic pixmap png python qt 
quicktime readline real samba sdl slang spell sse ssl svga tcpd tiff truetype 
truetype-fonts type1-fonts udev usb vorbis win32codecs wmv xine xinerama xml2 
xmms xv yahoo zlib linguas_en_US userland_GNU kernel_linux elibc_glibc" 
Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY 
 
 
  

[Comment 3 Roy Marples (RETIRED) 2005-11-03 22:38:09 UTC]

We think that this issue has been resolved in the 1.12 branch for init scripts
that call start-stop-daemon (clamd and named do) - the latest in portage is
baselayout-1.12.0_pre9-r1.

I have no issues with restarting either named or clamd on slow and fast machines
using the 1.12 branch.

Reopen if baselayout-1.12.0_pre9-r1 does not fix this specific issue.