Hello! I've ran into this annoying issue when setting up a new server. I have an APC SmartUPS hooked up on a USB-serial converter on /dev/ttyUSB0.
This works nicely, until: hub 3-0:1.0: port 1 disabled by hub (EMI?), re-enabling... pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0 usb 3-1: pl2303 converter now attached to ttyUSB1 apcsmart gets into an infinite loop of this: apcsmart[2285]: smartmode: issuing 'Y' failed: Input/output error while upsd becomes unhappy: upsd[2311]: Data for UPS [apc] is stale - check driver (because now it can't talk to the UPS) After this, a shutdown usually follows, though my understanding is that this should only happen on battery power. This is very easy to reproduce, just use an USB-serial converter, and pull it out of the port. I've been looking into fixing that and would like some advice on how to proceed. I tried the easiest fix possible: abort on EIO and hope I can get systemd to restart the driver. That so far hasn't worked, it results in a series of very fast restarts, and systemd giving up shortly. So I'm going to try to make the driver reconnect on EIO. So far I have made an attempt, but it still quits somewhere. It also seems some changes might be necessary to the driver API to get this done. So I'd like some advice first: Is there any work on this planned already? Do you have any preferences regarding how this should work? Eg, retry connection only after connection has been established? Add a configuration parameter to enable this mode? How should I approach changing the driver API? For instance it seems like a upsdrv_initups argument to ensure it won't quit on failure may be needed. What about other UPS models? This would imply changes in main.c, and affect other models, but I can only test my APC SmartUPS. Also this problem probably applies to USB UPSes. Thanks! _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
