Отложенный запуск сервисов

Как же это сделать?

например sleep в ExecStartPre или сделать таймер

Например, нужно задержать его на 10 секунд.

но вот тут что-то не так, т.к. одной из целей в systemd было убрать хардкодные задержки и заменить их на «события».

но вот тут что-то не так

Конечно, не так. Это и есть обратная сторона systemd.
Дело в том, что некоторые внешние устройства при быстром запуске их сервиса не успевают инициализироваться, уж такими их умудрились сделали.
Помогает лишь задержка на несколько секунд.

sleep в ExecStartPre или сделать таймер

Можете накидать примеры этих способов?

Можете накидать примеры этих способов?

не особо :)

[Service]
...
ExecStartPre=/usr/bin/sleep 10
ExecStart=...

но это криво

некоторые внешние устройства при быстром запуске их сервиса не успевают инициализироваться

задержка старта сервиса по идее не влияет на скорость инициализации. Имеется в виду инициализация после включения питания или подключения к интерфейсу?

Если сервис в таких случаях завершается, то можно в юните прописать ему рестарт с задержкой. Так же можно попробовать запустить с помощью правил udev после определения устройства.

После включения питания системного блока с постоянно подключенными устройствами.
Поговаривают, что это из-за какого-то кривого драйвера этих устройств, но никто не берется его исправить.
Вот все и выкручиваются, как умеют.

[Service]
...
ExecStartPre=/usr/bin/sleep 10
ExecStart=...

Костыли.

Вот смотри: https://www.freedesktop.org/software/systemd/man/systemd.service.html#TimeoutStartSec=

Есть параметр TimeoutStartSec, через который можно задать ожидание перед запуском.

Изменить параметры можно через Drop-in.

А почему криво? ;)

а вдруг 10 секунд в некоторорых случаях перестанет хватать? При рестарте сервиса жди N секунд — если работаешь не один и твой товарищ не в курсе или забыл, то он может решить, что возникла какая-то проблема (systemctl ждет когда юнит отработает полностью). И т.д.

Возможен вариант ровнее?

рестарт с задержкой при падении (если сервис падает)

RestartSec=5s
Restart=on-failure #always

Дело в том, что некоторые внешние устройства при быстром запуске их сервиса не успевают инициализироваться, уж такими их умудрились сделали.

Тут правильнее смотреть, как корректнее чекать инициализацию девайса, и через udev отдавать виртуальный .device. А юниты активировать по появлению девайса

это не ожидание перед запуском. Это время ожидания подтверждения успешного запуска

Спасибо за уточнение.

По вашему «кривому» :) способу

[Service]
ExecStartPre=/usr/bin/sleep 10

systemctl stop  my_service

systemctl start  my_service

systemctl restart  my_service

RestartSec=10s
Restart=on-failure

Если он так полезен, то почему он не установлен по дефолту?

он не полезен, это просто еще один костыль. Я склоняюсь к тому, что запуском после сбоя должен заниматься человек, хотя все зависит от ситуации: вылет cupsd меня не сильно волнует, а вот упавшая БД другое дело.

Но при команде systemctl restart my_service не работает вообще. Ну и ладно, не очень-то и хотелось.

Ну стоило бы посмотреть systemctl status my_service и понять, почему рестарт не работает.

Есть гарантия что всего задержки 10 достаточно? Вдруг однажды 15 нужно будет?

В systemd.timer есть такая возможность, но я не помню синтаксис. Внесите intelfx.

@reboot sleep 10 && /usr/bin/my_service >/dev/null 2>&1

Зачем cron?

Внимательно пролистал ман к systemctl , но не обнаружил в нем возможности отложить запуск сервиса.

Тебе нужно отложить запуск однократно?

Или сделать так, чтобы юнит в принципе запускался через N после загрузки ОС?

Есть гарантия что всего задержки 10 достаточно? Вдруг однажды 15 нужно будет?

++

Откуда вообще возникла потребность в задержке?

Дело в том, что некоторые внешние устройства при быстром запуске их сервиса не успевают инициализироваться, уж такими их умудрились сделали. Помогает лишь задержка на несколько секунд.

Что за устройство? Что понимается под «инициализацией»? Оно обнаруживается через несколько секунд или уже после обнаружения ещё какое-то время не готово к работе?

Устройство - известный всем USB-приемник для приема TV-программ, в народе именуемый «свистком» и который сейчас для чего только не используют.
Больше ничего неизвестно, но народ опытным путем вычислил, что для определения (или инициализации) этих свистков 5 секунд обычно всегда хватает, а чтобы была гарантия, ставят 10.

Я склоняюсь к тому, что запуском после сбоя должен заниматься человек,

Конечно. это правильнее, но не всегда у человека есть время мониторить этот сбой, куда проще сделать перезапуск после него.

Ты самого главного не сказал: он определяется 5 секунд или после определения ещё 5 секунд неработоспособен?

Не знаю насчет определения, но если не ввести задержку для сервиса, то он не работает вообще, сколько ни жди
А если ввести задержку 5 сек для запуска его сервиса, то после истечения этих 5 секунд он начинает работать сразу.

Здравствуйте Не подскажите как вы нашли нужный сервис который отвечает за эту загрузку? У меня такая же проблема с свистком ethernet. Когда у меня при инициализация идёт виртуальной сетевой карты, то инет работает как надо. А когда инициализация идёт сразу с свистка, то интернета нет. Вот тоже думаю как отложить инициализацию свистка. Неделю уже по не знанию ковыряюсь. Ещё в начале пути нашел эту тему и пробовал много каких сервисов запускать с задержкой, но так и не нашел решения.