[Nut-upsdev] launchd plists

[Charlie Garrison]

Good morning,

On 13/03/10 at 11:06 AM -0500, Charles Lepple 
<clepple at gmail.com> wrote:

>On Mar 13, 2010, at 10:42 AM, Charlie Garrison wrote:
>
>>>Hopefully I will have some time later today to take a more 
>>>in-depth look at your original problem. On the other hand, if 
>>>the driver is working in debug mode, our efforts might be 
>>>better spent on creating a solid example launchd script for 
>>>running the driver.
>>
>>I'm working on that now. I'll send the one I'm using when I've 
>>got it ready.
>
>Excellent. Sounds like you are further along than I am...

I've attached some plist files for launchd.

>>Would you expect a different launchd plist for each of 
>>upsdrvctl, upsd and upsmon? That's the way I'm approaching it. 
>>Your thoughts would be appreciated.
>
>Well, due to the problem of "no USB connectivity unless in 
>debug mode", I don't think it will be useful to have one for 
>upsdrvctl. The problem is that upsdrvctl will not start the 
>driver in debug mode, so we will end up with your original issue.

Yep, I discovered that. I've created a plist for both upsdrvctl 
and upsdrvctl-debug. The debug plist loads the driver directly, 
and the ProgramArguments will need to be site-specific. And 
stderr is being sent to /dev/null; I didn't want to fill up my 
logs. (I've set upsdrvctl.plist to disabled, only one of 
upsdrvctl or upsdrvctl-debug should be enabled.)

>My reasoning for suggesting a launchd plist for the driver is 
>that launchd can respawn the driver if necessary - which would 
>be helpful in your case if the device disconnects. (However, I 
>seem to remember that you said the driver still reports "data 
>stale", which means it has not treated the error code as a 
>"device disconnection". We need to work on that.)

I don't believe I've had a 'data stale' error when running 
driver in debug mode. Or maybe I'm not following what you're saying.

>On the other hand, we may have some startup issues with upsd 
>and upsmon, especially if they start before networking is 
>available. For those, it might be better to create a 
>StartupItem for now.

Even though launchd doesn't really have any dependancy checking; 
I believe the following will work for ensuring *a* network 
interface is up:

     <key>RunAtLoad</key>
     <false/>
     <key>KeepAlive</key>
     <dict>
         <key>NetworkState</key>
         <true/>
     </dict>

Note, *a* network interface also includes local loopback, so 
that may not be good enough if upsd.conf doesn't specify IP 
address to bind to (since we may have network but no IP yet).


I've done very little testing with the attached plist files for 
launchd, but they are loading fine NUT seems to be doing its job.

Thanks,
Charlie

-- 
    Ꮚ Charlie Garrison ♊ <garrison at zeta.org.au>
    〠 PO Box 141, Windsor, NSW 2756, Australia

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
http://www.ietf.org/rfc/rfc1855.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: org.nut.upsdrvctl.plist
Type: application/octet-stream
Size: 455 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20100314/65756019/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: org.nut.upsdrvctl-debug.zip
Type: application/zip
Size: 938 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20100314/65756019/attachment.zip>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: org.nut.upsd.plist
Type: application/octet-stream
Size: 441 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20100314/65756019/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: org.nut.upsmon.plist
Type: application/octet-stream
Size: 445 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20100314/65756019/attachment-0002.obj>