Suddenly start_daemon does not fork the new pid, hangs the script

Bug #532341 reported by Michael Lueck on 2010-03-05
This bug affects 1 person
Affects Status Importance Assigned to Milestone
lsb (Ubuntu)

Bug Description

Binary package hint: lsb

Suddenly software which uses start_daemon to launch a daemon process in the background caused an Ubuntu Server 8.10 not to completely reboot. The package that utilizes start_daemon is ooRexx: Open Object Rexx.

The startup script for the rxapid daemon does various checks to determine which way to launch the daemon. On 8.10, it selects start_daemon as that is available.

The script successfully launches the ooRexx rxapid daemon, as I can successfully interact with the daemon.

However, the script never ends, and that causes the server to never get to a login prompt on tty1.

I am successfully using /etc/rc.local to start rxapid, and have removed the service using: update-rc.d -f rxapid remove

This server used to boot normally. A kernel update caused me to need to reboot the server, thus I discovered this problem.

Michael Lueck (mlueck) wrote :

I was able to recreate this problem in a VirtualBox test environment.

Steps to recreate this situation:

1) Install Ubuntu Server 9.10
2) Apply all available updates
3) Reboot
4) Add openssh-server
5) ssh to the VM test server
6) use wget to DL the latest ooRexx for Ubuntu:
7) Install said package:
sudo dpkg -i ooRexx-4.0.0.i586.deb
8) Reboot
9) The rxapid process never forks, system will not complete booting on tty1

I also opened a bug report about this at the ooRexx project site:

"rxapid service suddenly not forking on Ubuntu Server 9.10"

As ooRexx 4.0 has been out for a while, it must be something in one of the latest Ubuntu updates as the package of ooRexx has not changed since it was last working correctly.

Michael Lueck (mlueck) wrote :

I guess I never rebooted this server since I had installed ooRexx.

Now I was able to recreate this problem on Ubuntu Server 9.10 without any updates applied.

Updating both tickets with this information.

Michael Lueck (mlueck) wrote :

This problem also affects the fully updated version of the Lucid Alpha.

For some reason when the operation system boots, it is unable to fork the daemon.

If I kill the daemon, then the start script does finish / exit, which cleans up the environment.

However manually starting stopping the service via:

sudo /etc/init.d/rxapid start
sudo /etc/init.d/rxapid stop

Which is the exact same script works as expected. The script starts the daemon and exists.

What happened with the upgrade to 9.10 that forking the daemon fails at boot-up but is able to succeed when the system is fully booted?

Looks to me like a definite Ubuntu problem, and not with ooRexx.

Updating both tickets with the same text.

Michael Lueck (mlueck) wrote :

Tested with a clean VM load of the Lucid alpha today - 20100312. Still the same problem.

At boot up, the start_daemon does not fork the new pid, hangs the script, prevents the machine from getting to the tty1 login prompt.

Kill the rxapi process, start script exits normally.

Manually start / stop the rxapid service normally.

Open Object Rexx is used on many systems I support, both Ubuntu desktops and servers.

I fail to see what is different about the service starting at boot-up verses once the OS is fully booted. Could someone kindly reply as to why this sudden non-fork behavior at bootup is occurring? Thank you.

Michael Lueck (mlueck) wrote :

The ooRexx developers figured out that this problem was due to a bug in how the C/C++ code was compiling. Some code specifically for AIX was ending up in the Linux builds. They are releasing an updated version, 4.0.1 soon that has this corrected. I have verified the fix on a 9.10 and 10.04 box.

You may now close this ticket.

Ma Hsiao-chun (mahsiaochun) wrote :

OK, close.

Changed in lsb (Ubuntu):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.