как настроить последовательность загрузки с помощью systemd
Начиная с версии rsync 3.1.0, аргумент - remote-option (или его сокращенная форма -M ) доступен для передачи аргументов серверу. Например, предоставление клиенту команды:
$ rsync -av -M --customarg1=value1 -M --customarg2=value2 file1 file2 user@server:some/path
приведет к тому, что серверная команда получит аргументы с префиксом -M , но без -M , в SSH_ORIGINAL_COMMAND переменная.Примерно так:
rsync --server -vnlogDtpre.iLsfxC --customarg1=value1 --customarg2=value1 . some/path
Пользовательские аргументы должны быть обработаны и удалены из командной строки перед вызовом серверной rsync (в противном случае он завершится с ошибкой, потому что он их не распознает). Один из способов сделать это - сопоставление регулярного выражения:
rsync_cmd="$SSH_ORIGINAL_COMMAND"
[[ "$rsync_cmd" =~ --customarg1=([a-zA-Z0-9]+) ]] && customarg1=${BASH_REMATCH[1]}
[[ "$rsync_cmd" =~ --customarg2=([a-zA-Z0-9]+) ]] && customarg2=${BASH_REMATCH[1]}
rsync_cmd=$(sed -re 's/--(customarg1|customarg2)=[a-zA-Z0-9]+//g' <<< $rsync_cmd)
(пример сопоставления регулярного выражения позволяет параметру быть буквенно-цифровым)
Одно предостережение заключается в том, что он не работает, если клиенту rsync присвоено значение -s (или - protect-args ), потому что это вызывает внутреннюю передачу аргументов между клиентом rsync и сервером - они не отображаются в оболочке, не включены в $ SSH_ORIGINAL_COMMAND , и поэтому не может быть изменен.
Альтернативный метод - использовать - rsync-path для передачи настраиваемых аргументов. Этот метод работает со старыми версиями rsync, в которых отсутствует -M , а также с параметром - protect-args :
$ rsync --rsync-path='rsync --customarg1=value1 --customarg2=value2' -av file1 file2 user@server:some/path
Я столкнулся с теми же проблемами при установке Ubuntu 16.10 на новый MiniPC (в отличие от Ubuntu 14.x, которая работала нормально).
Я наконец нашел автоматизированное решение этой проблемы: включите службу NetworkManager-wait-online.service и разверните пользовательский сценарий, который перезапускает службу postfix через +-5 минут после загрузки машины (предполагая, что беспроводное соединение к тому времени будет активно).
A. Включите это.
Это общий подход, который может быть полезен и для других служб, кроме Postfix, поэтому я сохраняю его в сценарии.
systemctl enable NetworkManager-wait-online.service; systemctl status NetworkManager-wait-online.service;
B. Добавьте клиентский таймер Systemd + сервис
@info Таймер будет запускаться ONCE, через {x} минут после загрузки машины.
nano /etc/systemd/system/mjd-restart-postfix-after-wlan-connected.timer
[Unit].
Описание=(таймер)mjd-restart-postfix-after-wlan-connected
[Timer]
OnBootSec=5min
[Install]
WantedBy=timers.target
nano /etc/systemd/system/mjd-restart-postfix-after-wlan-connected.service
[Unit]
Description=mjd-restart-postfix-after-wlan-connected
[Service]
Тип=oneshot
ExecStart=/bin/sh -ec "systemctl restart postfix; systemctl status postfix; uname -a | /usr/bin/mailx -s \"Server (`hostname`): postfix was restarted.\" youremail@gmail.com"
MYUNIT=mjd-restart-postfix-after-wlan-connected
MYTIMER=${MYUNIT}.timer
systemctl enable ${MYTIMER}; systemctl status ${MYTIMER};
systemctl list-units --all | grep "${MYUNIT}"
systemctl status ${MYUNIT}
C. Перезапустите
перезагрузка
# подождите 5 минут
D. Проверьте
MYUNIT=mjd-restart-postfix-after-wlan-connected
MYTIMER=${MYUNIT}.timer
systemctl status ${MYTIMER}
Если содержимое этих двух конфигурационных файлов (один из Resolve и один из Postfix) не совпадает, то проблема ПРОБЛЕМАТИЧЕСКАЯ (Postfix запускается до подключения LAN/WLAN). cat /etc/resolv.conf cat /var/spool/postfix/etc/resolv.conf
E. Информация @doc https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1519331 @doc https://wiki.archlinux.org/index.php/Systemd/Timers @doc qshape deferred @doc cat /var/log/syslog | egrep "NetworkManager|postfix"