-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I've made a couple of changes to cronsub in response to some issues reported by users. Specifically:
* cronsub now requires that the script file be executable, and will raise an error if it's not. The previous behaviour was that non-executable scripts would be executed by /bin/sh. If this affects you, the fix is to make the script executable (chmod +x).
* Previously, SGE would copy the job script to a shared directory and execute it there. For example, if you submitted $HOME/test.py, it would be copied to a file such as /sge62/default/spool/wolfsbane/job_scripts/117333 before starting. This was unfortunate for Python users who depended on Python's behaviour of treating the script's directory as part of the "import" search path.
This behaviour has been changed, so that the script file will be executed in its original location.
I appreciate that the first item may be a breaking change for some users. However, on balance this seems like the lesser evil.
- river.
Op 8 jan 2011, om 03:28 heeft River Tarnell het volgende geschreven:
I've made a couple of changes to cronsub in response to some issues reported by users. Specifically:
- cronsub now requires that the script file be executable, and will
raise an error if it's not. The previous behaviour was that non-executable scripts would be executed by /bin/sh. If this affects you, the fix is to make the script executable (chmod +x).
I appreciate that the first item may be a breaking change for some users. However, on balance this seems like the lesser evil.
I had an entry in my crontab like:
55 * * * * cronsub -l -s krinkle_clogger $HOME/bots/clogger-start.sh
I got e-mails since a few minutes ago about it not being executable. This can be fixed by giving the user that executes it (in most cases the owner, you) the chmod x right
So if it were chmodded like 644 it now needs to be 744 :)
-- Krinkle
Hi,
since we changed to Solaris I'm not able to start my perl-script via cron.
1. I'm using the example given at https://wiki.toolserver.org/view/Cronsub#cronsub for my cronjob:
0,5,10,15,20,25,30,35,40,45,50,55 * * * * /opt/local/bin/cronsub -s seth-vdetector % /usr/bin/perl $HOME/bots/vdetector.pl >/dev/null
the old (working) code was: */5 * * * * nice -n 10 /usr/local/bin/phoenix /home/seth/phoenix-seth-vdetector /usr/bin/perl $HOME/bots/vdetector.pl
/dev/null
Now the file seth-vdetector.out contains error messages
Base class package "Bot::BasicBot" is empty. (Perhaps you need to 'use' the module which defines that package first, or make that module available in @INC (@INC contains: /opt/ts/perl/5/share/vendor_perl /opt/ts/perl/5.12/lib/site_perl/5.12 /opt/ts/perl/5.12/lib/vendor_perl/5.12 /opt/ts/perl/5.12/lib/5.12 .). at /home/seth/bots/vdetector.pl line 9 BEGIN failed--compilation aborted at /home/seth/bots/vdetector.pl line 9.
What does that mean? At Linux there hasn't been such an error. The perl line which seems to generate the error is use base qw( Bot::BasicBot );
I asked about Basic::Bot more than 9 months ago, but did not get any answer. :-( https://wiki.toolserver.org/w/index.php?title=Conversion_of_nightshade_to_So...
2. Since 2010-01-08 02:25 (UTC) I'm getting additional cron error messages by e-mail:
/opt/local/bin/cronsub[38]: shift: bad number
I guess, this has to do with river's change. But I don't know what to to, since $HOME/bots/vdetector.pl is already at -rwxr-xr-x.
Can anybody help?
thx and bye seth
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
seth:
0,5,10,15,20,25,30,35,40,45,50,55 * * * * /opt/local/bin/cronsub -s seth-vdetector % /usr/bin/perl $HOME/bots/vdetector.pl >/dev/null
For a long-running job, you should use "-sl". Otherwise your job will be killed after 6 hours. (This is not documented very well on [[cron]] at the moment.)
Base class package "Bot::BasicBot" is empty.
For software which was previously installed on nightshade but now isn't, you should file a request in the TS project in JIRA and include "[solaris]" in the subject.
I asked about Basic::Bot more than 9 months ago, but did not get any answer. :-( https://wiki.toolserver.org/w/index.php?title=Conversion_of_nightshade_to_So...
Sorry, but this page was never intended for reporting issues with the migration. We asked users several times to test their tools and report issues in JIRA.
/opt/local/bin/cronsub[38]: shift: bad number
I guess, this has to do with river's change. But I don't know what to to, since $HOME/bots/vdetector.pl is already at -rwxr-xr-x.
Yes, I broke this earlier today. It should be fixed now. Sorry.
- river.
Hello all Hello River
1st Thanks for the fast reply. After reading it and also some older posts I was able to figure out a 'chmod 744' is needed on my python script BUT ALSO THE ADDITION OF '#!/usr/bin/env python' AS FIRST LINE in the script IS NEEDED.
2nd I switched to 'cronie' (thanks for the installation ;)
3rd My next problem is:
=================
Traceback (most recent call last): File "/sge62/default/spool/wolfsbane/job_scripts/118077", line 43, in <module> import wikipedia, config, query, pagegenerators ImportError: No module named wikipedia =================
when running:
'qsub $HOME/pywikipedia/runbotrun.py -cron'
which is the equivalent to:
'0 2 * * * cronsub -s mainbot $HOME/pywikipedia/runbotrun.py -cron'
in my cron(ie)tab file. But it seams that the change you mentioned "Previously, SGE would copy the job script to a shared directory" does not trigger for 'qsub'... I assume the both tools to have the same behaviour, since I thought I can use 'qsub' to test my crontab entries... But may be I'm wrong here.
Greetings! And thanks for your help! Dr.Trigon
Am 08.01.2011 03:28, schrieb River Tarnell:
Hi,
I've made a couple of changes to cronsub in response to some issues reported by users. Specifically:
cronsub now requires that the script file be executable, and will raise an error if it's not. The previous behaviour was that non-executable scripts would be executed by /bin/sh. If this affects you, the fix is to make the script executable (chmod +x).
Previously, SGE would copy the job script to a shared directory and execute it there. For example, if you submitted $HOME/test.py, it would be copied to a file such as /sge62/default/spool/wolfsbane/job_scripts/117333 before starting. This was unfortunate for Python users who depended on Python's behaviour of treating the script's directory as part of the "import" search path.
This behaviour has been changed, so that the script file will be executed in its original location.
I appreciate that the first item may be a breaking change for some users. However, on balance this seems like the lesser evil.
- river.
_______________________________________________ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dr. Trigon:
'qsub $HOME/pywikipedia/runbotrun.py -cron'
which is the equivalent to:
'0 2 * * * cronsub -s mainbot $HOME/pywikipedia/runbotrun.py -cron'
These are not equivalent. cronsub does a fair amount of additional processing on top of qsub.
in my cron(ie)tab file. But it seams that the change you mentioned "Previously, SGE would copy the job script to a shared directory" does not trigger for 'qsub'
That's correct.
since I thought I can use 'qsub' to test my crontab entries... But may be I'm wrong here.
You can run cronsub from the command-line for testing.
- river.
You can run cronsub from the command-line for testing.
;))) easy, simple and straight forward... should be kind of obvious... :))
Thanks a lot! ;)
- river.
_______________________________________________ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
toolserver-l@lists.wikimedia.org