init.d boot script not working after upgrade from 8.10 to 9.04

[usingruby]

After upgrading from ubuntu 8.10 to 9.04 a custom init.d script stopped to work. The script is perfectly working from a console if I login, but does not work in the startup process. I am not sure where I can find the correct logs to identify the error.

The boot script is attached. The user is my ubuntu user account. For me it looks like an authorization/access problem, because the script works after I have logged in.

* I added the script to the boot process via BUM and readded it after the upgrade to 9.04
* I tried to add this script to an other working boot up script (SqueezeCenter) the SqueezeCenter server is started so I am sure that the script is executed but the MusicIP service did not start up

Did something change in the start up process that needs to be taken care of?

I found this in a log:
Apr 29 07:50:19 erde su[13678]: Successful su for klaas by root
Apr 29 07:50:20 erde su[13678]: + ??? root:klaas
Apr 29 07:50:22 erde su[13678]: pam_unix(su:session): session opened for user klaas by (uid=0)
Apr 29 07:50:23 erde dbus-daemon: Rejected send message, 1 matched rules; type="method_call", sender=":1.34" (uid=1000 pid=6551 comm="/usr/lib/indicator-applet/indicator-applet --oaf-a") interface="org.freedesktop.DBus.Properties" member="Get" error name="(unset)" requested_reply=0 destination=":1.68" (uid=0 pid=13678 comm="su - klaas -c /usr/local/mmserver/MusicMagicServer"))
Apr 29 07:50:23 erde su[13678]: pam_unix(su:session): session closed for user klaas

Regards Klaas

[usingruby]

anyone has a tip where to look or what to read, to find out more? I would need a starting point to get this issue fixed.

Thank you very much
Klaas

[MaxIBoy]

I think Jaunty has put the login part sooner in the boot process. Try moving your custom script before gdm.

[usingruby]

this did not help, I moved it directly prior gdm, but I get the same messages in the "auth.log" I am wondering if this is the real error because the auth.log has many errors like this listed only for other commands.

[pico]

I have the sema scenario and the same problem. On 2 different PC.

Some custom services (nagios and dekiwiki in my case) do not start in automatic after reboot.
Since Ubuntu 8.04 I nave no problem with this services, but 9.04 seems to ignore the service and do not start it.

I have also no idea on direction to investigate....

[usingruby]

I don't know what happened, the new updates solved it for me! No errors in the auth.log, so it must be some changes from yesterdays updates Hopefully it stays this way!

[pico]

No WAY for ME!

Today Update do not solve the problem!

On one of 2 PC where I have problem (here I have installed nagios) I have this absurd situation:

pico@ubuntusrv1:~$ sudo /etc/init.d/nagios checkconfig
Running configuration check... OK.
pico@ubuntusrv1:~$ sudo /etc/init.d/nagios status
nagios is not running
pico@ubuntusrv1:~$ sudo /etc/init.d/nagios start
Starting nagios: done.
pico@ubuntusrv1:~$ sudo /etc/init.d/nagios status
nagios is not running
pico@ubuntusrv1:~$ ps -ef |grep nagios
pico      5113  4901  0 11:56 pts/0    00:00:00 grep nagios
pico@ubuntusrv1:~$

Logs give no help!
Can somebody help me please ??
ciao

[usingruby]

okay, removed the SOLVED status. Maybe you should fill a bug report with launchpad?

[digitalsushi]

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.

[usingruby]

I have no idea, it worked once (as posted before), then it stopped working again with no additional updates So the bug is still there and I have no idea why it was starting once. A different user reported the same on a different forum.

So maybe we should fill a bug report with nearly no information.