Bug 544121 - UPS devices should be blacklisted
UPS devices should be blacklisted
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: ModemManager (Show other bugs)
16
All Linux
low Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
: Reopened
: 537544 1011213 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-03 18:09 EST by Andre Robatino
Modified: 2013-09-24 11:39 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-13 21:38:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
boot.log (shows UPS driver controller failing to start) (3.55 KB, text/plain)
2009-12-08 11:13 EST, Andre Robatino
no flags Details
dmesg output (38.24 KB, text/plain)
2009-12-16 10:16 EST, Andre Robatino
no flags Details
upsboot.log (715 bytes, text/plain)
2009-12-16 10:27 EST, Andre Robatino
no flags Details
upsboot after adding "user=root" (315 bytes, text/plain)
2009-12-16 10:34 EST, Andre Robatino
no flags Details
boot.log (3.67 KB, text/plain)
2009-12-16 12:08 EST, Andre Robatino
no flags Details
output of "strace -f -o strace.txt modem-manager --debug" (927.56 KB, text/plain)
2009-12-18 02:54 EST, Andre Robatino
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 608022 None None None Never

  None (edit)
Description Andre Robatino 2009-12-03 18:09:49 EST
Description of problem:
I'm using an APC BackUPS 650 serial port UPS with a serial port to USB adapter.  The ups service fails to start at boot time, with the following in /var/log/messages:

Dec  3 17:13:24 localhost upsd[1624]: listening on 127.0.0.1 port 3493
Dec  3 17:13:24 localhost upsd[1624]: listening on ::1 port 3493
Dec  3 17:13:24 localhost upsd[1624]: Can't connect to UPS [ups] (genericups-ups
): No such file or directory
Dec  3 17:13:24 localhost upsd[1624]: allowfrom in upsd.users is no longer used
Dec  3 17:13:24 localhost upsd[1625]: Startup successful
Dec  3 17:13:24 localhost upsmon[1628]: Startup successful
Dec  3 17:13:24 localhost upsd[1625]: User monuser@::1 logged into UPS [ups]
Dec  3 17:13:24 localhost upsmon[1629]: Poll UPS [ups@localhost] failed - Driver
 not connected
Dec  3 17:13:24 localhost upsmon[1629]: Communications with UPS ups@localhost lost

However, I can start it manually after bootup.  I previously discussed this in bug #540225 where an selinux warning was fixed with a Koji version of selinux-policy, but I am still left with the failure of ups to start automatically.

Version-Release number of selected component (if applicable):
nut-2.4.1-8.fc12.x86_64

How reproducible:
always

Additional info:
Contents of /etc/ups/ups.conf:

[ups]
	driver = genericups
	port = /dev/ttyUSB0
	upstype = 9

I am using the same configuration and hardware which worked in F11.  The problem started after a clean install of F12.
Comment 1 Andre Robatino 2009-12-03 18:20:45 EST
See also bug #537544 where I have similar problems with the apcupsd service failing
to start at boot time when using apcupsd, but able to start it manually after that.
Comment 2 Michal Hlavinka 2009-12-08 08:39:37 EST
interesting

please add content of /var/log/boot.log

also try to move ups to start later during boot:
chkconfig ups off
edit /etc/init.d/ups
change line:

# chkconfig: - 26 74

to

# chkconfig: - 99 74

chkconfig ups on

and reboot. If it does help, add output of ls -l /etc/rc.d/rc5.d If it does not help, try this procedure with apcupsd (chkconfig apcupsd off, change first number on chkconfig line in /etc/init.d/apcupsd to 99, chkconfig apcupsd on).

thanks
Comment 3 Andre Robatino 2009-12-08 11:13:28 EST
Created attachment 376939 [details]
boot.log (shows UPS driver controller failing to start)
Comment 4 Andre Robatino 2009-12-08 11:44:03 EST
Procedure with /etc/init.d/ups did not help (3 ups startup lines simply occur at the end of boot.log but are unchanged, ups does not start during bootup).  Did not help with apcupsd either (boot.log shows no error messages, but apcupsd does not start during bootup, same messages in /var/log/messages including selinux error).
Comment 5 Andre Robatino 2009-12-08 15:22:31 EST
After the tests, I put everything back as before.  I just rebooted a few minutes ago, and for the first time, ups started automatically, with the following in /var/log/messages:

Dec  8 15:14:15 localhost genericups[1557]: Startup successful
Dec  8 15:14:15 localhost upsd[1559]: listening on 127.0.0.1 port 3493
Dec  8 15:14:15 localhost upsd[1559]: listening on ::1 port 3493
Dec  8 15:14:15 localhost upsd[1559]: Connected to UPS [ups]: genericups-ups
Dec  8 15:14:15 localhost upsd[1559]: allowfrom in upsd.users is no longer used
Dec  8 15:14:15 localhost upsd[1560]: Startup successful
Dec  8 15:14:15 localhost upsmon[1563]: Startup successful
Dec  8 15:14:15 localhost upsd[1560]: User monuser@::1 logged into UPS [ups]

I have no idea why it worked this time.  The last updates were applied before the earlier tests.  I'll try rebooting later to see if it's reproducible, and if so I'll try apcupsd also (I normally use ups).
Comment 6 Andre Robatino 2009-12-08 22:30:21 EST
Tried a few reboots with either apcupsd or ups enabled.  Apcupsd still fails to start with the same symptoms, but ups seems to reproducibly start now.  This is even though I restored both files in /etc/init.d/ to the original versions (verified with rpm -V apcupsd and rpm -V nut-client).  I haven't made any hardware changes.
Comment 7 Andre Robatino 2009-12-12 21:49:18 EST
Just experienced failure of ups to start at boot time.  So it's not 100% reproducible but still a problem.
Comment 8 Michal Hlavinka 2009-12-16 07:49:34 EST
This is odd. It seems there is some problem with usb-rs232 adapter on hw/kernel side. What is output of dmesg?

edit your /etc/init.d/ups

and change line 40:
from

daemon /sbin/upsdrvctl start > /dev/null  ....

to

daemon /sbin/upsdrvctl -DDDDD start > /dev/null  ....

and attach nut's part of /var/log/messages after reproducing the problem.



Then try to reproduce also after adding "user=root" as first line in /etc/ups/ups.conf this is just test if it helps/change anything, no need to attach any log if there are not big changes in behaviour (produced messages).

thanks
Comment 9 Andre Robatino 2009-12-16 09:35:32 EST
There is no ups-associated output in dmesg that I can find.  Adding the -DDDDD to /etc/init.d/ups appears to make no change in the /var/log/messages output.  When adding "user=root" to the beginning on /etc/ups/ups.conf, the only change I see is that the startup messages appear to show everything starting successfully, but in reality nothing has changed, and in /var/log/messages there is one additional line at the beginning:

Dec 16 09:26:04 localhost genericups[1644]: Startup successful
Dec 16 09:26:04 localhost upsd[1646]: listening on 127.0.0.1 port 3493
Dec 16 09:26:04 localhost upsd[1646]: listening on ::1 port 3493
Dec 16 09:26:04 localhost upsd[1646]: Can't connect to UPS [ups] (genericups-ups
): Permission denied
Dec 16 09:26:04 localhost upsd[1646]: allowfrom in upsd.users is no longer used
Dec 16 09:26:04 localhost upsd[1647]: Startup successful
Dec 16 09:26:04 localhost upsmon[1650]: Startup successful
Dec 16 09:26:04 localhost upsd[1647]: User monuser@::1 logged into UPS [ups]
Dec 16 09:26:04 localhost upsmon[1651]: Poll UPS [ups@localhost] failed - Driver
 not connected
Dec 16 09:26:04 localhost upsmon[1651]: Communications with UPS ups@localhost lo
st
Comment 10 Michal Hlavinka 2009-12-16 09:53:33 EST
> There is no ups-associated output in dmesg that I can find.

I'm not looking for ups-associated output, but to anything usb settlement related or anything "unusual"

> Adding the -DDDDD to /etc/init.d/ups appears to make no change in the /var/log/messages output. 

right, there is > /dev/null also, change that line to 

daemon /sbin/upsdrvctl -DDDDD start > /tmp/upsboot.log 2>&1 ....

and attach /tmp/upsboot.log
Comment 11 Andre Robatino 2009-12-16 10:16:22 EST
Created attachment 378773 [details]
dmesg output

(I reverted the previous changes so this is starting from scratch)
Comment 12 Andre Robatino 2009-12-16 10:27:39 EST
Created attachment 378779 [details]
upsboot.log

There were several upsboot.log-related selinux messages.  I don't know if these truncate the file.

SELinux is preventing /sbin/upsdrvctl access to a leaked /tmp/upsboot.log file descriptor.
SELinux is preventing /sbin/upsdrvctl "getattr" access on /tmp/upsboot.log.
SELinux is preventing /sbin/upsdrvctl "write" access on /tmp/upsboot.log.
SELinux is preventing /bin/plymouth access to a leaked /tmp/upsboot.log file descriptor.
Comment 13 Andre Robatino 2009-12-16 10:34:50 EST
Created attachment 378781 [details]
upsboot after adding "user=root"

Again, /var/log/boot.log appears to show ups starting normally, but in fact it doesn't.  I am also unable to start ups with "service ups start" which would normally work.
Comment 14 Andre Robatino 2009-12-16 10:37:31 EST
Actually I got the previous output after running "service ups start".  Before doing that, the file was different - it only had a few lines and appeared to show ups starting normally.
Comment 15 Michal Hlavinka 2009-12-16 11:47:36 EST
thanks, you can remove  "-DDDDD" from /etc/init.d and "user=root" from ups.conf if you still have it there

> There were several upsboot.log-related selinux messages.  
> I don't know if these truncate the file.

output is probably truncated, but we don't need the missing part for now

"""Unable to open /dev/ttyUSB0: Device or resource busy"""

this means device is not ready (yet) or used by something else

please try to add 

fuser -u /dev/ttyUSB0 || echo "device not used"

just before the "daemon /sbin/upsdrvctl start" line

output will be in /var/log/boot.log

if device is not used, please add output of lsusb -v and lshal

thanks
Comment 16 Andre Robatino 2009-12-16 12:08:00 EST
Created attachment 378795 [details]
boot.log

[andre@compaq-pc ~]$ ps -A | grep 1515
 1515 ?        00:00:00 modem-manager
Comment 17 Michal Hlavinka 2009-12-17 05:40:12 EST
right, modem-manager is stealing our ups device, reassigning bug to ModemManager

Description of problem:
modem manager is stealing /dev/ttyUSB0 device where UPS is connected. This breaks ups controller daemons (nut and apcupsd).

How reproducible:
always

steps to reproduce:
1) have UPS connected via usb-rs232 adapter
2) configure ups daemon
3) reboot

actual result:
ups daemon fails to start, because device is already used
fuser -u /dev/ttyUSB0 (placed in ups daemons init script)
> /dev/ttyUSB0:         1515(root)
ps -A | grep 1515
> 1515 ?        00:00:00 modem-manager  

expected result:
device is not used by modem manager so ups daemon can start successfully
Comment 18 Dan Williams 2009-12-17 11:15:52 EST
Does the UPS respond to AT commands?  ModemManager probe serial ports for mobile broadband capabilities using standard AT commands, and if the device doesn't respond or has no mobile broadband capabilities, ModemManager will ignore it.

You can run modem-manager --debug and get more information about what's going on including serial dumps.
Comment 19 Andre Robatino 2009-12-17 12:39:44 EST
Could you explain in more detail how to get this information?

[andre@compaq-pc ~]$ modem-manager --debug

** (modem-manager:17832): WARNING **: Could not acquire the org.freedesktop.ModemManager service.
  Message: 'Connection ":1.208" is not allowed to own the service "org.freedesktop.ModemManager" due to security policies in the configuration file'
[andre@compaq-pc ~]$
Comment 20 Dan Williams 2009-12-17 12:55:41 EST
All as root:

1) service NetworkManager stop
2) killall -TERM modem-manager
3) modem-manager --debug

thanks!
Comment 21 Andre Robatino 2009-12-17 12:59:19 EST
[root@compaq-pc ~]# modem-manager --debug
** Message: Loaded plugin Sierra
** Message: Loaded plugin Huawei
** Message: Loaded plugin Option High-Speed
** Message: Loaded plugin Novatel
** Message: Loaded plugin Option
** Message: Loaded plugin Gobi
** Message: Loaded plugin MotoC
** Message: Loaded plugin ZTE
** Message: Loaded plugin Ericsson MBM
** Message: Loaded plugin Generic
** Message: Loaded plugin Nokia
** Message: (ttyUSB0) opening serial device...
** (modem-manager:19588): DEBUG: (ttyUSB0): probe requested by plugin 'Generic'
** (modem-manager:19588): DEBUG: (ttyUSB0): <-- '\-1'
** (modem-manager:19588): DEBUG: (ttyUSB0): --> 'AT+GCAP<CR>'
** (modem-manager:19588): DEBUG: (ttyUSB0): <-- 'AT+GCAP<CR>'
** (modem-manager:19588): DEBUG: (ttyUSB0): --> 'AT+GCAP<CR>'
** (modem-manager:19588): DEBUG: (ttyUSB0): <-- 'AT+GCAP<CR>'
** (modem-manager:19588): DEBUG: (ttyUSB0): --> 'AT+GCAP<CR>'
** (modem-manager:19588): DEBUG: (ttyUSB0): <-- 'AT+GCAP<CR>'
** Message: (ttyUSB0) closing serial device...
Comment 22 Andre Robatino 2009-12-17 13:02:37 EST
Not sure if it matters but the ups service is currently running.  If necessary I could stop that and run modem-manager --debug again.
Comment 23 Andre Robatino 2009-12-17 13:10:54 EST
There was a fairly long interval between opening and closing the serial device.  Maybe the ups service sees that it's locked during startup and gives up before modem-manager finally gets around to releasing it?
Comment 24 Dan Williams 2009-12-17 17:03:57 EST
(In reply to comment #23)
> There was a fairly long interval between opening and closing the serial device.
>  Maybe the ups service sees that it's locked during startup and gives up before
> modem-manager finally gets around to releasing it?  

How long is that interval?  I'm tracking an issue that just showed up with 2.6.31 (doesn't happen on 2.6.30 *at all*) where sometimes even though MM used O_NONBLOCK the read/write calls will block for a long time.  Still trying to figure out what's going on here.
Comment 25 Andre Robatino 2009-12-17 17:10:49 EST
Over 10 seconds.  That's comparable to the entire bootup time, and in the startup messages, the ups service appears to give up immediately when it sees the device is unavailable.
Comment 26 Dan Williams 2009-12-17 17:39:21 EST
(In reply to comment #25)
> Over 10 seconds.  That's comparable to the entire bootup time, and in the
> startup messages, the ups service appears to give up immediately when it sees
> the device is unavailable.  

That's a pretty dumb ups service...  I have a few ideas here but I need to try them out with all my modems; any chance you can strace modem-manager when it's "hung" or gdb attach to it at that point and grab a backtrace?
Comment 27 Andre Robatino 2009-12-18 02:54:54 EST
Created attachment 379161 [details]
output of "strace -f -o strace.txt modem-manager --debug"

OK, I did the following as root:

service ups stop
service NetworkManager stop
killall -TERM modem-manager
strace -f -o strace.txt modem-manager --debug

and got the following:

[root@compaq-pc ~]# strace -f -o strace.txt modem-manager --debug
** Message: Loaded plugin Sierra
** Message: Loaded plugin Huawei
** Message: Loaded plugin Option High-Speed
** Message: Loaded plugin Novatel
** Message: Loaded plugin Option
** Message: Loaded plugin Gobi
** Message: Loaded plugin MotoC
** Message: Loaded plugin ZTE
** Message: Loaded plugin Ericsson MBM
** Message: Loaded plugin Generic
** Message: Loaded plugin Nokia
** Message: (ttyUSB0) opening serial device...
** (modem-manager:3311): DEBUG: (ttyUSB0): probe requested by plugin 'Generic'
** (modem-manager:3311): DEBUG: (ttyUSB0): <-- '\-4'
** (modem-manager:3311): DEBUG: (ttyUSB0): <-- '\-2'
** (modem-manager:3311): DEBUG: (ttyUSB0): --> 'AT+GCAP<CR>'
** (modem-manager:3311): DEBUG: (ttyUSB0): <-- 'AT+GCAP<CR>'
** (modem-manager:3311): DEBUG: (ttyUSB0): --> 'AT+GCAP<CR>'
** (modem-manager:3311): DEBUG: (ttyUSB0): <-- 'AT+GCAP<CR>'
** (modem-manager:3311): DEBUG: (ttyUSB0): --> 'AT+GCAP<CR>'
** (modem-manager:3311): DEBUG: (ttyUSB0): <-- 'AT+GCAP<CR>'
** Message: (ttyUSB0) closing serial device...
^C** Message: Caught signal 2, shutting down...

Contents of strace.txt attached.
Comment 28 Dan Williams 2010-01-02 19:40:38 EST
Can you try the packages here?

http://koji.fedoraproject.org/koji/buildinfo?buildID=149089

They fix a specific issue with unresponsive serial ports that could be blocking
ModemManager in your case.
Comment 29 Andre Robatino 2010-01-02 20:07:34 EST
No change, ups still unable to start at boot time.
Comment 30 Dan Williams 2010-01-06 00:17:59 EST
That build should ensure that ModemManager won't wait excessively long for the device to respond, but it's still up to the UPS service to try again and not just fail the first time.  If modem-manager was hanging for a long time while sending the AT+GCAP commands, that updated build should fix it.
Comment 31 Andre Robatino 2010-01-06 03:18:42 EST
I ran the commands in comment #27 again with koji's ModemManager and it takes about the same time (over 10 seconds) before closing the device as before.
Comment 32 Michal Hlavinka 2010-01-18 10:36:21 EST
*** Bug 537544 has been marked as a duplicate of this bug. ***
Comment 33 Dan Williams 2010-01-18 18:24:45 EST
Yeah, each GCAP request is set to a 3 second timeout.  So a total of 4 requests at about 3 seconds is 12 seconds to find out the device is not a modem.

So I'm not really sure what the issue here is any longer...  the bug in MM has been fixed that would cause MM to hold the port open excessively long.   But apparently there's still a bug in the UPS service where it just fails without trying to open the port again if the port isn't available the first time.  That bug should be fixed in the UPS service.

Future versions of ModemManager will cut the # of GCAP tries down to 3 for a total of about 9 seconds, but having the UPS service depend on timing of the port becoming available without retrying is also quite fragile.  It simply needs to retry a few times until it either gets the UPS's port, or gives up.  But more than once.
Comment 34 Michal Hlavinka 2010-01-19 10:56:46 EST
Could you explain me this not a bug, please?

There are two ups packages, nut and apcupsd. Both of them were working correctly until ModemManager came. They use only one serial port and this port *must* be explicitly set by user. On the other hand (my knowledge of MM is limited) ModemManager asks every serial device making it unavailable for about ten seconds but the service, the one being explicitly configured, but blocked by NM, is buggy?? It sends some commands to anything it founds connected to serial port. I don't know if there is some rfc or something that any device must tolerate these commands, but some electronic technical device can do some pretty mess because they don't work with any protocol that is tolerant to 'foreign language'.

In my opinion MM needs a fix, it should use only explicitly set/last time used device or probe all devices only when user asks this.
Comment 35 Dan Williams 2010-01-19 19:51:27 EST
(In reply to comment #34)
> Could you explain me this not a bug, please?
> 
> There are two ups packages, nut and apcupsd. Both of them were working
> correctly until ModemManager came. They use only one serial port and this port

They were working as they had been for a long time, but that's not necessarily "correctly".

> *must* be explicitly set by user. On the other hand (my knowledge of MM is

In a perfect world it doesn't need to be set explicitly by the user if the UPS control software detected the device based on USB VID/PID or USB serial number or whatever.  It could be set explicitly, but it doesn't need to be.

The point here is that the rest of the world is getting smarter about device detection and making it more automatic, but apparently the UPS software is not... 

Your UPS will not always be the same tty because USB bus enumeration is *not* stable.  It depends on port position and how many devices are plugged into that USB controller.  If you plug *any* other USB serial device into the system, it's possible that your UPS device will move ttys and oops, your configuration is now busted.

That's one reason the software needs to be smarter.  There are a limited number of USB-enabled UPS models, and it's highly unlikely that any USB device with the vendor ID 051d (APC's USB vendor ID) is *not* a UPS.  So why doesn't the UPS software just look for known UPS devices instead of making you specify it explicitly?  If you have more than one UPS plugged into your computer then ideally the UPS exports a unique USB serial number that you can use instead of a tty name.

That all has nothing to do with ModemManager, but is simply an observation of why the UPS daemons need an update to bring them in to the 2000s instead of the 1990s.  If my understanding of how they operate is correct.

> limited) ModemManager asks every serial device making it unavailable for about
> ten seconds but the service, the one being explicitly configured, but blocked
> by NM, is buggy?? It sends some commands to anything it founds connected to

It's explicitly configure in the *UPS service configuration*.  Other programs have no way of knowing that the UPS service is looking for that device.  That's just the way the world works.  We don't expect ModemManager to parse every UPS program's configuration file just to find out if there is a tty specified there.

The UPS program itself has got to be smarter about how it operates, including perhaps retrying device detection if the port is not available initially.  The only reason you didn't run into this in F10 and F11 was that modem probing was done at udev time, before the tty was available to the rest of the system.  That was undesirable for other reasons, and the probing was moved into ModemManager instead of being a udev helper.

> serial port. I don't know if there is some rfc or something that any device
> must tolerate these commands, but some electronic technical device can do some
> pretty mess because they don't work with any protocol that is tolerant to
> 'foreign language'.
> 
> In my opinion MM needs a fix, it should use only explicitly set/last time used
> device or probe all devices only when user asks this.    

That totally breaks hardware hotplug, and thus is undesirable.  The real fix is to fix the UPS daemon to retry it's own hardware detection to be more robust.


I'm happy to add rules to ModemManager that make it ignore devices when the *device itself* has issues with probing, which some devices do.  But the problem here is in the UPS software running on the host, not the device.  And that's software we can fix.  Which we should do.
Comment 36 Dan Williams 2010-01-19 20:16:50 EST
For example, apcupsd seems especially dumb WRT to hardware detection.  If you explicitly configure a port, the call path looks like:

pusb_ups_open()
   open_usb_device()
       for (i = 0; i < 10; i++) {
           <try to open device>
           <wait one second if it fails, otherwise success>
       }

and that's apparently where it stops.  Why doesn't it try again every 30 seconds after that?  It looks like it has logic to recover a temporarily unplugged device, but only after it's opened it successfully the first time.

I'd expect that if you plug the UPS device in *after* starting the daemon that it also fails to detect it and requires a daemon restart to find the device?

It looks like main() calls setup_device(), which calls device_open() which eventually calls pusb_ups_open().  So yeah, apcupsd doesn't deal with hardware hotplug *at all*.  Pretty dumb.  It probably needs to get smarter.
Comment 37 Dan Williams 2010-01-19 20:23:31 EST
nut does not appear to retry for the port *at all*.  (main() -> upsdrv_initups() -> ser_open() -> fail)
Comment 38 Michal Hlavinka 2010-01-20 07:30:44 EST
well, It's not usual use case you plug ups later, because it means you have to unplug your computer's power cord first. I definitely don't know why it should retry opening ups later. I don't expect dhcp, bind, ... to start when there is (for example usb plugged) ethernet card missing and just sitting and waiting if it's there after a while...

I'll ask upstream for their opinion.
Comment 39 Dan Williams 2010-01-20 16:56:01 EST
You can certainly have the computer plugged into the UPS's power socket, but not have the USB cable plugged into *that* computer yet.  Or, you could have a laptop that you use to diagnose UPS issues that you plug the UPS into periodically but normally leave the UPS unplugged.  Or whatever.

Or what if you already have a running UPS daemon, and you want to monitor a second UPS?  Same case.  Neither of these programs handle that.
Comment 40 Michal Hlavinka 2010-01-21 07:46:15 EST
> Or what if you already have a running UPS daemon, 
> and you want to monitor a second UPS?  Same case.
> Neither of these programs handle that

you have to specify what device is it, because some devices use incompatible protocols and also can do some weird things when you send them wrong / unknown command (see the info about reset from upstream)

So far I did not get all responses to my emails, but so far I've got:

<my email>
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
</my email>
-----------------------------------------------------------
<response #1>
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.
</response #1>

-----------------------------------------------------------

<response #2>
+1

*I'm fairly certain that some contact closure UPS devices consider a  
probing sequence as a signal to shutdown the load. You definitely  
don't want that to happen.*

I'm also quite sure that based on the VID:PID combination of the  
prospective modem, ModemManager should be able to figure out if a  
device could be a modem or an ordinary USB to serial converter that is  
not known to be a (wireless) modem. Like NUT doesn't probe known  
non-UPS devices, neither should ModemManager.
</response #2>

-----------------------------------------------------------

<response #3>
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.*
</response #3>
Comment 41 Michal Hlavinka 2010-01-21 09:02:10 EST
<response #4>
I intended to add the link to the "Plug and Play External COM Device  
Specification" document, but forgot to do so. Here it is:

http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/pnpcom.rtf

Many of the design considerations in here are still valid today.
</response #4>

some randomly found parts from the document mentioned above:

<snip>
B.3	Serial Printers and other devices

Other serial devices may be smart (like modems) or dumb.  Modem control commands may be ignored by some devices, but misinterpreted by others.  For example, a non-Plug and Play serial printer would likely print out an "AT<tell_me_your_ID> command on a fresh page, which would annoy the user while failing to elicit a Plug and Play ID.
</snip>

<snip>
B.4	Uninterruptible Power Supplies

Some computer systems need to run reliably, unattended, even in the presense of transient AC power outages; network servers are an obvious example.  Many of these are connected to Uninterruptible Power Supplies (UPS).

For control reasons, some of these UPS devices are connected to the dependent PC through a serial port.  Unfortunately, it is common to connect these devices to the standard serial control leads in non-standard ways.  The effect is that in some cases, the Serial enumerator could shut down the power in the UPS under unusual circumstances.
</snip>
Comment 42 Dan Williams 2010-01-29 15:03:14 EST
We're tracking an issue upstream for blacklisting various devices that don't respond well to probing either and I expect the same mechanism can be used here for devices that would turn off load when probed.  I'm not very sympathetic to dumb UPS software, but I'm certainly not opposed to blacklisting devices that are known to take probing badly.  With that in mind, re-opening and retitling the bug.
Comment 43 Dan Williams 2010-04-09 22:41:12 EDT
I blacklisted all the UPS devices I could find IDs for in nut in upstream MM git master.  If there are other devices, lets open new bugs for them and get them added.
Comment 44 Andre Robatino 2010-05-27 21:33:43 EDT
I hadn't seen this problem for months, but immediately after clean installing F13, the ups service isn't starting at boot again.  But I can start it manually afterwards, as before.
Comment 45 Marc Wilson 2011-01-11 23:12:20 EST
I found today after installing F14 that my X10 home controller, a serial device connected to ttyUSB0 via a USB-to-RS232 adapter, no longer worked.

The X10 control application would block on opening the tty.

Investigating the log:

Jan 10 10:55:16 dell kernel: [    8.140123] USB Serial support registered for pl2303
Jan 10 10:55:16 dell kernel: [    8.140162] pl2303 6-2.4:1.0: pl2303 converter detected
Jan 10 10:55:16 dell kernel: [    8.151917] usb 6-2.4: pl2303 converter now attached to ttyUSB0

And later:

Jan 10 10:55:19 dell modem-manager: (ttyUSB0) opening serial device...
Jan 10 10:55:33 dell modem-manager: (ttyUSB0) closing serial device...
Jan 10 10:55:33 dell modem-manager: (ttyUSB0) opening serial device...
Jan 10 10:55:33 dell kernel: [  113.433124] usb 6-2.4: pl2303_read_int_callback - usb_submit_urb failed with result -1
Jan 10 10:55:39 dell modem-manager: (ttyUSB0) closing serial device...

So it tries twice for some reason.

After this, any attempt to read or write the tty blocks indefinately.

So I added all the USB-to-serial devices I have lying around to be blacklisted:

# Belkin F5U183 Serial Adapter
ATTRS{idVendor}=="050d", ATTRS{idProduct}=="0103", ENV{ID_MM_DEVICE_IGNORE}="1"

# ATEN Intl UC-232A (Prolific)
ATTRS{idVendor}=="0557", ATTRS{idProduct}=="2008", ENV{ID_MM_DEVICE_IGNORE}="1"

# Prolific Technology PL203 Serial Port
ATTRS{idVendor}=="067b", ATTRS{idProduct}=="2303", ENV{ID_MM_DEVICE_IGNORE}="1"

I'm sure someone somewhere has a serial modem plugged into one of these, or one like it.  Heck, *I* have an old Courier modem plugged into one.  But that doesn't mean I want modem-manager trying to talk to it.
Comment 46 Marc Wilson 2011-01-11 23:14:25 EST
Of course, this isn't a UPS.  But this seems to be the bug where blacklisting devices for modem-manager is being discussed.
Comment 47 Dan Williams 2011-01-24 13:38:41 EST
(In reply to comment #46)
> Of course, this isn't a UPS.  But this seems to be the bug where blacklisting
> devices for modem-manager is being discussed.

Right; however the problem is that sometimes modem vendors will use a generic serial-to-USB chip like the Prolific ones as the mechanism to bridge the modem to USB, and of course we have no idea what's behind it.  I'm not really sure how to fix that situation.  I'm willing to blacklist non-prolific ones by default for now though.

For example, like this:

http://forum.eeeuser.com/viewtopic.php?id=28994
Comment 48 Dan Williams 2011-01-24 13:39:25 EST
I've blacklisted the first two devices upstream as:

12f1b351e83730c7d5fa882f0fbbaf4b19816a00
Comment 49 Bug Zapper 2011-06-02 13:12:57 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 50 Bug Zapper 2011-06-27 10:38:19 EDT
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 51 Eddie Lania 2011-12-21 12:59:26 EST
Can somebody please reopen this bug? I am hitting the problem with the apcupsd not starting because of the ttyS1 being locked by ModemManager too, and I really don't know how to blacklist this tty in ModemManager.

Using a newly installed Fedora 16 on a production machine, the ups is critical.

Thank you.
Comment 52 Andre Robatino 2011-12-21 13:52:07 EST
Reopening. I'm using a USB UPS now so can't help in testing, though.
Comment 53 Eddie Lania 2012-01-01 15:01:07 EST
I am hitting the problem with the apcupsd not starting because of the ttyS1 being locked by ModemManager too.

I really don't know how to blacklist this tty in ModemManager.

Can somebody please help me with this?
Comment 54 Dan Williams 2012-07-20 19:39:27 EDT
(In reply to comment #53)
> I am hitting the problem with the apcupsd not starting because of the ttyS1
> being locked by ModemManager too.
> 
> I really don't know how to blacklist this tty in ModemManager.
> 
> Can somebody please help me with this?

We need to figureo out what driver is driving your device.  Do the following:

cd -P /sys/class/tty/ttyS1/device
ls -al driver

that'll show something like:

lrwxrwxrwx. 1 root root 0 Jul 20 08:03 driver -> ../../../bus/pci/drivers/serial

which in this case means the 'serial' driver.  Then we blacklist that device by dropping a file containing the following into /etc/udev/rules.d and we either restart, or we run "sudo udevadm trigger" to get the rule change to take effect.

ACTION!="add|change", GOTO="mm_tty_blacklist_end"
SUBSYSTEM=="pci", DRIVERS=="serial", ENV{ID_MM_DEVICE_IGNORE}="1"
LABEL="mm_tty_blacklist_end"
Comment 55 Andre Robatino 2012-07-20 20:08:12 EDT
Changing the needinfo email since I now use a USB UPS and can't help with testing.
Comment 56 Eddie Lania 2012-08-09 09:38:40 EDT
"Then we blacklist that device by dropping a file containing the following into /etc/udev/rules.d"

What filename?

I have in /etc/udev/rules.d:

ls /etc/udev/rules.d/
60-fprint-autosuspend.rules  70-persistent-cd.rules  90-alsa-tools-firmware.rules  99-fuse.rules
Comment 57 Eddie Lania 2012-08-09 09:59:48 EDT
btw.

I have renamed in /usr/share/dbus-1/

org.freedesktop.ModemManager.service

to

org.freedesktop.ModemManager.service.disabled.

This took care of my problems for now.
Comment 58 Michael Tatarinov 2012-09-05 03:49:14 EDT
The blacklist in /lib/udev/rules.d/77-mm-usb-device-blacklist.rules now
Comment 59 Eddie Lania 2012-09-10 03:08:52 EDT
That file already excists there
It says it will be overwritten on update(s). That's not the solution:

# do not edit this file, it will be overwritten on update

ACTION!="add|change", GOTO="mm_usb_device_blacklist_end"
SUBSYSTEM!="usb", GOTO="mm_usb_device_blacklist_end"
ENV{DEVTYPE}!="usb_device",  GOTO="mm_usb_device_blacklist_end"

Can't you come up with something better than that?
Comment 60 Eddie Lania 2012-09-10 03:09:20 EDT
That file already excists there
It says it will be overwritten on update(s). That's not the solution:

# do not edit this file, it will be overwritten on update

ACTION!="add|change", GOTO="mm_usb_device_blacklist_end"
SUBSYSTEM!="usb", GOTO="mm_usb_device_blacklist_end"
ENV{DEVTYPE}!="usb_device",  GOTO="mm_usb_device_blacklist_end"

Can't you come up with something better than that?
Comment 61 Fedora End Of Life 2013-01-16 20:08:17 EST
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 62 Fedora End Of Life 2013-02-13 21:38:53 EST
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 63 Michal Hlavinka 2013-09-24 11:39:24 EDT
*** Bug 1011213 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.