CUPS Freigaben im lokalen Netz gelegentlich unsichtbar
Hallo, ich habe hier ein seltsames Problem an einem PC: nach ca. jedem zehnten Rechner-Start sind alle an ihm angeschlossenen Drucker, trotz Freigabe, im lokalen Netzwerk nicht sichtbar. Alle Versuche mit "rccups stop; rcnetwork stop; rcnetwork start; rccups start" bzw. "cupsctl --no-share-printers ; cupsctl --share-printers" oder "cupsdisable ...; cupsenable ..." bleiben erfolglos. Kein anderer PC im Netz sieht dessen Drucker, auch nach "rccups stop/start" auf den clients. Andere Netzwerkdienste funktionieren aber. Erst nach einem reboot dieses PC funktioniert alles wieder wie es soll. Das ist leider keine einmalige Erscheinung, und nervt nun langsam. Wie kann ich diesen Fehler einkreisen? Hat jemand ähnliche Probleme? Ach so: es läuft OS 11.3 mit CUPS 1.4.4 aus den offiziellen repos. Gruß Dietmar Kühn -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, On May 3 13:51 Dietmar Kühn wrote (excerpt):
ich habe hier ein seltsames Problem an einem PC: nach ca. jedem zehnten Rechner-Start sind alle an ihm angeschlossenen Drucker, trotz Freigabe, im lokalen Netzwerk nicht sichtbar. ... Erst nach einem reboot dieses PC funktioniert alles wieder wie es soll. ... es läuft OS 11.3 mit CUPS 1.4.4 aus den offiziellen repos.
Leider habe ich derzeit keine Ahnung, was das sein könnte. Findet sich in /var/log/cups/error_log bei "LogLevel debug" etwas? Siehe "Get CUPS debug messages if it does not work" in http://en.opensuse.org/SDB:CUPS_in_a_Nutshell Gruß Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer
Am 03.05.2011 14:24, schrieb Johannes Meixner:
Hallo,
On May 3 13:51 Dietmar Kühn wrote (excerpt):
ich habe hier ein seltsames Problem an einem PC: nach ca. jedem zehnten Rechner-Start sind alle an ihm angeschlossenen Drucker, trotz Freigabe, im lokalen Netzwerk nicht sichtbar. ... Findet sich in /var/log/cups/error_log bei "LogLevel debug" etwas?
die einzige verdächtige Zeile, die aller paar Tage (mit anderer Zeitmarke) auftaucht, lautet: E [03/May/2011:12:12:01 +0200] Unable to bind broadcast socket - Address already in use. goggle liefert als ersten Treffer: http://www.linuxproblem.org/art_13.html Das sieht nach einer heißen Spur aus. Wie kann ich am besten verhindern, daß ein nicht-CUPS-programm den Port 631 belegt? Ich kann mir nicht vorstellen, daß ich fast der einzige bin, der dieses Problem hat.
Siehe "Get CUPS debug messages if it does not work" in http://en.opensuse.org/SDB:CUPS_in_a_Nutshell
Gruß Johannes Meixner
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am 03.05.2011 14:49, schrieb Dietmar Kühn:
Am 03.05.2011 14:24, schrieb Johannes Meixner:
Hallo,
On May 3 13:51 Dietmar Kühn wrote (excerpt):
ich habe hier ein seltsames Problem an einem PC: nach ca. jedem zehnten Rechner-Start sind alle an ihm angeschlossenen Drucker, trotz Freigabe, im lokalen Netzwerk nicht sichtbar.
... Findet sich in /var/log/cups/error_log bei "LogLevel debug" etwas?
die einzige verdächtige Zeile, die aller paar Tage (mit anderer Zeitmarke) auftaucht, lautet:
E [03/May/2011:12:12:01 +0200] Unable to bind broadcast socket - Address already in use.
goggle liefert als ersten Treffer: http://www.linuxproblem.org/art_13.html
Das sieht nach einer heißen Spur aus. Wie kann ich am besten verhindern, daß ein nicht-CUPS-programm den Port 631 belegt? Ich kann mir nicht vorstellen, daß ich fast der einzige bin, der dieses Problem hat.
Ergänzung: ich habe in der google-trefferliste weitergelesen. Es passiert offensichtlich häufig, daß vorm Start von CUPS der Port 631 nach Zufallsprinzip an einen anderen Dienst (mountd, statd, ...) vergeben wurde. Hier bin ich mit meinem Latein am ende, es sollten sich einmal Experten damit beschäftigen. Vielleicht kann man dem portmapper irgendwie verbieten, die 631 zu vergeben ?
Siehe "Get CUPS debug messages if it does not work" in http://en.opensuse.org/SDB:CUPS_in_a_Nutshell
Gruß Johannes Meixner
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, On May 3 15:08 Dietmar Kühn wrote (excerpt):
Findet sich in /var/log/cups/error_log bei "LogLevel debug" etwas? ... E [03/May/2011:12:12:01 +0200] Unable to bind broadcast socket - Address already in use.
goggle liefert als ersten Treffer: http://www.linuxproblem.org/art_13.html
Das sieht nach einer heißen Spur aus. Wie kann ich am besten verhindern, daß ein nicht-CUPS-programm den Port 631 belegt? Ich kann mir nicht vorstellen, daß ich fast der einzige bin, der dieses Problem hat.
Ergänzung: ich habe in der google-trefferliste weitergelesen. Es passiert offensichtlich häufig, daß vorm Start von CUPS der Port 631 nach Zufallsprinzip an einen anderen Dienst (mountd, statd, ...) vergeben wurde. Hier bin ich mit meinem Latein am ende, es sollten sich einmal Experten damit beschäftigen. Vielleicht kann man dem portmapper irgendwie verbieten, die 631 zu vergeben ?
Für viele Fälle sollte Port 631 gemäß der Einträge in /etc/bindresvport.blacklist geschützt sein, nämlich dann, wenn Programme die glibc Funktion bindresvport verwenden. Aber nichts kann ein beliebiges Programm daran hindern, sich Port 631 ohne Verwendung von bindresvport zu nehmen, wenn Port 631 während des Bootens noch frei ist zu einem Zeitpunkt an dem der cupsd noch nicht gestartet worden ist. Wie ich es derzeit sehe (ich bin aber hier kein Experte) hilft dann nur, solche Programme, die Port 631 nehmen, einzeln - wenn möglich - so zu konfigurieren, dass sie Port 631 nicht mehr nehmen. Gruß Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer
Hallo Herr Meixner, erstmal vielen Dank für die Info. Mein Verdacht war also richtig. Am 03.05.2011 15:58, schrieb Johannes Meixner:
Für viele Fälle sollte Port 631 gemäß der Einträge in /etc/bindresvport.blacklist geschützt sein, nämlich dann, wenn Programme die glibc Funktion bindresvport verwenden.
Aber nichts kann ein beliebiges Programm daran hindern, sich Port 631 ohne Verwendung von bindresvport zu nehmen, wenn Port 631 während des Bootens noch frei ist zu einem Zeitpunkt an dem der cupsd noch nicht gestartet worden ist.
Wie ich es derzeit sehe (ich bin aber hier kein Experte) hilft dann nur, solche Programme, die Port 631 nehmen, einzeln - wenn möglich - so zu konfigurieren, dass sie Port 631 nicht mehr nehmen.
Gruß Johannes Meixner
Das Problem ist nun zwar erkannt, eine brauchbare Lösung scheint es derzeit aber nicht zu geben. Welcher "Otto-Normalverbraucher" soll denn alle seine Programme einzeln so konfigurieren, daß Port 631 nicht benutzt wird? Das ist völlig unzumutbar, und wirft leider wieder einmal ein schlechtes Licht auf das ansonsten recht stabile und zuverlässige linux als Betriebssystem. Ich nutze es seit ca. 15 Jahren für meine tägliche Arbeit. Vielleicht könne man, als "workaround", am gesamten boot-prozeß etwas andern: zu einem sehr frühen Zeitpunkt einen Prozeß starten, dessen einzige Aufgabe darin besteht, Port 631 zu nehmen. In /etc/init.d/cups müßte bei "start" dieser Dienst dann beendet werden, und erst nach Freigabe von Port 631 der cupsd starten. Macht das sinn, oder gibt es bessere Lösungen? Gruß Dietmar Kühn -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am 04.05.2011 07:55, schrieb Dietmar Kühn:
Das Problem ist nun zwar erkannt, eine brauchbare Lösung scheint es derzeit aber nicht zu geben. Welcher "Otto-Normalverbraucher" soll denn alle seine Programme einzeln so konfigurieren, daß Port 631 nicht benutzt wird? Das ist völlig unzumutbar, und wirft leider wieder einmal ein schlechtes Licht auf das ansonsten recht stabile und zuverlässige linux als Betriebssystem. Ich nutze es seit ca. 15 Jahren für meine tägliche Arbeit.
Dafür gibt es ja Standards. 631 ist seit ewigen Zeiten definiert. Wenn sich andere Anwendungen diesen Port blockieren machen sie was falsch. Ralf Prengel Manager Customer Care Comline AG Hauert 8 D-44227 Dortmund/Germany Fon +49 231 97575 904 Fax +49 231 97575 257 Mobil +49 151 10831 157 EMail Ralf.Prengel@comline.de www.comline.de Vorstand Stephan Schilling, Erwin Leonhardi Aufsichtsrat Dr. Franz Schoser (Vorsitzender) HR Dortmund B 14570 USt.-ID-Nr. DE 124727422 Für die Erstellung unserer Dokumente benutzen wir die Produkte aus dem Microsoft Office 2007 Paket. Sollte sich ein Anhang in der Mail befinden, der mit einer älteren Office Version nicht geöffnet werden kann, installieren Sie bitte das Compatibility Pack für Office 2007. http://www.microsoft.com/downloads/details.aspx?FamilyID=941b3470-3ae9-4aee-8f43-c6bb74cd1466&DisplayLang=de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, On May 4 07:55 Dietmar Kühn wrote (excerpt):
Am 03.05.2011 15:58, schrieb Johannes Meixner:
Für viele Fälle sollte Port 631 gemäß der Einträge in /etc/bindresvport.blacklist geschützt sein, nämlich dann, wenn Programme die glibc Funktion bindresvport verwenden.
Aber nichts kann ein beliebiges Programm daran hindern, sich Port 631 ohne Verwendung von bindresvport zu nehmen, wenn Port 631 während des Bootens noch frei ist zu einem Zeitpunkt an dem der cupsd noch nicht gestartet worden ist.
Wie ich es derzeit sehe (ich bin aber hier kein Experte) hilft dann nur, solche Programme, die Port 631 nehmen, einzeln - wenn möglich - so zu konfigurieren, dass sie Port 631 nicht mehr nehmen.
Das Problem ist nun zwar erkannt, eine brauchbare Lösung scheint es derzeit aber nicht zu geben. Welcher "Otto-Normalverbraucher" soll denn alle seine Programme einzeln so konfigurieren, daß Port 631 nicht benutzt wird?
Ja leider - ich bin aber hier kein Experte, um fundierte Ausagen dazu machen zu können.
Das ist völlig unzumutbar, und wirft leider wieder einmal ein schlechtes Licht auf das ansonsten recht stabile und zuverlässige linux als Betriebssystem.
Wie ich es sehe, ist es letztlich dasselbe "schlechte Licht", was auf jeder Art von freier Entscheidungsfindung liegt, wo es nicht ein totalitäres Oberkommando gibt, was für alle die Entscheidungen fällt und durchsetzt, sondern wo statt totalitärer Befehle langsame, mühevolle Prozesse einen Konsens und die Akzeptanz aller Beteiligten finden müssen. Der Wunsch nach einem weisen, gütigen Oberkommandierenden, der für alle sorgt und alles richtig macht, ist niemals auf Dauer erfüllbar. Hart formuliert: Wer freie Strukturen nicht mittragen will, soll halt "auswandern" und sich einem totalitären Oberkommando unterwerfen und muss dann aber auch die Konsequenzen daraus aushalten. Kurz: Entweder freie Software und die Konsequenzen der Freiheit mittragen, oder proprietäre Software und auf die eigene Freiheit verzichten.
Vielleicht könne man, als "workaround", am gesamten boot-prozeß etwas andern: zu einem sehr frühen Zeitpunkt einen Prozeß starten, dessen einzige Aufgabe darin besteht, Port 631 zu nehmen. In /etc/init.d/cups müßte bei "start" dieser Dienst dann beendet werden, und erst nach Freigabe von Port 631 der cupsd starten.
portreserve macht das, siehe http://cyberelk.net/tim/software/portreserve/ und https://bugzilla.redhat.com/show_bug.cgi?id=103401 Immerhin hat Red Hat von August 2003 bis November 2010 gebraucht, sich zu einigen, wie das Problem in Red Hat Enterprise Linux 6.0 behandelt wird. Vermutlich gibt es Gründe, warum portreserve nicht bzw. noch nicht bei openSUSE verwendet wird. Wir haben bzgl. portreserve auch einen FATE Feature-Request: https://fate.novell.com/311668 Aber der ursprüngliche Request "Add portreserve rpm (NFS)" wurde mittlerweile abgeschwächt zu "ask for the inclusion of port 657 / rmc in /etc/bindresvport.blacklist" weil es hierbei eigentlich um "stealing well-known ports via bindsresvport" geht was sich via /etc/bindresvport.blacklist abstellen läßt. Wie gesagt: Ich bin hier kein Experte, um fundierte Ausagen zu dem Themenbereich machen zu können. Gruß Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer
Am Wed, 04 May 2011 07:55:32 +0200
schrieb Dietmar Kühn
Hallo Herr Meixner, erstmal vielen Dank für die Info. Mein Verdacht war also richtig.
Am 03.05.2011 15:58, schrieb Johannes Meixner:
Für viele Fälle sollte Port 631 gemäß der Einträge in /etc/bindresvport.blacklist geschützt sein, nämlich dann, wenn Programme die glibc Funktion bindresvport verwenden.
Aber nichts kann ein beliebiges Programm daran hindern, sich Port 631 ohne Verwendung von bindresvport zu nehmen, wenn Port 631 während des Bootens noch frei ist zu einem Zeitpunkt an dem der cupsd noch nicht gestartet worden ist.
Wie ich es derzeit sehe (ich bin aber hier kein Experte) hilft dann nur, solche Programme, die Port 631 nehmen, einzeln - wenn möglich - so zu konfigurieren, dass sie Port 631 nicht mehr nehmen. [...] Das Problem ist nun zwar erkannt, eine brauchbare Lösung scheint es derzeit aber nicht zu geben. Welcher "Otto-Normalverbraucher" soll denn alle seine Programme einzeln so konfigurieren, daß Port 631 nicht benutzt wird? Das ist völlig unzumutbar, und wirft leider wieder einmal ein schlechtes Licht auf das ansonsten recht stabile und zuverlässige linux als Betriebssystem. Ich nutze es seit ca. 15 Jahren für meine tägliche Arbeit. Vielleicht könne man, als "workaround", am gesamten boot-prozeß etwas andern: zu einem sehr frühen Zeitpunkt einen Prozeß starten, dessen einzige Aufgabe darin besteht, Port 631 zu nehmen. In /etc/init.d/cups müßte bei "start" dieser Dienst dann beendet werden, und erst nach Freigabe von Port 631 der cupsd starten. Macht das sinn, oder gibt es bessere Lösungen?
Was ergibt denn, als root, # lsof -i:631 Das sollte wenigstens anzeigen, welcher Dienst sich diesen Port widerrechtlich gekapert hat. -Dieter -- Dieter Klünter | Systemberatung sip: 7770535@sipgate.de http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am 04.05.2011 11:21, schrieb Dieter Kluenter:
Was ergibt denn, als root, # lsof -i:631
Das sollte wenigstens anzeigen, welcher Dienst sich diesen Port widerrechtlich gekapert hat.
-Dieter
Hallo, danke für den Tipp mit lsof, ich hatte gerade nach einer Möglichkeit zur Auflistung der z.Zt. genutzten Ports gesucht. mit und ohne cups: a30:~ # rccups stop Shutting down cupsd a30:~ # lsof -i:631 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME rpc.mount 2567 root 17u IPv4 7410 0t0 UDP *:ipp a30:~ # rccups start Starting cupsd a30:~ # lsof -i:631 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME rpc.mount 2567 root 17u IPv4 7410 0t0 UDP *:ipp cupsd 20846 root 4u IPv4 1289848 0t0 TCP *:ipp (LISTEN) cupsd 20846 root 6u IPv6 1289849 0t0 TCP *:ipp (LISTEN) "rpcinfo -p" hat die 631 nicht mit aufgelistet. "rcnfsserver restart" beendet zwar den Spuk, doch wie kann man hier auf Dauer eine Abhilfe schaffen ? genügt es vielleicht, die Reihenfolge der init-scripte beim booten zu ändern? Gruß Dietmar -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am 04.05.2011 11:44, schrieb Dietmar Kühn:
Am 04.05.2011 11:21, schrieb Dieter Kluenter:
Was ergibt denn, als root, # lsof -i:631
Das sollte wenigstens anzeigen, welcher Dienst sich diesen Port widerrechtlich gekapert hat.
-Dieter
Hallo, danke für den Tipp mit lsof, ich hatte gerade nach einer Möglichkeit zur Auflistung der z.Zt. genutzten Ports gesucht.
mit und ohne cups:
a30:~ # rccups stop Shutting down cupsd a30:~ # lsof -i:631 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME rpc.mount 2567 root 17u IPv4 7410 0t0 UDP *:ipp a30:~ # rccups start Starting cupsd
a30:~ # lsof -i:631 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME rpc.mount 2567 root 17u IPv4 7410 0t0 UDP *:ipp cupsd 20846 root 4u IPv4 1289848 0t0 TCP *:ipp (LISTEN) cupsd 20846 root 6u IPv6 1289849 0t0 TCP *:ipp (LISTEN)
"rpcinfo -p" hat die 631 nicht mit aufgelistet.
"rcnfsserver restart" beendet zwar den Spuk, doch wie kann man hier auf Dauer eine Abhilfe schaffen ? genügt es vielleicht, die Reihenfolge der init-scripte beim booten zu ändern?
probehalber habe ich cups und cron in die "# Required-Start: " - zeile in /etc/init.d/nfsserver eingefügt, nun sind die symlinks in den rc.?-dirs anders sortiert. Das ist wohl keine saubere Lüsung, aber ich hoffe, daß es so funktioniert.
Gruß Dietmar
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Dietmar Kühn wrote:
Am 04.05.2011 11:44, schrieb Dietmar Kühn:
Am 04.05.2011 11:21, schrieb Dieter Kluenter:
Was ergibt denn, als root, # lsof -i:631
Das sollte wenigstens anzeigen, welcher Dienst sich diesen Port widerrechtlich gekapert hat.
-Dieter
Hallo, danke für den Tipp mit lsof, ich hatte gerade nach einer Möglichkeit zur Auflistung der z.Zt. genutzten Ports gesucht.
mit und ohne cups:
a30:~ # rccups stop Shutting down cupsd a30:~ # lsof -i:631 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME rpc.mount 2567 root 17u IPv4 7410 0t0 UDP *:ipp [...] "rcnfsserver restart" beendet zwar den Spuk, doch wie kann man hier auf Dauer eine Abhilfe schaffen ?
mountd auf einen festen Port legen (bei mir: 694) dazu in /etc/sysconfig/nfs einfach einen mountd port eintragen (dann hat man es auch mit firewall regeln für nfs viel leichter) Andreas bei dem nfsd und cupsd seit Jahren auf "ihren" Ports laufen -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hi dietmar, Am Mittwoch, 4. Mai 2011 11:44:46 schrieb Dietmar Kühn:
Am 04.05.2011 11:21, schrieb Dieter Kluenter:
"rcnfsserver restart" beendet zwar den Spuk, doch wie kann man hier auf Dauer eine Abhilfe schaffen ? genügt es vielleicht, die Reihenfolge der init-scripte beim booten zu ändern?
workaround! (von der schlimmsten sorte!) du schreibst dir ein perl programm was den port belegt, startest es gleich nach dem netzwerk init und killst es im initscript des cups. -- Gruss Falk -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am 04.05.2011 12:09, schrieb Falk Sauer:
Hi dietmar,
Am Mittwoch, 4. Mai 2011 11:44:46 schrieb Dietmar Kühn:
Am 04.05.2011 11:21, schrieb Dieter Kluenter:
"rcnfsserver restart" beendet zwar den Spuk, doch wie kann man hier auf Dauer eine Abhilfe schaffen ? genügt es vielleicht, die Reihenfolge der init-scripte beim booten zu ändern?
workaround! (von der schlimmsten sorte!)
du schreibst dir ein perl programm was den port belegt, startest es gleich nach dem netzwerk init und killst es im initscript des cups.
Es wäre doch eher zu klären warum NFS sich 631 krallt. Da ist was richtig schief konfiguriert. Gruß Ralf Prengel Manager Customer Care Comline AG Hauert 8 D-44227 Dortmund/Germany Fon +49 231 97575 904 Fax +49 231 97575 257 Mobil +49 151 10831 157 EMail Ralf.Prengel@comline.de www.comline.de Vorstand Stephan Schilling, Erwin Leonhardi Aufsichtsrat Dr. Franz Schoser (Vorsitzender) HR Dortmund B 14570 USt.-ID-Nr. DE 124727422 Für die Erstellung unserer Dokumente benutzen wir die Produkte aus dem Microsoft Office 2007 Paket. Sollte sich ein Anhang in der Mail befinden, der mit einer älteren Office Version nicht geöffnet werden kann, installieren Sie bitte das Compatibility Pack für Office 2007. http://www.microsoft.com/downloads/details.aspx?FamilyID=941b3470-3ae9-4aee-8f43-c6bb74cd1466&DisplayLang=de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am 04.05.2011 12:22, schrieb Ralf Prengel:
Am 04.05.2011 12:09, schrieb Falk Sauer:
Hi dietmar,
Am Mittwoch, 4. Mai 2011 11:44:46 schrieb Dietmar Kühn:
Am 04.05.2011 11:21, schrieb Dieter Kluenter:
"rcnfsserver restart" beendet zwar den Spuk, doch wie kann man hier auf Dauer eine Abhilfe schaffen ? genügt es vielleicht, die Reihenfolge der init-scripte beim booten zu ändern?
workaround! (von der schlimmsten sorte!)
du schreibst dir ein perl programm was den port belegt, startest es gleich nach dem netzwerk init und killst es im initscript des cups.
daran dachte ich auch schon, aber mit meinem "Workaround" ging es schneller.
Es wäre doch eher zu klären warum NFS sich 631 krallt. Da ist was richtig schief konfiguriert.
volle Zustimmung. Bis sich da etwas ändert, muß mein "Workaround" herhalten. Danke Euch allen für die Hilfe und Denk-anstöße ! Vielleich hilft es auch anderen Nutzern. Gruß Dietmar Kühn
Gruß Ralf Prengel Manager Customer Care Comline AG Hauert 8 D-44227 Dortmund/Germany
Fon +49 231 97575 904 Fax +49 231 97575 257 Mobil +49 151 10831 157 EMail Ralf.Prengel@comline.de
www.comline.de Vorstand Stephan Schilling, Erwin Leonhardi Aufsichtsrat Dr. Franz Schoser (Vorsitzender) HR Dortmund B 14570 USt.-ID-Nr. DE 124727422
Für die Erstellung unserer Dokumente benutzen wir die Produkte aus dem Microsoft Office 2007 Paket. Sollte sich ein Anhang in der Mail befinden, der mit einer älteren Office Version nicht geöffnet werden kann, installieren Sie bitte das Compatibility Pack für Office 2007. http://www.microsoft.com/downloads/details.aspx?FamilyID=941b3470-3ae9-4aee-8f43-c6bb74cd1466&DisplayLang=de
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (6)
-
Dieter Kluenter -
Dietmar Kühn -
Falk Sauer -
Johannes Meixner -
Kyek, Andreas, VF-DE -
Ralf Prengel