Re: Powerdown notification
Re: Powerdown notification
- Subject: Re: Powerdown notification
- From: Eric Gouriou <email@hidden>
- Date: Wed, 20 May 2009 22:45:10 -0700
On May 20, 2009, at 10:38 AM, Matthew Mashyna wrote:
My client asked me to take this issue up again and I found an
acceptable solution. To recap... I have a Cocoa based daemon that
monitors, uh, "stuff" on client computers. This daemon regularly
checks in with a server to report the client's status. The problem I
was having was that when the system shuts down, the daemon wasn't
able to get the notification that a shutdown was imminent and report
the shutdown to the server.
I got a lot of suggestions about using IOKit and distributed
notifications. None of that stuff worked when my daemon was launched
from launchd. I started looking at catching the SIGTERM. I wasn't
able to catch it on shutdown until... I changed the launch daemon
plist to include this option: HopefullyExitsFirst
When HopefullyExitsFirst is turned on, the shutdown waits for my
daemon to exit and voila! I get the signal and have time to report
the shutdown. At least I think it waits. I'm not completely sure but
I get the result I am looking for.
Is it acceptable to slowdown every shutdown ? How long does it take
for the daemon
to handle the SIGTERM and exit ?
----------------
HopefullyExitsFirst <boolean>
This optional key causes programs to exit earlier during system
shutdown. This key exists because some
jobs do more than flush buffers and exit like they're supposed
to. The use of this key should be considered
a temporary solution until the software can be changed to only
flush dirty buffers and then exit.
----------------
The use of that key is discouraged and considered a kludge. I know
that Damien
would love to get rid of it. The semantics (carefully left
unspecified) may also change.
"earlier" is pretty vague, a 10ms headstart on the SIGTERM could be what
this will mean in a future release.
The not HopefullyExitsFirst case may not work for this daemon due to
dependencies
on other daemons which are being shutdown concurrently. A solution
would be to stop
relying on those services, or at the very least to stop relying on
those services to handle
the shutdown case.
Potential solutions:
- there could be a simplistic BSD-only daemon which just invokes
sigwait()
and notifies the server upon reception of SIGTERM.
- the server could understand that a severed connection implies a
shutdown.
- the daemon register a (WAN) Bonjour service and rely on
mDNSResponder
to handle the unregistration at shutdown for you.
It's difficult to provide advice given the dearth of information
about this daemon.
In general the mention of a "Cocoa based [launch] daemon" makes me
cringe.
Did you mean a Foundation-based daemon ?
At the very least I'd encourage you to file an enhancement request
stating
your needs and constraints.
Eric
Matt
On Mar 18, 2009, at 6:03 PM, Ethan Bold wrote:
Though your assumption is reasonable, those constants don't work.
IOKit doesn't send out messages for those.
-Ethan
On Mar 18, 2009, at 1:14 PM, Brian Bergstrand wrote:
On Mar 18, 2009, at 8:07 PM, Ethan Bold wrote:
Hi Matt-
IOKit does not provide any notifications of system shutdown. The
IORegisterForSystemPower() API call that you make below only
refers to system sleep & wake power events, not shutdown events -
the argument messageType may be kIOPMMessageCanSystemSleep,
kIOPMMessageSystemWillSleep, kIOPMMessageSystemWillNotSleep,
kIOPMMessageSystemHasPoweredOn, kIOPMMessageSystemWillPowerOn.
That's all - no messages sent on shutdown.
What about the following constants:
#define kIOMessageCanSystemPowerOff iokit_common_msg(0x240)
#define kIOMessageSystemWillPowerOff iokit_common_msg(0x250)
#define kIOMessageSystemWillNotPowerOff iokit_common_msg(0x260)
They exist in the headers so one assumes they will be sent.
Brian Bergstrand
<http://www.bergstrand.org/brian/> PGP Key ID: 0xB6C7B6A2
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden