very rare segfault in libusb on daemon startup
lynix opened this issue · 4 comments
Rare crash on startup, giving the following log message:
aerod: initialization failed: (+ one random character)
Kernel log shows:
localhost kernel: aerod[4108]: segfault at 50 ip 00007fa82abd3063 sp 00007fff2f7ff7f0 error 4 in libusb-1.0.so.0.0.0[7fa82abd0000+d000]
Issue starts after update to openSUSE Tumbleweed snapshot 20190205
https://deref-gmx.net/mail/client/vhNoJwnJezU/dereferrer/?redirectUrl=https%3A%2F%2Fopenqa.opensuse.org%2Ftests%2Foverview%3Fdistri%3Dopensuse%26groupid%3D1%26version%3DTumbleweed%26build%3D20190205
After a very long time of search I found the reason of the hanging of the NFS-Server and depends on this the NFS-Clients with mounted /home which are blocked several time for some minutes till hours.
The reason was a hangig daemon which are included in the
/etc/init.d/boot.local
Script. After the update to systemd, the script was included in
/usr/lib/systemd/system/rc-local.service
Inside of the boot.local there are only one relevant line:
test -x /usr/bin/aerod && ( /usr/bin/aerod -f -t &>> /var/log/aquero.log )&
Which starts the lynix aerodamon which allows to monitor my FAN-Control.
https://github.com/lynix/aerotools
https://www.aquacomputer.de/steuerung.html
Due to the fact that boot.local was not canceled before a reboot and Continuos hangs, I created an aerod.service in the /etc/systemd/system like described in some openSUSE forums:
\# cat /etc/systemd/system/aerod.service
[Unit]
Description=aerod Serice
ConditionFileIsExecutable=/usr/bin/aerod
After=basic.target
[Service]
Type=oneshot
ExecStart=/usr/bin/aerod -f -t
ExecStop=killall aerod
TimeoutSec=0
#StandardOutput=/var/log/aquero.log
StandardOutput=tty
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
\#
Now I saw some errors in the log some USB errors - which seams the reason.
kernel: usb 9-4.1: New USB device found, idVendor=0c70, idProduct=f0b0, bcdDevice= 4.00
kernel: usb 9-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
kernel: usb 9-4.1: Product: aquaero 4.00
kernel: usb 9-4.1: Manufacturer: aqua computer
kernel: hid-generic 0003:0C70:F0B0.0005: hiddev97,hidraw4: USB HID v1.10 Device [aqua computer aquaero 4.00] on usb-0000:00:16.0-4.1/input0
kernel: usb 9-4.1: usbfs: interface 0 claimed by usbfs while 'aerocli' sets config #1
kernel: aerod[31027]: segfault at 218 ip 00007f227b5659ce sp 00007f227b1bf870 error 4 in libusb-1.0.so.0.1.0[7f227b563000+d000]
kernel: aerod[1893]: segfault at 218 ip 00007f69735a19ce sp 00007f69731fb870 error 4 in libusb-1.0.so.0.1.0[7f697359f000+d000]
I downloaded the SW new and start a new
# make ; make install
but still the same issue
kernel: usb 9-4.1: New USB device found, idVendor=0c70, idProduct=f0b0, bcdDevice= 4.00
kernel: usb 9-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
kernel: usb 9-4.1: Product: aquaero 4.00
kernel: usb 9-4.1: Manufacturer: aqua computer
kernel: hid-generic 0003:0C70:F0B0.0005: hiddev97,hidraw4: USB HID v1.10 Device [aqua computer aquaero 4.00] on usb-0000:00:16.0-4.1/input0
kernel: usb 9-4.1: usbfs: interface 0 claimed by usbfs while 'aerocli' sets config #1
kernel: aerod[31027]: segfault at 218 ip 00007f227b5659ce sp 00007f227b1bf870 error 4 in libusb-1.0.so.0.1.0[7f227b563000+d000]
kernel: aerod[1893]: segfault at 218 ip 00007f69735a19ce sp 00007f69731fb870 error 4 in libusb-1.0.so.0.1.0[7f697359f000+d000]
kernel: aerod[1942]: segfault at 218 ip 00007f999621d9ce sp 00007f9995e77870 error 4 in libusb-1.0.so.0.1.0[7f999621b000+d000]
kernel: aerod[2854]: segfault at 218 ip 00007f2696be59ce sp 00007f269683f870 error 4 in libusb-1.0.so.0.1.0[7f2696be3000+d000]
Well, your systemd unit could use some improvement: Type=oneshot is definitely not intended for daemons, and the killall statement should in fact not even work as systemd expects full paths.
Here's my suggestion for a .service file:
[Unit]
Description=aerod
[Service]
Type=simple
ExecStart=/usr/bin/aerod -F -t
[Install]
WantedBy=multi-user.target
That being said, I unfortunately don't run any Aquaero anymore - I'm back on air cooling since 2013. So I'm afraid I cannot work on the issue.
If you like, you could create a coredump running a development build and I could have a look, but no promises made, it's almost 10 years old software ;)
Just realized that I still have an unmerged development branch (devel) lying around which contains some fixes. Have you tried that one or only master?