Pomoc Po upgrade problem dziwny z cronem ale nie tylko

[aki]

Witajcie,

Po upgrade do 4.3.2 pojawił się dziwny problem. Zaobserwowałem go poprzez fakt, że polecenia z /etc/config/crontab się nie wykonują o określonym czasie. Miałem tam wpisanych na stałe od lat kilka własnych rzeczy, ale też wpisywały się tam (i wpisują dalej) polecenia z aplikacji typu CloudDriveSync.

Drugą obesrwacją jest to, że wiele poleceń bazujących na /etc/passwd nie działa:

[~] # crontab -e
crontab: unknown uid 0

[~] # passwd
passwd: unknown uid 0

Co ciekawe, hasło spokojnie mogę zmienić przez interfejs graficzny, ale nie powoduje to żadnych efektów w /etc/shadow.

Programy bazujące na cronie (typu CloudDriveSync) co prawda dalej modyfikują /etc/config/crontab, ale ich działanie musi opierać się na czym innym. Zmiana przez interfejs powoduje odpowiednią zmianę działania, ale już zmiana /etc/config/crontab i przeładowanie crona nie daje żadnych efektów.

Na tym cronie z własnymi poleceniami to powiem Wam mi bardzo zależało. A u czuję się zagubiony na amen...

Bardzo dziękuję za pomoc.

pozdrowienia
aki

Wersja oprogramowania Firmwware: 4.3.2.0026 Build 20161211
Model serwera: QNAP TS-496U

 

[Pikpok]

restart crona (reczny czy przez reboot qnapa) powoduje jego wyzerowanie do ustawien wpisanych w /etc/init.d/crond.sh - popatrz sobie w ten skrypt a wszystko stanie sie jasne.

Polecenie
/etc/init.d/crond.sh restart
nadpisuje wszystko co wczesniej bylo recznie wpisane w

/etc/config/crontab (crontab -l) bedzie wowczas bez Twoich recznych zmian


aby to obejsc dopisalem do /etc/init.d/crond.sh moj wpis w odpowiedniej sekcji

                if [ -x /share/homes/admin/1.sh ]; then

                                /bin/echo "*/1 * * * * /share/homes/admin/1.sh" >> /etc/config/crontab

                fi

I teraz po restarcie wykonywanie 1.sh nadal dziala.

Twoich problemow z crontab -e nie mam, chodzi mi dobrze. W tym temacie wiec nie pomoge