Bugzilla – Bug 104341
daemon.terminate signal not emitted when receiving SIGTERM
Last modified: 2007-06-05 10:01:38 UTC
Powersave daemon does not emit the PowersaveEvent daemon.terminate when it receives a SIGTERM. The corresponding functions are called. dbus_connection_send(...) is called properly but even a dbus_connection_flush(...) does not block afterwards as it should do. I think this is a timing problem because in very rare cases it is emitted. And trying with a debugger, it is emitted always. DBus_Server::emitSignal is called before DBus_Server destructor is called, so connection should not be closed before. But also nothing with dbus-monitor. At the moment, I do not know how to find the problem. Maybe Thomas can help me/us with that?
A workaround for kpowersave would be to directly listen to the DBus signal NameOwnerChanged (com.novell.powersave) to be able to switch to non daemon mode.
We should go for both: - try to find a workaround to let the daemon send it properly - learn kpowersave to deal with a real daemon breakaway A sleep (1) in the TERM signal handler (exit_handler(void), between delete pm and exit(0)) should give DBus time enough (yes, maybe not when system is really busy) to properly send the signal?
Hmm, it should be better to directly place it in the ~PM_Interface function directly after executeEvent("event.terminate"). Could be that we also exit other ways? This one should always be called if exiting...
This solves the problem but is not nice. And the reason why it fails is also not clear. We already have a sleep at daemon start, and now one at daemon termination, hmm. We should try to find another solution or the real reason for failure.
To #3: Yes, I already tried this way.
Don't care about exit time. Start is much more important. The reason is clear: While DBus tries to send the terminate signal, powersave daemon already ended up, all resources, including DBus connection and DBus callback functions are cleared. Maybe a flush_connection DBus function that blocks, exists? Otherwise you should just sleep this is not critical at all.
No. DBus_Server destructor is not called before sending the signal. And as mentioned in #1, dbus_connection_flush(...) should block until all messages have been processed, but it doesn't. Maybe dbus related problem, taking thoenig into CC...
Please use the debug packages of D-BUS to investigate (rpms located in ~thoenig/export/dbus- debug/). To get verbose debug output start the D-BUS daemon with: $ DBUS_VERBOSE=1 dbus-daemon --system --nofork
I will try...
Adding a sleep immediately after dbus_connection_flush(...) results in sending the signal properly. So dbus_connection_flush does not block as it ought to be. Timo is investigating it...
So I added this sleep for one second now. However, the real problem could not yet be discovered.
I assign the bug to me for now. Although I think it is a dbus problem. Will look at it more detailed as soon there is more time.
lowering severity because we have a workaround
While testing it more and more, I think this is a solution we can live with...