«Inputattach» не переживает приостановку / резюме
Я много читал на приостановке / возобновлении, здесь и других интернет-ресурсах и пробовал бесчисленные (слишком много, чтобы цитировать здесь) отданных намеков; Напрашен ...
Моя настройка требует Inputattach , и у этого всегда было проблему с приостановкой / резюме, поскольку она не вернулась к чистоте после резюме. Мне никогда не удалось использовать «крючки», предусмотренные в / USR / Lib / SystemD / System-Sleep / : Мои скрипты (построенные после примеров в документации) в тудах были правильно (!) Запустить во время резюме, Но их эффект не был. В routeCttl Я могу видеть, что сценарий, выполненный, как пользователь , созданный процессом , созданный процессом , и его PID перечислены:
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
, но когда резюме закончил, этот процесс ушел. Требуется ли у нее специальные разрешения / привилегии, которые будут приняты ядром и сохраняться?
Одним из наблюдений: при запуске Inputattach во время загрузки или вручную после ), , я вижу что-то вроде Эти записи в Journctctl :
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
, которые не отображаются после создания процесса в сон - крючок.
Мой обходной путь в возрасте состоялся в том, чтобы иметь псевдоним, что после резюме закончилось, RAN inputattach снова. Это больше не работает с момента модернизации до 20.10. Это может быть как (сейчас?) Команда Systemctl Softend команда асинхрона, а не будет ждать завершения цикла приостановки / возобновления. Я не вспоминаю, что это было до обновления.
Есть ли что-то очевидное, что я здесь делаю не так? Любые идеи / подсказки? Может ли быть умный ДБУС / UDEV Действие Действие, выполнение трюки?
1 ответ
У меня была та же проблема с корицей 19. Он обновил xfce, чтобы я мог получить любую фиксированную упакованную версию обновления погоды. Поэтому я загрузил код и построил его, как описано здесь
В случае, если вы застрянете, я передам пакет deb, который я создал для вас.
-121--909084-В конечном итоге, попробовав еще кое-что, я нашел здесь и в другом месте, я переустановился с Live CD.
-121--909094- Необходимо попытаться создать правило UDEV в /etc/udev/rules.d/. Я предполагаю, что вы хотите подключить мышь Logitech, поэтому найдите правильное правило, введя:
sudo udevadm monitor --environment --udev
Plugin the mouse и проанализируйте данные, которые команда выше будет регистрации на консоли: (Ваша будет выглядеть иначе!)
UDEV [43482,659634] bind/devices/pci0000: 00/0000: 00: 1a.0/usb1/1-1/1-1.5/1-1.5. ACTION = bind DEVPATH =/devices/pci0000: 00/0000: 00: 1a.0/usb1/1-1/1-1.5/1-1.5.6 ПОДСИСТЕМА = usb DEVNAME =/dev/bus/usb/001/007 DEVTYPE = usb _ device ДРАЙВЕР = 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 мышь 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 МАЖОР = 189 МИНОР = 6 ТЭГИ =: seat: CURRENT_TAGS=:seat:
In этом случае вы создаете файл, это папка, упомянутая выше, как 40-attach.rules и пишете следующее правило:
ACTION=="bind", ATTR{idVendor}=="093a",RUN+="/usr/local/sbin/mybashfile.sh"
Необходимо выбрать значения ATTR в соответствии с вашими данными (не мои).
Основная идея заключается в том, что udev выполнит команду после «RUN», если обнаружит аппаратные средства.
Напоминаем: это пример, основанный на подключенном устройстве. У вас будут другие значения, но это должно дать вам суть. То же самое можно сделать с любым оборудованием, подключенным к вашему ПК/ноутбуку
UPDATE
В этой статье Arch Linux описывается, как подключить последовательное устройство к ядру. Это может помочь вам обойти вместо использования маршрута UDEV - что не полезно в вашем случае.
Другой подход приведен здесь повторное пробуждение сенсорного экрана. В обоих случаях использовалась systemd. Не как крючок (как вы пытались), а как сам сервис. Наиболее важной частью должно быть определение единицы измерения:
[Unit]
Description=restart your-inputattach service
After=suspend.target
Это предшествует разделу «Обслуживание», где вы можете определить любые ваши потребности.