"inputattach" doesn't survive suspend / resume

Question

I've been reading quite a lot on suspend / resume, in here and other internet resources, and tried countless (too many to quote here) of the hints given; in vain...

My setup requires inputattach, and this always had a problem with suspend / resume as it didn't come back cleanly after a resume. I never succeeded in using the "hooks" provided in /usr/lib/systemd/system-sleep/: my scripts (built after examples in the documentation) in there were correctly(!) run during resume, but their effect was none. In journalctl I can see the script executed, as the root user, the inputattach process created, and its PID listed:

    Mär 04 16:48:42 RudisPC systemd-sleep[18057]: echo "... in test ...  $(whoami) -- $1"
    Mär 04 16:48:42 RudisPC systemd-sleep[18057]: ... in test ...  root -- post
    Mär 04 16:48:42 RudisPC systemd-sleep[18057]: case $1 in
    Mär 04 16:48:42 RudisPC systemd-sleep[18057]:   post)
    Mär 04 16:48:42 RudisPC systemd-sleep[18057]:         { inputattach -mman /dev/ttyS0 --daemon --always & disown; echo $!; }
    Mär 04 16:48:42 RudisPC systemd-sleep[18057]:     ;;
    Mär 04 16:48:42 RudisPC systemd-sleep[18057]: esac
    Mär 04 16:48:42 RudisPC systemd-sleep[18074]: + inputattach -mman /dev/ttyS0 --daemon --always
    Mär 04 16:48:42 RudisPC systemd-sleep[18057]: + echo 18074
    Mär 04 16:48:42 RudisPC systemd-sleep[18057]: 18074
    Mär 04 16:48:42 RudisPC systemd-sleep[18075]: + ps -elfH
    Mär 04 16:48:42 RudisPC systemd-sleep[18076]: 0 S root       18074   18057  0  80   0 -  1458 do_sel 16:48 ?        00:00:00         inputattach -mman /dev/ttyS0 --daemon --always

but when resume has finished, that process is gone. Does it require special permissions / privileges to be accepted by the kernel and persist?

One observation: When running inputattach at boot time, or manually after resume, I see something like these entries in journalctl:

Mär 04 16:48:50 RudisPC kernel: serio: Serial port ttyS0
Mär 04 16:48:50 RudisPC kernel: input: Logitech M+ Mouse as /devices/pnp0/00:06/tty/ttyS0/serio7/input/input18

which don't show up after process creation in the sleep- hook.

My workaround for ages was to have an alias that, after resume had finished, ran inputattach again. This doesn't work any more ever since the upgrade to 20.10. This may be as (now?) the systemctl suspend command is asynchronous, and will not wait for the suspend/resume cycle to complete. I don't recall what it was before the upgrade.

Is there something obvious that I am doing wrong here? Any ideas / hints? Could there be a smart dbus / udev action doing the trick?

Answer 1

You should try to create an UDEV rule in /etc/udev/rules.d/. I assume that you want to attach the Logitech mouse, so find the correct rule by entering:

sudo udevadm monitor --environment --udev

Plugin the mouse and analyze the data the command above will log to the console: (Yours will look different!)

UDEV [43482.659634] bind /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5.6 (usb) ACTION=bind DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5.6 SUBSYSTEM=usb DEVNAME=/dev/bus/usb/001/007 DEVTYPE=usb_device DRIVER=usb PRODUCT=93a/2521/100 TYPE=0/0/0 BUSNUM=001 DEVNUM=007 SEQNUM=3718 USEC_INITIALIZED=43481815203 ID_VENDOR=093a ID_VENDOR_ENC=093a ID_VENDOR_ID=093a ID_MODEL=USB_OPTICAL_MOUSE ID_MODEL_ENC=USB\x20OPTICAL\x20MOUSE ID_MODEL_ID=2521 ID_REVISION=0100 ID_SERIAL=093a_USB_OPTICAL_MOUSE ID_BUS=usb ID_USB_INTERFACES=:030102: ID_VENDOR_FROM_DATABASE=Pixart Imaging, Inc. ID_MODEL_FROM_DATABASE=Optical Mouse ID_PATH=pci-0000:00:1a.0-usb-0:1.5.6 ID_PATH_TAG=pci-0000_00_1a_0-usb-0_1_5_6 ID_FOR_SEAT=usb-pci-0000_00_1a_0-usb-0_1_5_6 MAJOR=189 MINOR=6 TAGS=:seat: CURRENT_TAGS=:seat:

In this case you create a file it the folder mentioned above like 40-attach.rules and write the following rule:

ACTION=="bind", ATTR{idVendor}=="093a",RUN+="/usr/local/sbin/mybashfile.sh"

You have to to select the ATTR values according to your data (not mine).

Basic idea is that udev will execute the command after "RUN" if it detects the hardware.

Be reminded: This is an example that is based on a device that is plugged in. You will have a different values, but it should give you the gist. You could do the same with about any hardware that is connected to your PC/Laptop

UPDATE

This Arch Linux article describes how to attach a serial device to the kernel. It might help you to get around instead of using the UDEV route - which is not helpful in your case.

Another approach is listed here reawakening a touchscreen. In both cases systemd was used. Not as hook (as you tried) but as a service itself. The most important part should be the unit definition:

[Unit]
 Description=restart your-inputattach service
 After=suspend.target

This precedes the "Service" Section, where you can define whatever your needs.