Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Strony: 1
Debiana mam zainstalowanego na kontenerze LXC typu "unprivileged" w wirtualizatorze Proxmox ze standardowej dostępnej tam templatki.
Po upgrade z Debian 9 do 11 przestały mi działać wpisy w crontabie z @reboot.
np. wpis naprawiający działanie SSH
@reboot mkdir -p /run/sshd; systemctl restart sshd
dpkg -l cron | grep amd64
ii cron 3.0pl1-137 amd64 process scheduling daemon
Próbowałem:
- przeglądać logi w poszukiwaniu czegoś sensownego,
- dpkg --purge cron*; apt install cron;
- dodawać wpis do /etc/crontab z @reboot,
- dodawać wpis przez crontab -e
(przy dodawaniu wpisu brak błedu o nieprawidłowej składnii)
Mogę podejrzewać, że ta wersja cron jest zrypana.
Czy u was jest też takie samo zachowanie crona (olewka wpisów @reboot)?
Offline
Debian 11, kiedy go ostatnio odpalałem, używał systemd.
Zrób sobie strypt do systemd, np :
/etc/etc/systemd/system/cgstart.service
przykładowa zawartość:
[Unit] DefaultDependencies=no Description="CGSTART - Zakładam strukturę grup do cgroup ;)" Before=cgred.service [Service] Type=oneshot ExecStart=/usr/local/sbin/cgstart TimeoutSec=0 RemainAfterExit=yes [Install] RequiredBy=local-fs.target
Ten akurat odpalał mój własny skrypt cgstart przed demonem cgred.
Zrobiony wieki temu ale działał grzecznie.
Systemd bazuje na zależnościach startowych a nie poziomach startowych (jak SysVinit),
pewnie dlatego reboot z crona nie działa prawidłowo.
Na necie jest tyle wątków o tym, ze cron @reboot nie działa,
że jest w podpowiedziach google jak wpisujesz w pasku wyszukiwania.
https://www.google.pl/search?q=cron+%40reboot+not+working
Około 29 200 wyników (0,59 s)
Prościej wyjdzie własny skrypt startowy niż gimnastyka z Cronem.
Tu masz instrukcję do pisania skryptów startowych do Systemd:
https://www.freedesktop.org/software/systemd/man/systemd.service.html
Poza tym nie bardzo rozumiem, co masz na myśli z poprawianiem działania sshd?
Kiedy ostatnio bawiłem się Debianem na pewnym serwerze, dokładnie wczoraj po południu,
to sshd w Debianie 11 działało grzecznie bez żadnych czarów z cronem.
Tylko że to nie było na LXC ani Proxmox, ale na pewnym serwerze dedykowanym w necie,
ponad XX tyś km od mojego tyłka.
Pozdro
Ostatnio edytowany przez Jacekalex (2022-05-01 13:57:23)
Offline
Cron działa niezależnie od systemd i zarówno cron jak i systemd-timer mogą działa równolegle, choć zwykle usługi/skrypty cron'a w Debianie mają warunki typu:
# skip in favour of systemd timer if [ -d /run/systemd/system ]; then exit 0 fi
Jak skrypty cron'a tego nie mają to naturalnie mogą się wywoływać bez większego problemu i u mnie te dwa mechanizmy działają obok siebie od lat i nie zauważyłem żadnych problemów.
Wszystko co siedzi w /var/spool/cron/crontabs/ też się bez problemu wykonuje.
A cron'a mam w wersji 3.0pl1-137.1, i ta nie wiele się różni od 3.0pl1-137
A co do tego: @reboot mkdir -p /run/sshd ... to się zainteresuj systemd-tmpfiles.
Ostatnio edytowany przez morfik (2022-05-02 09:51:27)
Offline
Poza tym nie bardzo rozumiem, co masz na myśli z poprawianiem działania sshd?
Kiedy ostatnio bawiłem się Debianem na pewnym serwerze, dokładnie wczoraj po południu,
to sshd w Debianie 11 działało grzecznie bez żadnych czarów z cronem.
Tylko że to nie było na LXC ani Proxmox, ale na pewnym serwerze dedykowanym w necie,
ponad XX tyś km od mojego tyłka.
A już wyjasniam - bez tego wpisu w cronie co reboot mam taką sytuację:
systemctl status sshd ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled) Active: inactive (dead) Docs: man:sshd(8) man:sshd_config(5)
SSH nie bierze Portu z configa i działa na standardowym porcie 22.
w logach na kontenerze:
May 04 09:01:52 hostnametutaj sshd[329]: fatal: Missing privilege separation directory: /run/sshd
Ten prosty workaround rozwiązuje problem - niestety na około. Zapewne w którejś kolejnej wersji Debiana nie będzie już takiej potrzeby.
Workaround na crona czyli to rozwiązanie z unitami systemd ja wiem że zadziała - ale dobre wrogiem lepszego ;-)
Ostatnio edytowany przez jkl (2022-05-04 16:39:11)
Offline
Dla potomnych:
- naprawa wolnego logowania po SSH to zakomentowanie w /etc/pam.d/common-sessions linijki "#session optional pam_systemd.so"
Offline
Strony: 1