Possible bug when relaunching App_Server

[chrisbirkinshaw]

In another thread in the feature requests forum (http://forum.linuxmce.org/index.php?topic=2689.0) we discussed suspend to ram/disk but ran into problems as the App_Server can often quit on resume. As I test I just tried issuing a "killall App_Server", then waited to see what happened. Issuing a "ps aux | grep App_Server" reveals that it did not restart so I tried manually:

screen -d -m -S App_Server-40 /usr/pluto/bin/Spawn_Device.sh 40 dcerouter App_Server

This is the result from the spawn log:

3       02/03/08 17:43:53       40 (spawning-device)    Device died... count=1/50 dev=40
Sun Feb  3 17:43:53 GMT 2008 died
========== NEW LOG SECTION ==========
1       02/03/08 17:44:07       40 (spawning-device)    Starting... 2
1       02/03/08 17:44:07       40 (spawning-device)    Found /usr/pluto/bin/App_Server
== ATTEMPT FRESH START ==
1       02/03/08 17:45:57       /usr/pluto/bin/Spawn_Device.sh 40 (spawning-device)     32616 Dev: 40; Already Running list: 40,41,43,42,44,45,48,46,47,
1       02/03/08 17:45:58       /usr/pluto/bin/Spawn_Device.sh 40 (spawning-device)     32616 Device 40 was marked as 'running'. Not starting
1       02/03/08 17:45:58       /usr/pluto/bin/Spawn_Device.sh 40 (spawning-device)     32616 Dev: 40; Exiting because not starting


So it does not start as the system thinks it is still running, however it is definitely not. How can I change this status, and what watchdog is supposed to be taking care of tracking this accurately?

Thanks,

Chris

[Zaerc]

Try removing the device-number from /usr/pluto/locks/pluto_spawned_local_devices.txt, for instance in your example you could try running:

Code Select Expand


sudo sed -e '/^40$/d' -i /usr/pluto/locks/pluto_spawned_local_devices.txt

The sudo won't be necessary if you're already root (like in a boot script).