Bugzilla Bug 120904

mon is a system monitoring daemon. It starts and stops from a standard init
script. 

Recently, I noticed that while the stop script appears to execute properly with
out output as follows:
 * Service mon stopping
 * Service mon stopped

Nothing actually happens; mon is still running:
18642 ?        S      0:00 /usr/bin/perl /usr/sbin/mon -P /var/run/mon.pid -f

It appears that I can stop it manually using start-stop-daemon --stop, but this
 is not working from within the init script itself. 

I'm not sure this is a problem with mon per se, but something specific the how
start-stop-daemon works from within an init script, so I am presuming this to
some issue with a recently version of baselayout. I am running
baselayout-1.12.0_pre15.


emerge info:
Portage 2.0.54 (default-linux/amd64/2005.0, gcc-3.4.4, glibc-2.3.6-r2, 2.6.13
x86_64)
=================================================================
System uname: 2.6.13 x86_64 AMD Opteron(tm) Processor 250
Gentoo Base System version 1.12.0_pre15
dev-lang/python:     2.3.5-r2, 2.4.2
sys-apps/sandbox:    1.2.12
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.16.1
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r4
ACCEPT_KEYWORDS="amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/linux/distributions/gentoo"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/config/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="amd64 apache2 bitmap-fonts bzip2 cdr crypt eds encode expat gd gdbm gif
gpm imlib innodb jpeg libwww lm_sensors lzw lzw-tiff mhash mysql ncurses nls
nptl nptlonly pam pcre pdflib perl png qt readline samba sdl slang snmp ssl
tcltk tcpd udev userlocales vhosts xml2 xpm zlib userland_GNU kernel_linux
elibc_glibc"
Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS

Fixed in mon-0.99.2-r2

This bug was NEVER fixed. It is still present in mon-0.99.2-r4.

You'll have to re-submit your new emerge --info as it works for me using
baselayout-1.13 and mon-r4

System uname: 2.6.18-gentoo-r1 x86_64 AMD Opteron(tm) Processor 250
Gentoo Base System version 1.12.6
Last Sync: Fri, 15 Dec 2006 04:30:01 +0000
app-admin/eselect-compiler: [Not Present]
dev-java/java-config: 1.3.7, 2.0.30
dev-lang/python:     2.4.3-r4
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.60
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r3
sys-devel/gcc-config: 1.3.13-r4
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.18
ACCEPT_KEYWORDS="amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf
/etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo"
CXXFLAGS="-O2"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/linux/distributions/gentoo"
LINGUAS="en"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude='/distfiles' --exclude='/local' --exclude='/packages'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/config/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="amd64 apache2 cli cracklib crypt dlloader dri elibc_glibc gcc64 gdbm gpm
iconv innodb input_devices_evdev input_devices_keyboard input_devices_mouse
isdnlog kernel_linux libg++ linguas_en lm_sensors logrotate mailwrapper mysql
ncurses nls nolvm1 nptl nptlonly pam pcre perl ppds pppd readline reflection
sensord session snmp spl ssl tcpd truetype udev unicode userland_GNU vhosts
video_cards_apm video_cards_ark video_cards_ati video_cards_chips
video_cards_cirrus video_cards_cyrix video_cards_dummy video_cards_fbdev
video_cards_glint video_cards_i128 video_cards_i810 video_cards_mga
video_cards_neomagic video_cards_nv video_cards_rendition video_cards_s3
video_cards_s3virge video_cards_savage video_cards_siliconmotion
video_cards_sis video_cards_sisusb video_cards_tdfx video_cards_tga
video_cards_trident video_cards_tseng video_cards_v4l video_cards_vesa
video_cards_vga video_cards_via video_cards_vmware video_cards_voodoo xml zlib"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS,
PORTAGE_RSYNC_EXTRA_OPTS

Works fine with baselayout-1.12.8, please test with that version AND ensure you
etc-update.

I now have baselayout-1.12.8-r1 and it is still doing it.

The problem is specific to my 64-bit Opteron system, so it appears related to
how something is being compiled differently on 64 bit systems. Are you testing
with a 64-bit system?

This bug had been changed to NEEDINFO because presumably the maintainer doesn't
have a 64-bit system. Please pass this someone who can test and fix it.

I did test it on my amd64 and it works fine.

Weird. So any ideas on how to get to the bottom of it?

Unsure.

The only good thing that I can see is that the start-stop-daemon handling has
been vastly re-written for baselayout-2 (alpha3 in portage right now) so you
may want to see if that fixes it for you.

Let me know how that works.

Ha ha, this is funny. It does stop now, but on start, it claims

 * start-stop-daemon: /usr/sbin/mon died                                       
                                                      [ !! ]
 * ERROR: mon failed to start

but does indeed start. So the stop bug was fixed and a start bug took its
place. Should that be filed as a new bug?

I think this bug should be kept open until this new version of baselayout is
unmasked.

heh, i put a typo in the init script :
Fixed anyway. Re-open if you disagree.