perlskript per cronjob

[hugenay]

Hallo Leutz,
immer dasselbe mit den cronjobs irgendwas an der Umgebung stimmt nicht, aber was?
Das Skript sieht ist in crontab eingetragen, spuckt aber nur eine Fehlermeldung aus.
Das Perl Skript macht ungefaehr folgendes:
Datei wird geoeffnet, mittels Commandosubstitution (per backticks) werden sql Befehle in einer Shell ausgefuehrt und in eine Variable geschrieben und deren Inhalt dann in die Datei geschrieben. Innerhalb der Shell werden noch Umgebungsvariablen fuer sql gesetzt. Ich verwende fuer die Shell Anteile absolute Pfade.
Selbstredend, dass das Skript von root ausgefuehrt problemlos laeuft, sobald es aber in der crontab von root eingetragen ist, gehts nicht mehr. Die Fehlermeldung sagt nur, dass der Job fehlgeschlagen ist.
Woran wirds liegen: an den Shell Teilen an den Perl Anteilen?
Ich weiss es ist bloede ohne den Code, aber den hab ich nicht hier zuhaus.
gruss hug.

[ratte]

keine genaue ahnung, vermutlich funzt's mit den umgehungsvariablen nicht...

grosses aber: wieso benutzt du perl, um ein bash-script (naja, zeile) auszufuehren?
entweder fisch oder fleisch, will sagen, ganz bash oder ganz perl.

alle beschriebenen funktionen lassen sich mit bashfunktionen ausfuehren, und fuer perl gilt das gleiche, sofern die module fuer die betreffende datenbankschnittstelle geladen werden.

zum debuggen von cronjob-scripten gilt:

<i>some intelligent script stuff</i>
echo "step 1 done"
<i>some intelligent script stuff</i>
echo "step 2 done"
...

bin gespannt auf das script!

ratte

[hugenay]

Hallo ratte,
das Perl skript bastelt die sql Abfragen zusammen, in Abhängigkeit von u.a. der Uhrzeit, und dass ist für mich leicher in Perl als mit awk.
Da ich aber sqlplus aufrufen muss, mache ich dass mittels Commandosubstitution (system() würde nichts bringen, da sqlplus das entsprechend environment will). Ein Datenbankmodul hab ich nicht leider, sehr umständlich alles ...

Das debuggen habe ich übrigens in etwa so gemacht, der Fehler lag aber in der Einrichtung der crontab, statt 5 Felder für Ausführungszeit hatte ich 6 dahin gezaubert.

Und bitte nicht übel nehmen, dass ich das Skript nicht poste, sind noch sensible Daten drin, ich werd die demnächst rausnehmen und dann posten.

gruss hug.

[ratte]

auch fuer oracle gibt es perl::dbi module.

ratte

[hugenay]

haha, logisch gibts das, aber wenn ich das auf die rechner tue, gibts gewaltig aerger. bei hochkritischen systemen kann man nicht mal eben ein modul auf ne maschine kopieren, da gibts nen buerokratiches verfahren, dass am ende sowieso schlecht ausgeht. Und DBI ist immer noch nicht teil der Standard Distribution afaik.
gruss hug.

[ratte]

dagegen gibt's ein verfahren:

-beschriebene problematik dokumentieren.
-auf dem entwicklungsserver das modul installieren,
-perl scripten,
-das erfolgreiche ergebnis dokumentieren.
-request mit obiger dokumentation abgeben.

bureauxkrasssismus abwarten, modul auf dem produktionsserver installieren und weiter quake3 spielen - oder nur noch quake3 spielen und behaupten ohne dieses modul geht's eben nicht.

ratte

[hugenay]

Als Entwickler ist das kein Problem, aber als Admin kann man leider nicht einfach ans Entwicklungssystem.
Ausserdem, wenn man Komponenten von Fremdfirmen hat, kanns gut sein, dass die sich weigern und sagen, dass das gegen die Servicevertraege verstoesst. (da deren Software betroffen werden koennte).

jetzt wart ich erst mal auf doom 3 ...

[hugenay]

kleines update: fuer andere skripte mache ich jetzt doch so wie du sagst, die perl module aufs produktionssystem zu kopieren ist aber leider zuviel des guten <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">

[ratte]

haette gedacht, die situation ist umgekehrt:

als entwickler kommt man nicht so einfach nicht auf den entwicklungsserver, als admin ist das kein problem.

schliesslich stellt man als admin den entwicklungsserver fuer die entwickler zur verfuegung, oder ist das bei euch andersrum???



... ein entwicklungsserver von einer fremdfirma? das ist wohl ne verkehrte welt. schliesslich ist ein entwicklungsserver ein kann-jede-minute-zerkonfiguriert-werden-system...und wenn doch, zahlt ihr sicher support-gebuehren, dann wuerde ich die mal ausquetschen!

ratte

[hugenay]

nene, das Testsystem wurde irgendwann aufgesetzt und gut ist. Entwicklungssystem kann mans nicht nennen, denn Hard- und Software kommt von ner Fremdfirma, wir "betreiben" es sozusagen nur. Das ist wohl das besondere an der Situation, hab ich aber in grossen Firmen/Systemen schon oefter erlebt.
gruss hug.

[hugenay]

ach was lustiges hab ich nocht entdeckt: perl2exe, damit kann man perl standalone executables machen, auch schoen zum code verstecken wenn man will.
gruss hug.

[Thomas]

Nur ist perl2exe kommerziell. Mit perlcc (bei der Perl Distribution dabei) geht das auch.

Richtig interessant wird es aber erst mit PAR: http://use.perl.org/articles/02/11/02/2 ... html?tid=5

Gruss,
Thomas

[ratte]

pfui, perlcode verscrambeln? dann schreib' doch lieber sebst <!--http--><a href="http://www.perlmonks.org/index.pl?node= ... ted%20Code" target="_blank">Obfuscated code</a><!--url--> oder nimm php und lass dir den richtig teuren verzender[dunno url, ist halt pfui] zum quellcode verscrambeln von deiner geschaeftsverfuehrung teuer, teuer einkaufen, sklave!

ratte

[Thomas]

@ ratte: Schon mal daran gedacht, dass ich eventuell auch einfach mein Programm zusammen mit allen Modulen einem unbedarften Klicki-Bunti-User als einfaches Executable geben möchte? Das Programm selbst kann man dann immernoch mit allen use-Anweisungen im Quellcode downloaden, aber bitte nur an der, der auch weiss, was use Gtk; etc. heisst.

Es geht mir (und den Entwicklern von PAR) dabei also absolut nicht darum, den Quellcode zu verstecken, sondern um die Ausführgeschwindigkeit und die Einfachheit für einen Desktop-User.

Gruss,
Thomas

[hugenay]

In erster Linie geht es doch darum, ein Skript leicht installierbar zu machen und in manchen Situationen hat da eine einfache executable deutliche Vorteile: Vielleicht moechte man fuer 1 Skript nicht erklaeren und dokumentieren in welcher Reihenfolge notwendige Module installiert werden muessen (und perl -MCPAN kann man Zuhause machen aber nicht in ner kritischen Umgebung). Da find ich solche Programme sehr sinnvoll, aber hatte eben noch nicht gewusst, dass perl2exe kommerziell ist, werd mir bei Zeiten die Alternativen ansehen.
Achja QuellCode verstecken ist bei Skripten doch eh laecherlich und wenn um den Quellcode vor unbedarften Kollegen zu schuetzen die daran rumpfuschen koennten.
gruss hug.