A new and bizarre issue has emerged on my Linux Mint server that seems specific to my Ender 3 and OctoPrint. Every night at midnight, regardless of whether a print is running or not, the USB connection to the Ender fails and restarts. (See screenshot from my Telegram OctoPrint plugin.) I’ve tried setting usb.autosuspend to -1 in GRUB, but that doesn’t seem to help.
I’m completely stumped and could use some advice. The failures are far too scheduled and predictable to be a random hardware failure. A relevant chunk of /var/log/syslog is included below for reference.
May 5 00:00:03 borgcube systemd[1]: logrotate.service: Succeeded. May 5 00:00:03 borgcube systemd[1]: Finished Rotate log files. May 5 00:00:03 borgcube kernel: [93921.837884] usb 1-5.4: new full-speed USB device number 9 us ing xhci_hcd May 5 00:00:03 borgcube systemd[1]: man-db.service: Succeeded. May 5 00:00:03 borgcube systemd[1]: Finished Daily man-db regeneration. May 5 00:00:03 borgcube kernel: [93922.059024] usb 1-5.4: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.63 May 5 00:00:03 borgcube kernel: [93922.059026] usb 1-5.4: New USB device strings: Mfr=0, Produc t=2, SerialNumber=0 May 5 00:00:03 borgcube kernel: [93922.059027] usb 1-5.4: Product: USB2.0-Serial May 5 00:00:03 borgcube kernel: [93922.066323] ch341 1-5.4:1.0: ch341-uart converter detected May 5 00:00:03 borgcube kernel: [93922.066896] usb 1-5.4: ch341-uart converter now attached to ttyUSB0 May 5 00:00:03 borgcube mtp-probe: checking bus 1, device 9: “/sys/devices/pci0000:00/0000:00:1 4.0/usb1/1-5/1-5.4” May 5 00:00:03 borgcube mtp-probe: bus: 1, device: 9 was not an MTP device May 5 00:00:03 borgcube snapd[1104]: hotplug.go:200: hotplug device add event ignored, enable e xperimental.hotplug May 5 00:00:03 borgcube mtp-probe: checking bus 1, device 9: “/sys/devices/pci0000:00/0000:00:1 4.0/usb1/1-5/1-5.4” May 5 00:00:04 borgcube mtp-probe: bus: 1, device: 9 was not an MTP device
Check your crontab log for anything running at midnight?
Checked that and the systemd timers. No dice. However, this problem started right around the time I updated my kernel package, and there was another update that I applied yesterday. I connected the printer and let it sit overnight. No midnight disconnections.
I’m running a print job now that should run past midnight. Fingers crossed that this was just some kind of transient kernel bug!
The print job didn’t fail, so I’m going to write this off as a kernel bug until/unless it happens again. I’m just glad I can run long jobs again!
try to force it to be midnight(changing the timer ik) and see if it happen
It’s haunted. Only explanation.
I’ll call Dean and Sam. Grab the salt.
Just make sure you don’t feed it after midnight.
Long shot but I saw something similar recently so it’s on my mind: do you have any home automation gear running on a schedule that could be killing power or connectivity?
Nope, but I found the problem. A kernel update also came with a brand-new bug. A subsequent kernel update fixed the issue. I’ve been running prints overnight with no midnight disconnects for days now.
