Nut upsdev - Jan 2010 - nut vs. ModemManager and device stealing

Hi,

I'd like to know your opinion for bug 
http://bugzilla.redhat.com/show_bug.cgi?id=544121

Recently serial connected UPSes stopped working because ModemManager steals 
tty devices (it tries to open every tty device to check if there is modem 
sitting there), this means device is blocked for about 10 seconds. This 
prevents nut daemon to start. I've reassigned bug against ModemManager
because
I think it's its fault, but ModemManager maintainer says it nut fault,
because
nut should not give up to open device and it should retry later. What do you 
think? Some more details can be found in the bug comments.

Cheers,
Michal

On Jan 20, 2010, at 8:25 AM, Michal Hlavinka wrote:
> I'd like to know your opinion for bug
> http://bugzilla.redhat.com/show_bug.cgi?id=544121
>
> Recently serial connected UPSes stopped working because ModemManager  
> steals
> tty devices (it tries to open every tty device to check if there is  
> modem
> sitting there), this means device is blocked for about 10 seconds.  
> This
> prevents nut daemon to start. I've reassigned bug against  
> ModemManager because
> I think it's its fault, but ModemManager maintainer says it nut  
> fault, because
> nut should not give up to open device and it should retry later.  
> What do you
> think? Some more details can be found in the bug comments.
If ModemManager probes serial devices, IMHO it should be optional, and  
easy to disable. At the very least, there should be an option to block  
ModemManager from using a specific port.

Sending AT commands to an UPS is not well-defined. Some UPSes may  
handle this gracefully, but I think that if someone has an UPS  
connected to a system, the uptime requirements of the system are  
probably more important than the convenience of auto-detecting a modem.

We have auto-reconnect code for some USB devices (only after the  
device has been opened successfully, IIRC) and it is a mess. I  
personally don't think we should add similar complexity to the serial  
side of NUT, and if we do, it should be disabled by default.

-- 
Charles Lepple

Citeren Michal Hlavinka <mhlavink op redhat.com>:
> I think it's its fault, but ModemManager maintainer says it nut  
> fault, because
> nut should not give up to open device and it should retry later. What do
you
> think? Some more details can be found in the bug comments.
I would say the problem is with ModemManager (as already stated  
before). Sending a command and seeing what is returned, just isn't  
reliable. Microsoft and Hayes have attempted to standardize 'Serial  
PnP for COM devices' in the last decade of the previous century, but  
this wasn't hugely successful. Other than that, attempts to  
automatically detect devices on the serial port usually give rise to  
the same kind of interoperability problems as we see now.

The trouble we're seeing in NUT (and apcupsd too) is that the core  
electronics of many UPS devices in the field haven't essentially  
changed in the last two decades. Many devices that are on the market  
today still use serial controllers internally with a USB to serial  
controller tacked on to make them usable in an environment where we  
hardly see RS232 interfaces built in anymore. This is a legacy we (and  
ModemManager too) has to deal with. Given the wide variety of  
protocols used, there is no way to auto detect these. It is not  
uncommon to see UPS devices in the field that were manufactured two  
decades ago. If you periodically replace the batteries and do some  
preventive maintenance, there is no reason (other than inadequate  
available power requirements) to replace these old beasts. So unlike  
other computer hardware, we're likely to see these dinosaurs in  
service for quite a number of years to come.

Generally it is considered bad practice to just send a command and see  
if anything useful is returned on a serial interface. Therefor, NUT  
only supports hotplugging UPS devices for which we can unambiguously  
detect that they are supported. In case of USB connected devices, the  
VendorID:ProductID combination is usually a good indication. But even  
then, there are 'generic' models available that could be either a UPS,  
GPS or whatever (because the manufacturer was too cheap to apply for  
his own USB vendorid). And for the reasons already mentioned above,  
for serial connected UPS devices we never (will) support hotplugging.

Best regards, Arjen
-- 
Please keep list traffic on the list