PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Cron-Job zuckt nicht



e2e4
16.03.04, 12:56
Salut,

ich habe mittels

crontab -e

einen Cron-Job erstellt:

15 11 * * * /skripte/test.sh

Um 11.15 Uhr hat dieser Job nichts gemacht. Der Inhalt von test.sh ist:



#!/bin/bash
datum=`date`
echo ${datum} > /skripte/ausgabe.txt


Starte ich das Skript händisch wird es ordnungsgemäß ausgeführt.

Muss man den Dienst nochmal irgendwie starten.

ps -aux | grep "cron"

gibt mir einen laufenden Dienst aus:

/usr/sbin/cron

Grüße, e2e4

drcux
16.03.04, 13:31
PATH=/sbin:/bin:/usr/sbin:/usr/bin

e2e4
16.03.04, 14:24
Die PATH-Einträge stimmen bei mir. Habs jetzt glaub ich gefunden.

/etc/init.d/cron restart

und der Test-Cron-Job wurde ausgeführt. :)

Grüße, e2e4

reno
16.03.04, 15:40
Ja griaß Di,

Original geschrieben von e2e4
/etc/init.d/cron restart

und der Test-Cron-Job wurde ausgeführt. :)Normal ist das aber nicht. Stell dir mal vor: ein System mit einer entsprechenden Anzahl Usern und Jeder müsste root bei jeder Änderung seiner crontab bitten den crond zu restarten. Sowas habe ich noch auf keinem System erlebt. :confused:

e2e4
17.03.04, 09:25
Okay habs mir vorgestellt ;)

Wo könnte ich jetzt nachschauen ob noch was hängt?

Grüße, e2e4

reno
19.03.04, 14:44
Ja griaß Di,
da scheint alles zu stimmen. Allerdings heisst bei mir der Dienst "/usr/sbin/crond" und nicht "/usr/sbin/cron" (oder ist es nur ein Tippfehler?). Wenn du Bock hast, könntest du ja mal folgendes probieren:
einen Eintrag erstellen: 0-59 * * * * touch $HOME/zzzz
Danach vielleicht mal mit crontab -l schauen, ob der Eintrag überhaupt in der Liste vorhanden ist. Dann sollte das File "zzzz" (oder wie du es auch immer nennen magst) jede Minute einen neuen Zeitstempel aufgedrückt bekommen.
Was steht eigentlich in dem Startscript: "/etc/init.d/cron"? Bei meiner Distro gibt es das nicht.

e2e4
22.03.04, 10:14
Salut,


/usr/sbin/crond

Bei mir gibt es nur /usr/sbin/cron.
Ich verwende SuSE 8.0 als Distri. crond gibt es gar nicht.


Wenn du Bock hast, könntest du ja mal folgendes probieren...

Dieser Dienst wird einwandfrei verrichtet. Nur die zwei Backup-Skripte arbeiten nicht.
Für diese erhalte ich in /var/log/messages

/USR/SBIN/CRON[24023]: (root) CMD (/skripte/homebackup.sh)

als Meldung. Das deutet für mich nicht auf einen Fehler hin.


Was steht eigentlich in dem Startscript: "/etc/init.d/cron"?


#! /bin/sh
# Copyright (c) 1995-2000 SuSE GmbH Nuernberg, Germany.
#
# Author: Werner Fink <werner@suse.de>, 1996-2001
#
# /etc/init.d/cron
#
# and symbolic its link
#
# /usr/sbin/rccron
#
# System startup script for the cron daemon
#
### BEGIN INIT INFO
# Provides: cron
# Required-Start: $remote_fs $syslog xntpd sendmail
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 5
# Default-Stop: 0 1 6
# Description: Cron job service
### END INIT INFO

# Source SuSE config
. /etc/rc.status

CRON_BIN=/usr/sbin/cron
test -x $CRON_BIN || exit 5

# Shell functions sourced from /etc/rc.status:
# rc_check check and set local and overall rc status
# rc_status check and set local and overall rc status
# rc_status -v ditto but be verbose in local rc status
# rc_status -v -r ditto and clear the local rc status
# rc_failed set local and overall rc status to failed
# rc_failed <num> set local and overall rc status to <num><num>
# rc_reset clear local rc status (overall remains)
# rc_exit exit appropriate to overall rc status
. /etc/rc.status

# First reset status of this service
rc_reset

# Return values acc. to LSB for all commands but status:
# 0 - success
# 1 - generic or unspecified error
# 2 - invalid or excess argument(s)
# 3 - unimplemented feature (e.g. "reload")
# 4 - insufficient privilege
# 5 - program is not installed
# 6 - program is not configured
# 7 - program is not running
#
# Note that starting an already running service, stopping
# or restarting a not-running service as well as the restart
# with force-reload (in case signalling is not supported) are
# considered a success.

case "$1" in
start)
echo -n "Starting CRON daemon"
## Start daemon with startproc(8). If this fails
## the echo return value is set appropriate.

# NOTE: startproc return 0, even if service is
# already running to match LSB spec.
startproc $CRON_BIN

# Remember status and be verbose
rc_status -v
;;
stop)
echo -n "Shutting down CRON daemon"
## Stop daemon with killproc(8) and if this fails
## set echo the echo return value.

killproc -TERM $CRON_BIN

# Remember status and be verbose
rc_status -v
;;
try-restart)
## Stop the service and if this succeeds (i.e. the
## service was running before), start it again.
## Note: try-restart is not (yet) part of LSB (as of 0.7.5)
$0 status >/dev/null && $0 restart

# Remember status and be quiet
rc_status
;;
restart)
## Stop the service and regardless of whether it was
## running or not, start it again.
$0 stop
$0 start

# Remember status and be quiet
rc_status
;;
force-reload)
## Signal the daemon to reload its config. Most daemons
## do this on signal 1 (SIGHUP).
## If it does not support it, restart.

echo -n "Reload service Cron"
## if it supports it:
## cron monitors /etc/crontab anyway

checkproc $CRON_BIN
rc_status -v

## Otherwise:
#$0 stop && $0 start
#rc_status
;;
reload)
## Like force-reload, but if daemon does not support
## signalling, do nothing (!)

## Otherwise if it does not support reload:
rc_status -v
;;
status)
echo -n "Checking for Cron: "
## Check status with checkproc(8), if process is running
## checkproc will return with exit status 0.

# Status has a slightly different for the status command:
# 0 - service running
# 1 - service dead, but /var/run/ pid file exists
# 2 - service dead, but /var/lock/ lock file exists
# 3 - service not running

# NOTE: checkproc returns LSB compliant status values.
checkproc $CRON_BIN
rc_status -v
;;
probe)
## Optional: Probe for the necessity of a reload,
## give out the argument which is required for a reload.

;;
*)
echo "Usage: $0 {start|stop|status|try-restart|restart|force-reload|reload|probe}"
exit 1
;;
esac
rc_exit

Nichts auffälliges m.M. nach.

Grüße, e2e4

e2e4
23.03.04, 12:08
Problem ist jetzt endgültig behoben - es lag an den relativen Pfadangaben.

Grüße, e2e4