Crontab Eintrag geht nicht... bitte um hilfe

Hallo,

ich versuche in Crontab eine Befehlszeile einzuf�gen, das mein Script f�r ein Anti Flood Tool nach jedem neustart des Servers startet. Leider kenne ich mich Linux nicht soooo gut aus. Vielleicht kann mir jemand helfen?

Ich danke euch schon mal.

--> der Eintrag den ich geschrieben habe.
@reboot ./teamspeak/ts2afd_startscript start

einen �hnlichen Eintrag benutze ich um den Ts zu Starten und das geht ohne Probleme
@reboot /teamspeak/tss2_rc2/server_linux

Hallo.

Kannst du bitte die vollst�ndige Crontab-Eintrag geben?

Und, der Punkt

./teamspeak/ts2afd_startscript start

sollte gel�scht werden.

Welche Shell benutzt du?

# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.XXXX1eso9q installed on Sat Aug  8 16:08:25 2009)
# (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $)
@reboot /teamspeak/ts2afd_startscript start
@reboot /teamspeak/tss2_rc2/server_linux
34      0       *       *       *       /usr/local/psa/bin/run-parts.sh /etc/psa/plesk-cron.daily
44      5       *       *       7       /usr/local/psa/bin/run-parts.sh /etc/psa/plesk-cron.weekly
50      1       1       *       *       /usr/local/psa/bin/run-parts.sh /etc/psa/plesk-cron.monthly
11,26,41,56     *       *       *       *       /usr/local/psa/admin/sbin/backupmng >/dev/null 2>&1
0       1       *       *       1       /usr/local/psa/libexec/modules/watchdog/cp/secur-check
0       1       *       *       1       /usr/local/psa/libexec/modules/watchdog/cp/send-report weekly
10      1       *       *       *       /usr/local/psa/libexec/modules/watchdog/cp/clean-sysstats
15      1       *       *       *       /usr/local/psa/libexec/modules/watchdog/cp/pack-sysstats day
15      1       *       *       1       /usr/local/psa/libexec/modules/watchdog/cp/pack-sysstats week
15      1       1       *       *       /usr/local/psa/libexec/modules/watchdog/cp/pack-sysstats month
15      1       1       *       *       /usr/local/psa/libexec/modules/watchdog/cp/pack-sysstats year
20      1       *       *       *       /usr/local/psa/libexec/modules/watchdog/cp/clean-events
0       3       *       *       7       /usr/local/psa/libexec/modules/watchdog/cp/clean reports

---------- Post updated at 09:25 AM ---------- Previous update was at 09:24 AM ----------

Leider weis ich nicht wie ich nachsehen kann welche Shell... und muss gestehen ... muss noch viel lernen... habe mich bis jetzt mit Linux nicht besch�ftigt :frowning:

Hello.

Per our forum rules, all posts must be in English.

We do provide translation services for posts from English to a number of languages as a benefit to users. However, posts must be in English.

Please repost in English.

Thank you for your cooperation.

The UNIX and Linux Forums.

I'm sorry... but my english is not soo well. i was hope so i find hier sombody how can help my in german.

Hi.

(Ich hoffe, dein Englisch ist besser als mein Deutsch!)

After removing the "." you need to reboot to test it.

Which user is running the cronjob?

Can you check the permissions using:

ls -l /teamspeak/ts2afd_startscript

Does the script work OK from the command line?

Hello...

i was so angry... it don't works i rm the script vom server :frowning:

and yes... from command line it works...

i hope i finde a nother programm to stop "Flood" in ts... that was wat the script should do.

Sorry "f�r mein schlechtes Englisch"...
and thx for help

As a service to the public i translated the first three posts to english. I hope you all understand the rule, which ensures that the biggest possible share of users can participate in the forums. Like it or not, English is the de facto lingua franca of the internet.

Now to the problem itself:

I don't know Linux all too well, but crontab is not the place to do things based on a event, like a reboot. crontab is for doing things repetitively based on time: if you want to run a script every 5 minutes or every third monday in a month or everyday at 5:00 pm, you use cron. In your case you use a "rc-script". The basic design is like that: your system has several different "runlevels" - modes of operation. One runlevel is a single-user mode without any networking, wich is used to debug the system if things went really, really bad. Another runlevel is multi-user, full network, but no graphical login, which is good if your graphics adapter is broken and you have to log on over the network. Read more about runlevels in your man pages.

To change from one runlevel to another there is a command ("telinit"). When this command is issued the following happens: all the services started in this runlevel are stopped (killed), then the runlevel is switched and all the services in the new runlevel are started. Because at boot time there has to be some runlevel initialized all the start-scripts for this runlevel are executed. This stopping/starting is done via so-called "rc-scripts", which reside in "/etc/rc[n].d", where [n] is the number of the runlevel. all these scripts work the same way: they understand a single parameter, which can be "start", "stop" (or "restart").

Here is a basic layout for such an rc-script:

case "$1" in
     start)
          # ---- do everything to start service here
          ;;

     stop)
          # ---- do everything to stop service here
          ;;

     *)
          echo "Usage: rc-script {start|stop}"
                exit 1
                ;;
esac

exit 0

You could put your command in there instead of in the crontab and it should work. That is: if your command would be correct, which it isn't.

If you use a relative path like "./somewhere" you depend on a specific context: your session has a working directory, in which a directory named "somewhere" resides. If you would change into this directory the path "./somewhere" would not make sense any more, right? When this script is executed (and this is true for crontab scripts alike) there is no such thing as context, because this is not your session any more, but a different one - hence, use absolute paths always!

Furthermore, you might have set environment variables your application depends on. Be aware that these won't be set in an rc-script either. You have to set them there explicitly to be able to use them there. Issue an "env" and analyze the output to find out if this is true for your app.

I hope this helps.

bakunin