Nut upsuser - Jun 2011 - Nut-upsuser Digest, Vol 72, Issue 21

Le 23/06/2011 14:00, nut-upsuser-request at lists.alioth.debian.org a ?crit
:
> Send Nut-upsuser mailing list submissions to
> 	nut-upsuser at lists.alioth.debian.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
> or, via email, send a message with subject or body 'help' to
> 	nut-upsuser-request at lists.alioth.debian.org
>
> You can reach the person managing the list at
> 	nut-upsuser-owner at lists.alioth.debian.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Nut-upsuser digest..."
>
>
> Today's Topics:
>
>     1. Re: Restarting NUT twice in the same time creates 2 instances
>        of usbhid-ups driver (Arjen de Korte)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 23 Jun 2011 11:53:46 +0200
> From: Arjen de Korte<nut+users at de-korte.org>
> To: nut-upsuser at lists.alioth.debian.org
> Subject: Re: [Nut-upsuser] Restarting NUT twice in the same time
> 	creates 2 instances of usbhid-ups driver
> Message-ID:
> 	<20110623115346.Horde.IpRfXUisJlFOAw0q00qnMAA at mail.de-korte.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes
>
> Citeren Rapha?l<raphael.broutin at ve-hotech.com>:
>
>> When reading /etc/init.d/nut, i see that when restarting nut, script
>> stop nut and start it again.
>> When starting again the driver is one more time started without any
>> verification that its already launched.
> Stopping a driver is an asynchronous process. So you either have to
> check if the PID file is removed before assuming the driver has
> actually stopped or you need to wait a couple of seconds before
> (re)starting the drivers.
>
>> I think there is a problem in code there.
> This is an inherent effect of the method that is used to signal
> drivers to stop. On systems with multiple driver instances, you don't
> want to hang around waiting for a driver to actually stop before going
> to the next one.
>
>> have you a solution to bypass this problem without rewriting
/etc/init.d/nut
> The easiest fix is to add a delay between
>
>      stop nut
>      sleep 2
>      start nut
>
> Best regards, Arjen
Testing PID before launching a new instance of driver is a good solution 
but need to be implemented in /etc/init.d/nut

The sleep solution is incorrect because if i do in parallel twice 
(stop,sleep,start). The two starts will be done at the same time ( i 
mean stop will be already done) and there will be 2 instance of driver.
Or i dont understand.

Testing PID before and launching new instance of driver if pid does not 
exist) sould be the right solution but only if  2 UPS needs 1 driver 
else this solution fails

Regards.


-- 
Rapha?l

Citeren Rapha?l <raphael.broutin at ve-hotech.com>:
> Testing PID before launching a new instance of driver is a good  
> solution but need to be implemented in /etc/init.d/nut
So, what's the big deal here? This is just a script on most (if not  
all systems) that can be modified easily. On the other had, changing  
the binaries is usually much more difficult.
> The sleep solution is incorrect because if i do in parallel twice  
> (stop,sleep,start). The two starts will be done at the same time ( i  
> mean stop will be already done) and there will be 2 instance of  
> driver.
Are you using 'upsdrvctl'? I fail to see the problem mentioned above,  
because 'upsdrvctl' will not start two drivers with identical names,  
so the problem can't occur (unless you're running 'upsdrvctl
start'
twice in a row).
> Or i dont understand.
Or I don't. Could you post your 'ups.conf' here? Are you trying to  
monitor two identical UPS devices?
> Testing PID before and launching new instance of driver if pid does  
> not exist) sould be the right solution but only if  2 UPS needs 1  
> driver else this solution fails
No, the name of the driver and UPS are in the PID filename, so we can  
easily check if that exists (in fact, the development version will do  
that). But this doesn't completely solve the problem, since this is  
prone to race conditions.

Best regards, Arjen
-- 
Please keep list traffic on the list (off-list replies will be rejected)