Hallo Liste,
ich hab eine mögliche Lösung gefunden:
ich lasse cron Scripte starten, die unter /etc/cron.d liegen, z.B. um
den Vertretungsplan zu synchronisieren.
Tatsächlich werden die Skripte nach dem neustart komplett ignoriert und
nicht ausgeführt, bis ich cron von Hand restarte.
Der von mir vermutete Grund:
der ausführende Benutzer ist "administrator" welcher ein LDAP-Benutzer
ist und der vermutlich zu boot-zeit noch nicht dem System(cron) bekannt
ist, weil LDAP einfach noch nicht läuft.
Fazit für mich:
in /etc/rc.local ein "sleep 10m; service cron restart" einfügen.
Fazit für euch vielleicht:
-> keine Cronjobs als LDAP-Benutzer anlegen, dann lieber gleich als "root"
Grüße, Tobias
Am 18.11.2015 um 06:04 schrieb "T. Küchel":
> Hallo Liste,
>
> heute zum zweiten Mal getestet: Server neu gestartet (5:42 Uhr), und
> cron läuft nicht rund.
> Es läuft zwar, startet aber manche skripte aus /etc/cron.d nicht.
>
> Erst nachdem ich cron neustarte (habe ich das letzte Mal gemacht), oder
> wenn ich die betreffenden Dateien bearbeite, werden sie RELOADed und
> starten auch.
>
> Hat jemand eine Idee, wie ich das debuggen kann? Nach "ubuntu 12.04
> reboot cron" zu googlen ist ziemlich aussichtslos, denn *manche* jobs
> (wie kronolith) funktionieren ja...
>
> Grüße + Danke, Tobias
>
> Log-auszug: (kronolith etc. rausgeschnitten)
>
> server ~ # grep -i cron /var/log/syslog
> Nov 18 05:42:01 server CRON[11108]: (www-data) CMD (test -x /usr/bin/php
> && ! test -f /tmp/kronolith-cron.lock && touch /tmp/kronolith-cron.lock
> && /usr/bin/php -q /usr/share/horde3/kronolith/scripts/reminders.php >
> /dev/null 2>&1 && rm -f /tmp/kronolith-cron.lock)
> Nov 18 05:42:17 server logger: /etc/cron.daily/sophomorix-base started
> Nov 18 05:42:19 server logger: sophomorix-check --cron run successfully
> Nov 18 05:42:21 server logger: sophomorix-quota --cron run successfully
> Nov 18 05:42:21 server logger: sophomorix-bind --cron run successfully
> Nov 18 05:42:21 server logger: /etc/cron.daily/sophomorix-base ended
> Nov 18 05:42:22 server anacron[4907]: Job `cron.daily' terminated
> (mailing output)
> Nov 18 05:42:22 server anacron[4907]: Normal exit (1 job run)
> Nov 18 05:44:01 server cron[4909]: (*system*backupservice) RELOAD
> (/etc/cron.d/backupservice)
> Nov 18 05:45:01 server cron[4909]: (*system*ipfire-janitor) RELOAD
> (/etc/cron.d/ipfire-janitor)
> Nov 18 05:45:01 server CRON[11681]: (www-data) CMD ( test -x
> /usr/bin/php && /usr/bin/php -q /usr/share/horde3/scripts/alarms.php >
> /dev/null 2>&1 || true)
> Nov 18 05:50:01 server CRON[12030]: (root) CMD ( rsync -a
> /var/lib/clamav/
> /var/linbo/xubuntu_virtxp/workstations/lzpc06/var/lib/clamav/ >/dev/null)
> Nov 18 05:51:01 server cron[4909]: (*system*ipfire-janitor) RELOAD
> (/etc/cron.d/ipfire-janitor)
> Nov 18 05:54:01 server cron[4909]: (*system*backupservice) RELOAD
> (/etc/cron.d/backupservice)
> Nov 18 05:54:01 server cron[4909]: (*system*dsbservice) RELOAD
> (/etc/cron.d/dsbservice)
> Nov 18 05:54:01 server CRON[12276]: (administrator) CMD (
> /home/administrators/administrator/Vertretungsplan/vplan.sh >/dev/null 2>&1)
>
> Erst ab hier läuft der vertretungsplan-skript (dsbservice) los.
>
> # ls /etc/cron.d/ -1
> amavisd-new
> anacron
> backupservice
> belwuemail
> clamavcopy
> dsbservice
> horde3
> ipfire-janitor
> kronolith2
> mdadm
> php5
> rsnapshot
> startclients
> uucp
>
> (alle haben dieselben Rechte)
> ___
> linuxmuster-user mailing list
> linuxmuster-user@lists.linuxmuster.net
> https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
>
___
linuxmuster-user mailing list
linuxmuster-user@lists.linuxmuster.net
https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
