Suspend to RAM

[chriss]

I remember trying killing all SCREEN processes and then running the launch manager again from a script but for some reason this was not 100% bulletproof. I will revisit this soon when I have time. Any better ideas?

Just an idea: why not extend the launch manager to kill all devices before suspending and restart all devices after resuming? all the logic should be there (start/stop MD) just need to somehow connect it to suspend/resume.
Seems a cleaner solution - however I haven't researched it before.

/chriss

[colinjones]

hmmm... was thinking, why can't we just send a TERM or HUP signal (not KILL) to LaunchManager - surely all the devices are started as children processes to that, so this would cause them all to shutdown cleanly. However, on researching it a little I'm now confused as to how LM works.

Each device is initiated using the Spawn_Device script, and so each device's PPID is the particular instance of Spawn_Device's PID that started it. But each of those Spawn_Device's PPID is not LM, as I expected. It points to Init, suggesting that LM plays no part in starting devices - that doesn't seem right?! Unless the LM is simply monitoring the devices starting up, not actually doing the launching itself. Either way, the fact that you can use LM to stop and start the devices means that it must have a hook into the functionality somewhere...

[sambuca]

1) we are talking about engineering a complex (and not necessarily guaranteed, esp at the OS level of the TCP connection) way of sustaining TCP connections when it isn't necessary. The whole point of (LMCE) devices is that they can stop and start, disconnect and reconnect as required. Modularity. Why build this complex extra functionality into DCERouter code, when it is a more elegant and clean/tidy just to close the device connections at suspend, and reconnect on resume. Both require code changes, but the latter is much more bullet proof and tidy.

2) the retain-connections option cannot survive a core reboot, or even a DCERouter reload, so this case would have to be handled anyway... and the simplest way to handle this would be to implement the former option above... which would solve the issue in the first place....

I guess that reconnecting the device would also restart the TCP connection from the core to the MD (because there is two, isn't there? One core->device and one device->Core ?)
If that is the case, I totally agree with this proposal, it keeps it simple 

As colin mentions, sending the device process a signal could probably do it. Don't know if a process can provide a suspend/resume hook to the kernel, or if there is a special resume signal, but the SIGHUP signal seems like a good candidate (wikipedia says something like: SIGHUP tells programs to reload configuration and reinitialize).

If the signal approach is used, it could be done from both the resume scripts and from the launch manager. As the LM already knows which devices are present (and possibly which ones need restarting, if some don't), it makes sense to me to let it handle this.
This depends on how the LM works, but at least it should be possible to do some ps | grep and bash scripting to get the process IDs to send signal to, using the device id as a start.

sambuca

[colinjones]

Pretty sure there is more than one connection, at least one in each direction, from something I read in the wiki - but I caution, I remember Thom correcting my understanding on this, and I don't know if it was just me misinterpreting the wiki or if the wiki is actually incorrect. Either way, I can't quiet remember the detail of what Thom explained, but it was less connections than I thought.

I think the first approach should be to see if there is a programmatic way of triggering LM to shutdown the devices normally (as if you pressed the button in the LM window). If this isn't easy, then move onto the SIGHUP approach. It should be easy to "ps" and "grep" the spawn_device processes, and send them all a SIGHUP. But not sure how to restart them - again research into interfaces to LM would help.

And yes, I'm pretty certain that the kernel has hooks you can attach scripts for suspend/resume to... just can't recall exactly where