Ich versuch's einfach noch mal mit einem anderen Betreff...
-------- Original Message --------
Hallo,
Ich habe Probleme mit zwei SuSE Linux 7.2 Professional Installationen, einmal nach einem Update von SuSE-Linux 6.2 und einmal bei einer Stand-Alone Installation:
Nach dem Update von SuSE-Linux 6.2 funktioniert der Druck auf Windows-Drucker mittels smbprint nicht mehr. Der smbclient wird zwar gestartet und schluckt permanent 100% CPU-Last, ein Ausdruck erfolgt aber nicht.
Auf dem gleichen System versagen Cron-Jobs, die mit 6.2 noch liefen auf eine ähnliche Weise. Hier hat in einigen der Cron-Skripte geholfen, eine Umleitung "< /dev/null" (ja, input, nicht output) anzuhängen. Auf dem komplett neu installierten System passiert das gleiche.
Weiterhin funktioniert die Einwahl per Modem auf das aktualisierten System nicht mehr Ordentlich (mgetty). Mit 6.2 alles paletti, mit 7.2 erscheint plötzlich Datenmüll (z.B. auch komplette Modem-Kommandos) in der Leitung.
An der anderen seriellen Schnittstelle sollte eigentlich eine USV von Best (Fortress) angesprochen werden. Seit dem Update findet die (neu kompilierte) Software die USV aber nicht mehr. Es spielt dabei keine Rolle ob der SuSE-2.4.4-4GB kernel installiert ist oder der 2.2er Kernel.
Und zu guter Letzt noch Schwierigkeiten mit apache + php4: Er startet nicht. Im error_log steht "[emerg] (22)Invalid argument: Failed to allocated shared memory". Das ist auf dem komplett neu installierten System der Fall. Entfernen und neu installieren von Apache & Zubehör hat hier nicht geholfen.
Hat jemand einen oder Mehrere Tips für mich wo ich nach den Ursachen suchen muß?
Noch ein Zusatz: Cron-Skripte, die selbst wieder skripte aufrufen schlagen trotz < /dev/null fehl.
Ich habe auf dem einen Rechner wieder neu installiert aber leider keinen Erfolg gehabt. Irgendwie funktioniert der ganze Kram, wenn er von Hand aufgerufen wird (auch das smbprint-Skript) jedoch nicht wenn er von dem jeweiligen Programm aufgerufen werden soll.
Der Installationssupport stellt sich dazu tot. Und hier auf der Liste scheint es niemand zu wissen. Falls ich nochwas herausfinden sollte, schreibe ich es hier. Im moment sind mir aber die Ideen ausgegangen.
Dirk Försterling wrote:
Ich versuch's einfach noch mal mit einem anderen Betreff...
-------- Original Message --------
Hallo,
Ich habe Probleme mit zwei SuSE Linux 7.2 Professional Installationen, einmal nach einem Update von SuSE-Linux 6.2 und einmal bei einer Stand-Alone Installation:
Nach dem Update von SuSE-Linux 6.2 funktioniert der Druck auf Windows-Drucker mittels smbprint nicht mehr. Der smbclient wird zwar gestartet und schluckt permanent 100% CPU-Last, ein Ausdruck erfolgt aber nicht.
Auf dem gleichen System versagen Cron-Jobs, die mit 6.2 noch liefen auf eine ähnliche Weise. Hier hat in einigen der Cron-Skripte geholfen, eine Umleitung "< /dev/null" (ja, input, nicht output) anzuhängen. Auf dem komplett neu installierten System passiert das gleiche.
Weiterhin funktioniert die Einwahl per Modem auf das aktualisierten System nicht mehr Ordentlich (mgetty). Mit 6.2 alles paletti, mit 7.2 erscheint plötzlich Datenmüll (z.B. auch komplette Modem-Kommandos) in der Leitung.
An der anderen seriellen Schnittstelle sollte eigentlich eine USV von Best (Fortress) angesprochen werden. Seit dem Update findet die (neu kompilierte) Software die USV aber nicht mehr. Es spielt dabei keine Rolle ob der SuSE-2.4.4-4GB kernel installiert ist oder der 2.2er Kernel.
Und zu guter Letzt noch Schwierigkeiten mit apache + php4: Er startet nicht. Im error_log steht "[emerg] (22)Invalid argument: Failed to allocated shared memory". Das ist auf dem komplett neu installierten System der Fall. Entfernen und neu installieren von Apache & Zubehör hat hier nicht geholfen.
Hat jemand einen oder Mehrere Tips für mich wo ich nach den Ursachen suchen muß?
* Dirk Försterling schrieb am 28.Sep.2001:
Noch ein Zusatz: Cron-Skripte, die selbst wieder skripte aufrufen schlagen trotz < /dev/null fehl.
Wie sieht das Skript denn aus? Was bedeutet, daß es fehl schlägt? Kommen da irgendwo Fehlermeldungen? Oder woher weißt Du, daß es fehl schlägt?
Hast Du beachtet, daß Cron keinem Terminal zugeordnet ist, und daß es ein viel kleineres Enviroment hat als gewohnt? Insbesondere sieht $PATH anders aus.
Das Skript selber und die Skripte die es aufruft sind ausführbar? Was soll die Eingabeumlenkung bringen? Ist da was Interaktives dabei? Dann wäre ich sehr vorsichtig. Das kann nicht funktionieren.
Ich habe auf dem einen Rechner wieder neu installiert aber leider keinen Erfolg gehabt. Irgendwie funktioniert der ganze Kram, wenn er von Hand aufgerufen wird (auch das smbprint-Skript) jedoch nicht wenn er von dem jeweiligen Programm aufgerufen werden soll.
Ohne nähere Angaben kann Dich da keiner weiterhelfen.
Der Installationssupport stellt sich dazu tot. Und hier auf der Liste scheint es niemand zu wissen.
Das hat mit Installation nichts zu tun. Für solche Probleme hast Du nicht bezahlt. So einfach ist das. Und mit den wenigen Angaben, die Du machst kann Dir hier auch kaum einer weiterhelfen.
Bernd
Naja, ich hatte das Ganze eigentlich zweimal relativ ausführlich gemailt.
Bernd Brodesser wrote:
- Dirk Försterling schrieb am 28.Sep.2001:
Noch ein Zusatz: Cron-Skripte, die selbst wieder skripte aufrufen schlagen trotz < /dev/null fehl.
Wie sieht das Skript denn aus? Was bedeutet, daß es fehl schlägt?
Kommen da irgendwo Fehlermeldungen? Oder woher weißt Du, daß es fehl schlägt?
Hier ein kleinstes skript, das mit SuSE-Linux 6.2 bis 7.0 funktioniert aber nicht mehr mit 7.2. Versionsstand des Zielrechners ist hierbei irrelevant.
#!/bin/bash /usr/bin/ssh -l user zielrechner /bin/cp /tmp/old /tmp/new > /dev/null
In der crontab aufrufen mit
0 12 * * * user /pfad/zum/skript
Es wurde dafür gesorgt, daß ein Paßwortloses login möglich ist. Wenn ich bei diesem einfachen skript eine Umleitung < /dev/null auch noch hinten dran hänge, läuft es, ansonsten bleibt es einfach hängen. Prozeß "Schläft". Wird statt ssh jedoch ein weiteres skritp oder ein Java-Programm aufgerufen das selbst wieder andere Programme aufruft (tar) dann gibt's ne I/O-Exception (illegal ioctl for this device). Wie gesagt: Erst mit 7.2 nicht mit 7.0. Von der Konsole oder aus einem xterm heraus funktioniert das Skript jedoch wunderbar.
Bei smbprint ("Drucker über Samba ansteuern) ist das anders gelagert, da hier cron nicht beteiligt ist. Wenn ich smbprint richtig verstanden habe leitet es die zu druckenden Daten via Pipe in smbclient. Zuvor werden noch Befehle in die Pipe geschrieben. Das funktioniert aber anscheinend nicht richtig. Smbprint ruft zwar den smbclient noch auf, aber dieser bleibt tatenlos aber mit 100% CPU-Last stehen ohne fortzuschreiten. Hier habe ich keine Ahnung wie ich drumrumarbeiten soll.
Hast Du beachtet, daß Cron keinem Terminal zugeordnet ist, und daß es ein viel kleineres Enviroment hat als gewohnt? Insbesondere sieht $PATH anders aus.
Das mit dem PATH ist klar. Das mit dem Terminal im allgemeinen auch. Bisher bedeutete das, daß Ausgaben ggf. Verloren sind und Programme bei Verlangen von Eingaben nicht weiterlaufen.
Das Skript selber und die Skripte die es aufruft sind ausführbar? Was soll die Eingabeumlenkung bringen? Ist da was Interaktives dabei? Dann wäre ich sehr vorsichtig. Das kann nicht funktionieren.
Nein. Alles ist in dieser Richtung O.K. Wie gesagt: Alles (Inklusive dem Modem- Zugang und der USV) lief _vor_ dem Upgrade von 6.2 auf 7.2 tadellos. Ein Transfer der Skripten auf ein neu installiertes System zeigte leider die gleichen Symptome.
Ich habe auf dem einen Rechner wieder neu installiert aber leider keinen Erfolg gehabt. Irgendwie funktioniert der ganze Kram, wenn er von Hand aufgerufen wird (auch das smbprint-Skript) jedoch nicht wenn er von dem jeweiligen Programm aufgerufen werden soll.
Ohne nähere Angaben kann Dich da keiner weiterhelfen.
Ich hatte vermutet, daß meine vielen Beispiele
Der Installationssupport stellt sich dazu tot. Und hier auf der Liste scheint es niemand zu wissen.
Das hat mit Installation nichts zu tun. Für solche Probleme hast Du nicht bezahlt. So einfach ist das.
Dann will ich sie auch nicht haben ;-}}}
Und mit den wenigen Angaben, die Du machst kann Dir hier auch kaum einer weiterhelfen.
Meinst du damit, daß der ganze Sermon, den ich in "Diverse Probleme...." am 26.09. schrieb nicht genug ist? Ich weiß ja nicht mal, wo ich anfangen soll, nach der Problemursache zu suchen, daher wollte ich hier nicht mein ganzes /etc/ sowie alle Skripten senden, die davon betroffen sind.
Hi Dirk
On Fri, Sep 28, 2001 at 10:53:56PM +0200, Dirk Försterling wrote:
Naja, ich hatte das Ganze eigentlich zweimal relativ ausführlich gemailt.
ich wollt mir das auch nicht geben, die waren nicht so das man vernünftig drauf antworten konnte, sorry is so.
Hier ein kleinstes skript, das mit SuSE-Linux 6.2 bis 7.0 funktioniert aber nicht mehr mit 7.2. Versionsstand des Zielrechners ist hierbei irrelevant.
#!/bin/bash /usr/bin/ssh -l user zielrechner /bin/cp /tmp/old /tmp/new > /dev/null
In der crontab aufrufen mit
0 12 * * * user /pfad/zum/skript
Es wurde dafür gesorgt, daß ein Paßwortloses login möglich ist. Wenn ich bei diesem einfachen skript eine Umleitung < /dev/null auch noch hinten dran hänge, läuft es, ansonsten bleibt es einfach hängen. Prozeß "Schläft".
das bedeutet imho das dieser Aufruf etwas ausgibt und zwar vermutlich in stderr das sollte zu sehen sein wenn du es auf der kommandozeile aufrufst oder das er eine interaktion verlangt.
Wenn man da nix sieht oder die meldung zum vergessen ist (weil auf der anderen seite nen altes ssh werkelt) dann hilft dir ein 2>&1 hinter der Ausgabeumleitung. Möglicherweise ist das aber auch die Frage die genau einmal kommt ob der gegenerische Host in die liste der known hosts eingetragen werden soll ... Wenn das alles nicht zutrifft schreib statt /dev/null ne richtige datei hin damit du mal siehst was schief läuft. cronjobs zu debuggen ist immer interessant und lustig, möglicherweise fehlt dem cp auch nur einfach sowas wie -f.
Wird statt ssh jedoch ein weiteres skritp oder ein Java-Programm aufgerufen das selbst wieder andere Programme aufruft (tar) dann gibt's ne I/O-Exception (illegal ioctl for this device). Wie gesagt: Erst mit 7.2 nicht mit 7.0. Von der Konsole oder aus einem xterm heraus funktioniert das Skript jedoch wunderbar.
es geht nicht nur darum ob es funktioniert, es geht auch darum ob es irgend eine Form der interaktion von dir verlangt. Ausserdem ist das Environment von cron /etwas/ spartanischer als von einem regulären user daher ist dieser Aufruf nicht in jedem Fall einfach so gleichzusetzen. Besagte Interaktion kann sich durchaus durch das eingeschränkte environment ergeben.
Der richtige Weg sowas zu debuggen ist zuerst am userpromt zu testen bis es geht und dann entsprechende logfiles zu definieren und das spiel unter kontrolle von cron zu wiederholen - der Schluss 'es geht am userprompt also muss es auch beim cron gehen' ist grundfalsch.
Bei smbprint ("Drucker über Samba ansteuern) ist das anders gelagert, da hier cron nicht beteiligt ist.
gut wenn wir hier schonmal von den gleichen vorr. ausgehen. :-)
Wenn ich smbprint richtig verstanden habe leitet es die zu druckenden Daten via Pipe in smbclient. Zuvor werden noch Befehle in die Pipe geschrieben. Das funktioniert aber anscheinend nicht richtig. Smbprint ruft zwar den smbclient noch auf, aber dieser bleibt tatenlos aber mit 100% CPU-Last stehen ohne fortzuschreiten. Hier habe ich keine Ahnung wie ich drumrumarbeiten soll.
es haben sich irgendwann mal ein paar Parameter des smbclient geändert - in der form das mehr spezifiziert werden sollte bei dessen aufruf, smbprint will/wollte bisher sich ja auch nur als Beispiel verstanden wissen, daher solltest du einfach mal den aufruf von smbclient von Hand zusammen bauen und die Ausgaben interpretieren, das ist dein job als Admin das nimmt dir SuSE nicht ab. Es sollte mich nicht wundern wenn dem yast2 an dieser Stelle Tribut gezollt wurde damit das per yast2 administrierbar wird.
Das mit dem PATH ist klar. Das mit dem Terminal im allgemeinen auch. Bisher bedeutete das, daß Ausgaben ggf. Verloren sind und Programme bei Verlangen von Eingaben nicht weiterlaufen.
ebend
Meinst du damit, daß der ganze Sermon, den ich in "Diverse Probleme...." am 26.09. schrieb nicht genug ist? Ich weiß ja nicht mal, wo ich anfangen soll, nach der Problemursache zu suchen, daher wollte ich hier nicht mein ganzes /etc/ sowie alle Skripten senden, die davon betroffen sind.
nein es war so geschrieben das keiner incl. me Lust hatte auf sowas schwammiges zu Antworten, das war exact mein Eindruck. Nicht der umfang eines postings entscheidet darüber ob ich Lust habe es zu beantworten sondern ob ich die Frage ohne grosses suchen extrahieren kann und ob die dazu erforderlichen Angaben vorhanden sind und als solche zu erkennen. Auf Postings wie 'wein halbes System geht nicht, sagt mir mal was ich alles machen muss' antworte ich nicht.
PS: wer ein update macht muss meistens damit rechnen selbstgeschriebenes anzupassen, das ist völlig normal und nicht pauschal ein Grund um auf SuSE zu schimpfen, obwohl im einen oder anderen Fall durchaus berechtigt aber erst wenn klar ist wo genau das Problem liegt.
Bernd Brodesser wrote:
Ohne nähere Angaben kann Dich da keiner weiterhelfen.
Ach so, einer fehlt noch:
Der Apache sagt mir wirklich nicht mehr außer "[emerg] (22)Invalid argument: Failed to allocated shared memory" im error_log, sobald PHP 4 installiert ist. Es handelt sich hier um eine SuSE-7.2 out-of-the Box mit 2.2er-Kernel (2.4.4-4GB auch ausprobiert). Wie soll ich nähere Angaben machen, wenn die Programme das nicht tun. Die hier zur Diskussion stehende Installation ist eine SuSE 7.2 vollinstallation ("einfach alles"). Nachdem die Platte doch recht wenig Platz hatte, wurde nahezu alles was mit X11 zu tun hat deinstalliert (soweit die Konflikte es erlaubt haben). Das Problem mit dem Apache trat davor auf und tritt nach der Abspeckung immernoch auf. Die Maschine hat 64MB RAM und 128MB swap.
Hi Dirk
On Fri, Sep 28, 2001 at 10:58:56PM +0200, Dirk Försterling wrote:
Ach so, einer fehlt noch:
Der Apache sagt mir wirklich nicht mehr außer "[emerg] (22)Invalid argument: Failed to allocated shared memory" im error_log, sobald PHP 4 installiert ist. Es handelt sich hier um eine SuSE-7.2 out-of-the Box mit 2.2er-Kernel (2.4.4-4GB auch ausprobiert). Wie soll ich nähere Angaben machen, wenn die Programme das nicht tun.
du könntest zb. mal auf http://sdb.suse.com/ nach samba suchen und wenn du da alles gemacht hast was bei deinem system in Frage kommt dich nochmal hier melden falls der Fehler immer noch auftritt.
Die hier zur Diskussion stehende Installation ist eine SuSE 7.2 vollinstallation ("einfach alles"). Nachdem die Platte doch recht wenig Platz hatte, wurde nahezu alles was mit X11 zu tun hat deinstalliert (soweit die Konflikte es erlaubt haben). Das Problem mit dem Apache trat davor auf und tritt nach der Abspeckung immernoch auf.
Das deutet darauf hin das du noch nicht obigem link gefolgt bist. Auserdem gibts im listenarchiv mindestens 100 Artikel zu diesem Thema.
PS: 'einfach alles' ist für einen apache den man auch benutzen will nicht wirklich eine gute Idee, beschränke dich einfach auf das was du wirklich brauchst.
Falk Sauer wrote:
Hi Dirk
On Fri, Sep 28, 2001 at 10:58:56PM +0200, Dirk Försterling wrote:
Ach so, einer fehlt noch:
Der Apache sagt mir wirklich nicht mehr außer "[emerg] (22)Invalid argument: Failed to allocated shared memory" im error_log, sobald PHP 4 installiert ist. Es handelt sich hier um eine SuSE-7.2 out-of-the Box mit 2.2er-Kernel (2.4.4-4GB auch ausprobiert). Wie soll ich nähere Angaben machen, wenn die Programme das nicht tun.
du könntest zb. mal auf http://sdb.suse.com/ nach samba suchen und wenn du da alles gemacht hast was bei deinem system in Frage kommt dich nochmal hier melden falls der Fehler immer noch auftritt.
Nun, sdb.suse.com ergibt bei mir nur "host not found". Falls Du sdb.suse.de meintest, dann habe ich da nachgesehen. Mit dem Stichwort "samba" finde ich ganze 13 Artikel, die größtenteils Steinalt sind und genau wie in http://sdb.suse.de/de/sdb/html/fehr_druck_1.html sieht auch der Druckerfilter hier aus. Nur daß er nicht läuft, d.h. smbclient bleibt bei 100% CPU-Last stecken. Die restlichen Artikel treffen nicht zu. Ansonsten habe ich auch schon andere Stichwörter durchprobiert. Diese Mailingliste ist für mich sozusagen der letzte Anlaufpunkt.
Aber was hat samba mit apache zu tun?
Jedenfalls habe ich auch nach "apache" gesucht und es handelt sich hier nicht um das ssl-Problem (ist installiert, die Fehlermeldung eine andere). Es ist auch nicht das PERL-Problem (Modulreihenfolge). Auch das Modul auth_ldap ist nicht installiert. Die anderen der 19 Artikel in der SDB treffen entweder nicht zu oder helfen nicht weiter (weil für zu alte Distribution bestimmt).
Die hier zur Diskussion stehende Installation ist eine SuSE 7.2 vollinstallation ("einfach alles"). Nachdem die Platte doch recht wenig Platz hatte, wurde nahezu alles was mit X11 zu tun hat deinstalliert (soweit die Konflikte es erlaubt haben). Das Problem mit dem Apache trat davor auf und tritt nach der Abspeckung immernoch auf.
Das deutet darauf hin das du noch nicht obigem link gefolgt bist.
Da kann ich nur widersprechen. Ich hatte die Mailingliste als letztes aufgesucht, da ich keine andere Lösung gefunden habe. sogar deja.com habe ich durchforstet. Speziell das Problem mit den Pipes in Skripten macht mir arge Kopfschmerzen, weil ich keine Ahnung habe ob sich das noch woanders auswirkt. Auch das Einfügen mit Backticks (also auch wieder Pipes) funktioniert nicht, wenn das Skript per cron oder lpd aufgerufen wird. Bei cron kann ich das fast immer beheben, wenn ich in der crontab die Datei_ein_leitung (nicht umleitung von stdout, sondern stdin) aus /dev/null heraus in das Skript hinzufüge (< /dev/null). Nach deiner anderen Antwort zu Urteilen scheinst Du zu vermuten, ich hätte mich vertippt.
Leider klappt diese Umleitung nicht mehr, wenn das aufgerufene Skript selbst wieder Programme startet, z.B. java oder andere Skripten. Die aufgerufenen Programme laufen einfach nicht. Die Umleitung von stdout und stderr in ein "log" ergibt hier stets eine leere Datei.
Noch ein Beispiel:
first.sh:
# !/bin/bash LS=`/bin/ssh ziel ls` REMDATE=`/bin/ssh ziel date` echo "... ${REMDATE} ... ${LS} ..." > /tmp/test echo `/home/user/bin/another.sh` >> /tmp/test
another.sh:
#! /bin/bash DATE=`/bin/ssh ziel date` echo "... ${DATE} ..."
Das Skript first.sh wird via cron aufgerufen:
00 12 * * * /home/user/bin/first.sh >> /tmp/cronlog 2>&1
Auf SuSE-Linux 7.0 klappt es auf Anhieb. Auf 7.2 passiert gar nichts. Im syslog von ziel taucht nicht mal ein ssh-Connect auf.
Ändere ich den crontab-Eintrag auf
00 12 * * * /home/user/bin/first.sh >> /tmp/cronlog 2>&1 < /dev/null
(Datei - Einleitung, also stdin)
dann läuft das Skript durch bis zum aufruf von another.sh in Backticks. Dieses wird nicht aufgerufen, d.h. es ist in /tmp/test am Ende kein Datum zu finden. Wie gesagt: Diese Konstellation läuft unverändert auf SuSE 7.0. Die Datei /tmp/cronlog enthält bei dem Beispiel nie etwas.
Ich habe hiermit versucht, das Problem auf einen kleinsten Nenner zu bringen. Es geht also nicht darum ob die Skripten korrekt sind, sondern warum hier Teile der Skripten (unter SuSE 7.2) nicht aufgerufen werden, und anscheinend dabei sdtin und/oder stdout eine Rolle spielt was es früher nicht tat.
Auserdem gibts im listenarchiv mindestens 100 Artikel zu diesem Thema.
Habe ich gesehen und gelesen. Möglicherweise habe ich auch was überlesen, da daß Archiv nicht gerade vor Komfortabilität strotzt. Mit dem mod_ssl hat der Fehler jedenfalls nix zu tun. Ich werd's dann nochmal mit einer von vornheherein kleineren Installation versuchen (was den apache angeht, das cron+smbprint-Problem habe ich nicht auf dem gleichen Rechner).
Hi Dirk
On Sat, Sep 29, 2001 at 01:38:11PM +0200, Dirk Försterling wrote:
du könntest zb. mal auf http://sdb.suse.com/ nach samba suchen und wenn du da alles gemacht hast was bei deinem system in Frage kommt dich nochmal hier melden falls der Fehler immer noch auftritt.
Nun, sdb.suse.com ergibt bei mir nur "host not found". Falls Du sdb.suse.de meintest, dann habe ich da nachgesehen. Mit dem Stichwort "samba" finde ich ganze 13 Artikel, die größtenteils Steinalt sind
ähm shit, man sollte halt nicht mails schreiben während man telefoniert. :-(
Aber was hat samba mit apache zu tun?
nichts :-/
Jedenfalls habe ich auch nach "apache" gesucht und es handelt sich hier nicht um das ssl-Problem (ist installiert, die Fehlermeldung eine andere). Es ist auch nicht das PERL-Problem (Modulreihenfolge). Auch das Modul auth_ldap ist nicht installiert. Die anderen der 19 Artikel in der SDB treffen entweder nicht zu oder helfen nicht weiter (weil für zu alte Distribution bestimmt).
du schriebst 'einfach alles' installiert zu haben und da kamen mir just diese Artikel in den sinn.
Da kann ich nur widersprechen. Ich hatte die Mailingliste als letztes aufgesucht, da ich keine andere Lösung gefunden habe. sogar deja.com habe ich durchforstet.
hm, was sagt denn ein apache ohne jedes Zusatzmodul?
Speziell das Problem mit den Pipes in Skripten macht mir arge Kopfschmerzen, weil ich keine Ahnung habe ob sich das noch woanders auswirkt. Auch das Einfügen mit Backticks (also auch wieder Pipes) funktioniert nicht, wenn das Skript per cron oder lpd aufgerufen wird. Bei cron kann ich das fast immer beheben, wenn ich in der crontab die Datei_ein_leitung (nicht umleitung von stdout, sondern stdin) aus /dev/null heraus in das Skript hinzufüge (< /dev/null). Nach deiner anderen Antwort zu Urteilen scheinst Du zu vermuten, ich hätte mich vertippt.
nein, aber deine Fehler hören sich für mich so an als wollte der cron eine eingabe haben die er vorher mit einer ausgabe näher erläutert, du wirst das problem nicht lösen indem du ihm eine null eingabe vorsetzt sondern nur wenn du ihm den wunsch nach einer eingabe austreibst.
Leider klappt diese Umleitung nicht mehr, wenn das aufgerufene Skript selbst wieder Programme startet, z.B. java oder andere Skripten. Die aufgerufenen Programme laufen einfach nicht. Die Umleitung von stdout und stderr in ein "log" ergibt hier stets eine leere Datei.
kann auch nicht funktionieren.
fang doch mal ganz klein an:
# !/bin/bash
^ Fehler!
LS=`/bin/ssh ziel ls`
^bei mir liegt ssh in /usr/bin
#!/bin/sh /usr/bin/ssh ziel ls > /tmp/log 2>&1
so täte ich anfangen, was steht dann in /tmp/log ? steht denn in /var/log/messages der cron event sauber drin? bekommt der cron user ne mail?
Ich habe hiermit versucht, das Problem auf einen kleinsten Nenner zu bringen. Es geht also nicht darum ob die Skripten korrekt sind, sondern warum hier Teile der Skripten (unter SuSE 7.2) nicht aufgerufen werden, und anscheinend dabei sdtin und/oder stdout eine Rolle spielt was es früher nicht tat.
mach doch erstmal das da oben und dann sehen wir weiter.
Habe ich gesehen und gelesen. Möglicherweise habe ich auch was überlesen, da daß Archiv nicht gerade vor Komfortabilität strotzt. Mit dem mod_ssl hat der Fehler jedenfalls nix zu tun. Ich werd's dann nochmal mit einer von vornheherein kleineren Installation versuchen (was den apache angeht, das cron+smbprint-Problem habe ich nicht auf dem gleichen Rechner).
ich kann das überhaupt nicht nachvollziehen, ich hab jetzt ungefähr 7 oder 8 7.2er am laufen und bisher immer den apachen recht schnell am laufen gehabt, allerdings immer nur das installiert was wirklich nötig ist.
Am Samstag, 29. September 2001 13.38 schrieb Dirk Försterling:
... Noch ein Beispiel:
first.sh:
# !/bin/bash LS=`/bin/ssh ziel ls` REMDATE=`/bin/ssh ziel date` echo "... ${REMDATE} ... ${LS} ..." > /tmp/test echo `/home/user/bin/another.sh` >> /tmp/test
another.sh:
#! /bin/bash DATE=`/bin/ssh ziel date` echo "... ${DATE} ..."
Das Skript first.sh wird via cron aufgerufen:
00 12 * * * /home/user/bin/first.sh >> /tmp/cronlog 2>&1
Auf SuSE-Linux 7.0 klappt es auf Anhieb. Auf 7.2 passiert gar nichts. Im syslog von ziel taucht nicht mal ein ssh-Connect auf.
Ändere ich den crontab-Eintrag auf
00 12 * * * /home/user/bin/first.sh >> /tmp/cronlog 2>&1 < /dev/null
(Datei - Einleitung, also stdin)
dann läuft das Skript durch bis zum aufruf von another.sh in Backticks. Dieses wird nicht aufgerufen, d.h. es ist in /tmp/test am Ende kein Datum zu finden. Wie gesagt: Diese Konstellation läuft unverändert auf SuSE 7.0. Die Datei /tmp/cronlog enthält bei dem Beispiel nie etwas.
Ich habe hiermit versucht, das Problem auf einen kleinsten Nenner zu bringen. Es geht also nicht darum ob die Skripten korrekt sind, sondern warum hier Teile der Skripten (unter SuSE 7.2) nicht aufgerufen werden, und anscheinend dabei sdtin und/oder stdout eine Rolle spielt was es früher nicht tat.
nur so ne Idee...
du benutzt ssh zum "zeil" ohne Passworteingabe, oder? könnter es sein, dass durch das neue System die Schlüssel nicht mehr dieselben wie früher sind und somit das Login gar nicht klappt?
Gruss Christian
Christian Hernmarck wrote:
Am Samstag, 29. September 2001 13.38 schrieb Dirk Försterling:
... Noch ein Beispiel:
first.sh:
# !/bin/bash LS=`/bin/ssh ziel ls`
[schnipp]
nur so ne Idee...
du benutzt ssh zum "zeil" ohne Passworteingabe, oder? könnter es sein, dass durch das neue System die Schlüssel nicht mehr dieselben wie früher sind und somit das Login gar nicht klappt?
Nein. An der SSH-Kommunikation im Speziellen und der Netzwerkkommunikation im Allgemeinen liegt es offensichtlich nicht. Mit Der Hilfe von Falk Sauer ist das Problem soweit runtergekocht worden, daß auf SuSE 7.2 aus irgendeinem Grund "stdin" nicht geöffnet werden kann. Dies ist definitiv via cron aufgerufenen Programmen der Fall. Wird der Befehl mittels strace ausgeführt kommt:
30494 read(0, 0xbffff41b, 1) = -1 EBADF (Bad file descriptor)
Ob das Verallgemeinert bei Programmen passiert, die von einem laufenden Dienst heraus aufgerufen werden (lpd, siehe smbprint-Problem am Anfang des Threads) muß ein Test noch zeigen.
Falls bei smbprint ein anderer Fehler vorliegt, so kann man ja noch von einem cron-Bug ausgehen (wie mir bereits an anderer Stelle einmal kurz "vorgeschlagen" wurde). Tritt bei lpd/smbprint (oder jedem beliebigen input-Filter für lpd) das gleiche Problem auf, dann mache ich mir schon eher sorgen.
Sehr interessant wäre es, falls jemand mit den nun Verfügbaren Informationen einen Tipp hätte, wo denn die Ursache liegen könnte: Anscheinend hat nicht jeder das Problem des "fehlenden" stdin. Ich hatte es dagegen auf einem Athlon einem Celeron und einem Dual-Xeon. Alle mit verschiedenen Installations- dichten ("Einfach Alles", "Minimal(Yast1)" und eine dritte Auswahl aus diversen SuSE-Installationsoptionen).
-dirk
-
B.Brodesser＠t-online.de -
Christian Hernmarck -
Dirk Försterling -
Falk Sauer