Удостоверьтесь, что Вы включили необычное автозавершение. На многих дистрибутивах это означает Ваш ~/.bashrc
потребности содержать . /etc/bash_completion
.
Необходимо будет настроить аутентификацию без пароля, т.е. с ключом это уже загружается в ssh-agent
.
Установление соединения SSH является медленным, таким образом, можно значительно ускорить завершения путем установления соединения раз и навсегда и использования того соединения после этого. Относительно сложный способ сделать, который должен открыть основное соединение SSH с ssh -N -M target-host
после установки соединений "главный-подчиненный" в ~/.ssh/config
; посмотрите Несколько ssh сессий в единственной команде для инструкций (Вам нужно ControlMaster
и ControlPath
опции).
Простой метод состоит в том, чтобы смонтировать удаленную файловую систему по SSHFS и использованию cp
с нормальным завершением оболочки.
mkdir ~/remote
sshfs USER@192.168.178.32:/home/USER ~/remote
cp -p someFile ~/remote/put/it/some/where/oh/damn/you/here
Вероятно, потому что его родительский процесс завершается, и сигнал завершения распространяет его детям, которые не блокируют его (и в случае SIGKILL
они даже не могут).
Shell имеет способность к командам выполнения в фоне:
(
lots of code
) &
Команды, сгруппированные фигурными скобками с амперсандом после них, будут выполняться асинхронно в подоболочке. Я использую это для автосоединений, когда USB-модем вставляется и переключается. Это занимает приблизительно 20 секунд и хорошо работает под udev.
Я заставил это работать с setsid. Моя часть ВЫПОЛНЕНИЯ правила udev:
RUN+="/bin/bash script.sh"
затем в сценарии:
#!/bin/bash
if [ "$1" != "fo_real" ]; then
/usr/bin/setsid $(/usr/bin/dirname $0)/$(/usr/bin/basename $0) fo_real &
exit
fi
Rest of script is here....
Первый вызов к возвратам сценария со статусом выхода 0, но второй вызов к сценарию продолжает бежать с PPID = 1.
При выполнении достойного распределения с поддержкой systemd самый легкий и технически самый безопасный путь состоит в том, чтобы использовать единицу устройства.
Таким образом, systemd будет полностью управлять продолжительным сценарием и даже сможет правильно завершить процесс, после того как устройство, завершают работу/удаляют - отсоединение средств процесса, Вы бросаете полностью управлять состоянием процесса и его историей.
Помимо этого, Вы сможете осмотреть состояние устройства, и оно присоединило сервис путем выполнения systemctl status my-ppp-thing.device
.
См. также это сообщение в блоге еще для некоторых примеров и деталей.
В настоящее время udev использует контрольные группы для поиска и уничтожения порожденных задач. Одно из решений - использовать «сейчас» или «партия». Другое решение - выполнить двойной форк и «переместить» процесс в другую контрольную группу. Это пример кода Python (аналогичный код может быть написан на любом языке):
os.closerange(0, 65535) # just in case
pid = os.fork()
if not pid:
pid = os.fork() # fork again so the child would adopted by init
if not pid:
# relocate this process to another cgroup
with open("/sys/fs/cgroup/cpu/tasks", "a+") as fd:
fd.write(str(os.getpid()))
sleep(3) # defer execution by XX seconds
# YOUR CODE GOES HERE
sleep(0.1) # get forked process chance to change cgroup
Отладочные данные могут быть отправлены, например, в системный журнал.