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.
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.
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
Created attachment 376939 [details] boot.log (shows UPS driver controller failing to start)
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).
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).
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.
Just experienced failure of ups to start at boot time. So it's not 100% reproducible but still a problem.
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
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
> 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
Created attachment 378773 [details] dmesg output (I reverted the previous changes so this is starting from scratch)
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.
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.
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.
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
Created attachment 378795 [details] boot.log [andre@compaq-pc ~]$ ps -A | grep 1515 1515 ? 00:00:00 modem-manager
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
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.
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 ~]$
All as root: 1) service NetworkManager stop 2) killall -TERM modem-manager 3) modem-manager --debug thanks!
[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...
Not sure if it matters but the ups service is currently running. If necessary I could stop that and run modem-manager --debug again.
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?
(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.
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.
(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?
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.
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.
No change, ups still unable to start at boot time.
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.
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.
*** Bug 537544 has been marked as a duplicate of this bug. ***
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.
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.
(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.
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.
nut does not appear to retry for the port *at all*. (main() -> upsdrv_initups() -> ser_open() -> fail)
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.
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.
> 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>
<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>
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.
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.
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.
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.
Of course, this isn't a UPS. But this seems to be the bug where blacklisting devices for modem-manager is being discussed.
(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
I've blacklisted the first two devices upstream as: 12f1b351e83730c7d5fa882f0fbbaf4b19816a00
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
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.
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.
Reopening. I'm using a USB UPS now so can't help in testing, though.
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?
(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"
Changing the needinfo email since I now use a USB UPS and can't help with testing.
"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
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.
The blacklist in /lib/udev/rules.d/77-mm-usb-device-blacklist.rules now
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?
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
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.
*** Bug 1011213 has been marked as a duplicate of this bug. ***