custom services do not start in auto after upgrade to 9.04

[pico]

Hi!

I have 2 PC with installed some custom application (one of this is NAGIOS and the other is DEKIWIKI).

I have performed a double Upgrade on this 2 PC from 8.04 to 8.10 and then from 8.10 to 9.04.

Now, everythings seems ok, but some custom service (inside /etc/init.d/) that have to start at boot automatically, do not work!

I have checked also with BUM, but even if service is active, do not start anymore, after upgrade.

I also tryed to put the command inside the /etc/rc.local but even in this way the service do not start (seems thar rc.local is ignored!).

In details
For tha package Nagios, the behavior is like this : http://forums.meulie.net/viewtopic.php?f=61&t=4765&sid=dc19871c91e225cd0dc6b8d8c0d59012#p16227

For the DekiWiki package : Dekiwiki do not start in auto, but start manually, from command line!

Can somebody help me to solve or to investigate (wich log I have to watch?) this stange problem??

THX

PiCo

[Klaas1979 (klaas-prause)]

Please checkout the post: http://ubuntuforums.org/showthread.php?t=1144800 with additional information, especially of user digitalsushi. The post with more information:
We have a similar issue. On Ubuntu 9.04 and Kubuntu 9.04, we have an init.d script called from runlevel 2 for auto-start. We noticed that it doesn't run after the system is loaded. We replaced our service with a script that does nothing but report when signals are received. We learned that something (probably the parent process) sends a SIGHUP and then a SIGTERM to our program. We're not sure what it is. A workaround solution is to prefix your service with a "nohup" command (inside your init.d script, not of the script itself). If you're unfamiliar with nohup, it simply intercepts any SIGHUP signals sent by a parent and shields them from reaching your program. In our case, it allows our service to work in Ubuntu 9.04.

If anyone knows why the service is being sent these signals, we'd love to learn more. Thanks.

[windracer (windracer)]

I'm having the same problem with Nagios 3.1.0 after upgrading from 8.10 to 9.04. The nohup trick didn't work for me. If I run nagios straight from the command-line, without the daemon (-d) switch, I get this. Could it be related? I don't know what "stack smashing" is.

Nagios 3.1.0
Copyright (c) 1999-2009 Ethan Galstad (http://www.nagios.org)
Last Modified: 01-25-2009
License: GPL

Nagios 3.1.0 starting... (PID=3078)
Local time is Fri May 08 21:03:36 EDT 2009
*** stack smashing detected ***: ./nagios terminated
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7e98da8]
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x0)[0xb7e98d60]
./nagios[0x8083ba2]
./nagios(check_for_nagios_updates+0x6a)[0x8083c1a]
./nagios(main+0x552)[0x8058cc2]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7db1775]
./nagios[0x80586d1]
======= Memory map: ========
08048000-080d7000 r-xp 00000000 08:01 8308982 /usr/local/nagios/bin/nagios
080d7000-080d8000 r--p 0008e000 08:01 8308982 /usr/local/nagios/bin/nagios
080d8000-080d9000 rw-p 0008f000 08:01 8308982 /usr/local/nagios/bin/nagios
080d9000-080da000 rw-p 080d9000 00:00 0
09dd4000-09df5000 rw-p 09dd4000 00:00 0 [heap]
b752d000-b753a000 r-xp 00000000 08:01 4620341 /lib/libgcc_s.so.1
b753a000-b753b000 r--p 0000c000 08:01 4620341 /lib/libgcc_s.so.1
b753b000-b753c000 rw-p 0000d000 08:01 4620341 /lib/libgcc_s.so.1
b753c000-b754e000 r-xp 00000000 08:01 4621550 /lib/tls/i686/cmov/libresolv-2.9.so
b754e000-b754f000 r--p 00011000 08:01 4621550 /lib/tls/i686/cmov/libresolv-2.9.so
b754f000-b7550000 rw-p 00012000 08:01 4621550 /lib/tls/i686/cmov/libresolv-2.9.so
b7550000-b7552000 rw-p b7550000 00:00 0
b7552000-b7553000 ---p b7552000 00:00 0
b7553000-b7d53000 rw-p b7553000 00:00 0
b7d53000-b7d5d000 r-xp 00000000 08:01 4620537 /lib/tls/i686/cmov/libnss_files-2.9.so
b7d5d000-b7d5e000 r--p 00009000 08:01 4620537 /lib/tls/i686/cmov/libnss_files-2.9.so
b7d5e000-b7d5f000 rw-p 0000a000 08:01 4620537 /lib/tls/i686/cmov/libnss_files-2.9.so
b7d5f000-b7d68000 r-xp 00000000 08:01 4621542 /lib/tls/i686/cmov/libnss_nis-2.9.so
b7d68000-b7d69000 r--p 00008000 08:01 4621542 /lib/tls/i686/cmov/libnss_nis-2.9.so
b7d69000-b7d6a000 rw-p 00009000 08:01 4621542 /lib/tls/i686/cmov/libnss_nis-2.9.so
b7d6a000-b7d7f000 r-xp 00000000 08:01 4620480 /lib/tls/i686/cmov/libnsl-2.9.so
b7d7f000-b7d80000 r--p 00014000 08:01 4620480 /lib/tls/i686/cmov/libnsl-2.9.so
b7d80000-b7d81000 rw-p 00015000 08:01 4620480 /lib/tls/i686/cmov/libnsl-2.9.so
b7d81000-b7d83000 rw-p b7d81000 00:00 0
b7d83000-b7d8a000 r-xp 00000000 08:01 4620513 /lib/tls/i686/cmov/libnss_compat-2.9.so
b7d8a000-b7d8b000 r--p 00006000 08:01 4620513 /lib/tls/i686/cmov/libnss_compat-2.9.so
b7d8b000-b7d8c000 rw-p 00007000 08:01 4620513 /lib/tls/i686/cmov/libnss_compat-2.9.so
b7d96000-b7d97000 rw-p b7d96000 00:00 0
b7d97000-b7d99000 r-xp 00000000 08:01 4620461 /lib/tls/i686/cmov/libdl-2.9.so
b7d99000-b7d9a000 r--p 00001000 08:01 4620461 /lib/tls/i686/cmov/libdl-2.9.so
b7d9a000-b7d9b000 rw-p 00002000 08:01 4620461 /lib/tls/i686/cmov/libdl-2.9.so
b7d9b000-b7ef7000 r-xp 00000000 08:01 4620450 ...

[pico (pico-cocco)]

I'm also affected of this BUG::
https://bugs.launchpad.net/ubuntu/+source/gconf2/+bug/328575

maybe is related to the first problem.

[markba (mark-baaijens)]

This is not nagios specific. My vboxtool script (http://vboxtool.sourceforge.net/) which is started by the init.d system was not working anymore after an upgrade to Jaunty. I used the 'nohup' workaround and that solution works for me.

[pico (pico-cocco)]

I have Installed from scratch a new Ubuntu 9.04.. and then installed Nagios 3.0.6 from synaptic packages (not from source!!).

It works with no problem.
So I'm quite sure this problem is related to the upgrade process. But I have no idea on how to solve it.

Regards

[Greg (cebif)]

I have a similar problem with /etc/rc.local starting uninterruptible power supply monitoring software at boot.
Up to ubuntu 8.10 it would start automatically when I edited the rc.local file. In ubuntu 9.04 jaunty it doesn't work. ubuntu 9.04 is an upgrade from 8.10. As with the other users comments it was working fine in 8.10 which was an upgrade from 8.04.
I found a workaround, by stopping the graphical boot screen it seems to allow rc.local to start the software. I edited menu.lst:
title Ubuntu 9.04, kernel 2.6.28-15-generic
root (hd0,0)
kernel /boot/vmlinuz-2.6.28-15-generic root=UUID=915a4563-e2ee-4842-999f-f4c55be09bf8 ro quiet splash
initrd /boot/initrd.img-2.6.28-15-generic
quiet

quiet splash was deleted in the kernel line of this file, so everytime it boots the software starts now.
The thread of the problem is at:
http://ubuntuforums.org/showthread.php?t=1266614&page=2

[Fabio Marconi (fabiomarconi)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.
Is this bug reproducible with the latest Lucid packages ?
Thanks in advance.

[Greg (cebif)]

With the latest lucid packages the bug is gone for me.

[Fabio Marconi (fabiomarconi)]

Thanks for the reply
In accord with reporter's reply and assignation policies i mark as Invalid
:)Fabio

[Fabio Marconi (fabiomarconi)]

 Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage .

When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://help.ubuntu.com/community/ReportingBugs.

[Fabio Marconi (fabiomarconi)]

We'd like to figure out what's causing this bug for you, but we haven't heard back from you in a while. Could you please provide the requested information? Thanks!

[Greg (cebif)]

Is there anyway of reproducing this bug now? Unless still using an upgrade to ubuntu 9.04. The original reporter or anyone else that was affected might not be using an upgrade to 9.04.

[Fabio Marconi (fabiomarconi)]

Oops, i made a mistake.
#10 and #11 not valid.
Sorry
Fabio