Bug 104341

Summary:	daemon.terminate signal not emitted when receiving SIGTERM
Product:	[openSUSE] SUSE LINUX 10.0	Reporter:	Holger Macht <hmacht>
Component:	Mobile Devices	Assignee:	Holger Macht <hmacht>
Status:	VERIFIED FIXED	QA Contact:	E-mail List <qa-bugs>
Severity:	Minor
Priority:	P5 - None	CC:	dkukawka, trenn
Version:	Beta 1
Target Milestone:	---
Hardware:	Other
OS:	All
Whiteboard:
Found By:	Other	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Holger Macht 2005-08-12 09:09:33 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?

Comment 1 Holger Macht 2005-08-12 09:22:11 UTC

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.

Comment 2 Thomas Renninger 2005-08-12 09:45:41 UTC

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?

Comment 3 Thomas Renninger 2005-08-12 09:47:49 UTC

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...

Comment 4 Holger Macht 2005-08-12 09:52:27 UTC

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.

Comment 5 Holger Macht 2005-08-12 09:53:00 UTC

To #3: Yes, I already tried this way.

Comment 6 Thomas Renninger 2005-08-12 10:02:14 UTC

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.

Comment 7 Holger Macht 2005-08-12 10:06:27 UTC

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...

Comment 8 Timo Hoenig 2005-08-12 10:12:55 UTC

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

Comment 9 Holger Macht 2005-08-12 10:20:57 UTC

I will try...

Comment 10 Holger Macht 2005-08-12 11:27:58 UTC

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...

Comment 11 Holger Macht 2005-08-22 11:21:08 UTC

So I added this sleep for one second now.

However, the real problem could not yet be discovered.

Comment 12 Holger Macht 2005-08-22 11:25:19 UTC

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.

Comment 13 Holger Macht 2005-08-25 09:41:29 UTC

lowering severity because we have a workaround

Comment 14 Holger Macht 2005-09-06 08:13:01 UTC

While testing it more and more, I think this is a solution we can live with...