LINUX.ORG.RU
решено Форум — Admin  

Юнит спит, а почему?

 


0

1

cat /lib/systemd/system/syncthing@.service

[Unit]
Description=Syncthing - Open Source Continuous File Synchronization for %I
Documentation=man:syncthing(1)
After=network.target
StartLimitIntervalSec=60
StartLimitBurst=4

[Service]
User=%i
ExecStartPre=/bin/sleep 600 <-- добавил эту строку
ExecStart=/usr/bin/syncthing serve --no-browser --no-restart --logflags=0
Restart=on-failure
RestartSec=1
SuccessExitStatus=3 4
RestartForceExitStatus=3 4

# Hardening
ProtectSystem=full
PrivateTmp=true
SystemCallArchitectures=native
MemoryDenyWriteExecute=true
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

systemctl status syncthing@user.service Дрыхнет уже второй час :)

● syncthing@user.service - Syncthing - Open Source Continuous File Synchronization for user
     Loaded: loaded (/lib/systemd/system/syncthing@.service; enabled; preset: enabled)
     Active: activating (start-pre) since Fri 2025-03-14 21:37:23 MSK; 6s ago
       Docs: man:syncthing(1)
  Cntrl PID: 101827 (sleep)
      Tasks: 1 (limit: 76063)
     Memory: 232.0K
        CPU: 3ms
     CGroup: /system.slice/system-syncthing.slice/syncthing@user.service
             └─101827 /bin/sleep 600
★★★
← oVirt на опыт масштабирования (100+ ВМ)
UFW - как открыть доступ с одной машины? →
Ответ на: комментарий от anonymous

Только об этом подумал и ты это написал. Да, это бага собственной персоной. Только я думаю он от StartLimitIntervalSec=60 отваливается. Вангую, что он считается запустившимся не учитывая pre. Т.е считается, что если юнит запустился, то запустился сервис :)

serg002 ★★★
() автор топика
Последнее исправление: serg002 (всего исправлений: 3)
Ответ на: комментарий от serg002

StartLimitIntervalSec - это время, в течение которого сервис должен отвалиться StartLimitBurst раз, чтобы systemd перестал его пытаться перезапустить. А отваливается он именно по TimeoutStartSec.

anonymous
()
Ответ на: комментарий от anonymous

Пропустил этот момент. TimeoutStartSec - я думал это в юните где-то стоит. Поиском только что не нашел и понял, что это, скорей всего, константа, общая для всех юнитов. Вполне может и из-за нее. Но по идее она должна считать время не юнита, а сервиса. А она считает время запуска юнита, отсюда и проблема. Добавили pre timeout и получили неработающий сервис. Лично в этом случае лучше было бы таймаут, потому что юнит синхронизации в рам имеет в названии имя профиля, который может меняться. Что усложняет эксплуатацию

serg002 ★★★
() автор топика
Ответ на: комментарий от Anoxemian

А в чём тупняк? Я загуглил по теме systemd unit timeout start. Мне выдало несколько ответов. Я выбрал ответ. Перезагрузился перепроверить. Оно не работает. Пришел с этим на форум. В чём тупняк? Или я должОн знать все константы и переменные systemd?

serg002 ★★★
() автор топика
Последнее исправление: serg002 (всего исправлений: 1)
Ответ на: комментарий от serg002

А в чём тупняк? Я загуглил…

Перечитай вывод sysctemctl status внимательно. Там всё есть

Active: activating (start-pre) since Fri 2025-03-14 21:37:23 MSK; 6s ago

То есть сервис спит не 2 часа, а 6 секунд. В StartPre написано sleep 600

cobold ★★★★★
()
Ответ на: комментарий от asdpm

а каким образом TimeoutStartSec учитывается для simple? они же не будут самодемонизироваться, от них не ожидается сигнал об успехе в заданное время. у него периода запуска как такового нет, он мгновенный. разве нет?

asdpm
()
← oVirt на опыт масштабирования (100+ ВМ)
Admin
UFW - как открыть доступ с одной машины? →