Disconnecting FTDI device leads to continuous error messages, filling log files and eventually the disk

[organman91]

OLA olad version: 0.10.3

I've followed the guide for setting up the Enttec Open DMX USB. It works fine, and the daemon reloads itself when plugging in the USB cable. However, when unplugging without stopping the daemon, the daemon continuously writes an error message:

Sep 7 18:53:25 foobar-pi olad: plugins/ftdidmx/FtdiWidget.cpp:330: FT232R USB UART with serial number : A600BRM3 Setting new line property failed

Since I'm running on a raspberry pi, this quickly fills the disk. On Raspbian Stretch (debian 9.4) the default is to write this error message to /var/log/syslog, /var/log/messages, and /var/log/user.log, which quickly exhausts all available space on the SD card.

I've found a workaround: setting the daemon logging level to 1 or 0 in /etc/init.d/olad prevents this message from being logged at all.

[peternewman]

Does it log anything before it starts spewing those? Does it recover properly and start sending DMX on re-plug? I'll try and reproduce it here.

[organman91]

With loglevel 3, no other output besides the error message from olad. (The USB device disconnect kernel event can be seen in syslog: Sep 9 22:04:36 foobar-pi kernel: [434121.647877] usb 1-1.3: USB disconnect, device number 12).

With loglevel 4, the only additional messages seen are about Garbage collection:

Sep  9 22:09:56 foobar-pi olad: olad/OlaServer.cpp:385: Garbage collecting
Sep  9 22:09:56 foobar-pi olad: common/io/EPoller.cpp:306: ss process time was 0.000041

Upon re-plugging the device, the daemon restarts itself and DMX is once again functional.

[RAD-X]

Seems that problem is still there (flash in RPi suffers like a ...). My dirty solution is using udev rule (for FTDI device in this example) and restarting olad service. SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", GROUP="plugdev", RUN+="/bin/sh -c 'service olad restart'"

[peternewman]

Seems that problem is still there (flash in RPi suffers like a ...).

Yeah no-one has closed the issue or done anymore work on it @RAD-X so it will still be present.

My dirty solution is using udev rule (for FTDI device in this example) and restarting olad service. SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", GROUP="plugdev", RUN+="/bin/sh -c 'service olad restart'"

That's a neat workaround, although I think signalling a HUP to the process would work too and might be less invasive.

Do you fancy trying to have a look at the code issue?

Does this happen even if the plugin isn't patched to a universe?

[thxrben]

I think that my issue from a few years ago (#1675) is related to this and may help solving it?