[gelöst] openSUSE 11.1 atd startet nicht

oelk · 29 Juli 2009

Hallo zusammen,

habe openSUSE 11.1 in einer VM laufen(VirtualBox), ohne KDE oder GNOME
Zunächst nur mit SAMBA, das geht auch alles soweit.

Bis auf die Tatsache das er beim Booten den ATD nicht startet.
Wenn er fertig mit booten ist kann ich ihn manuell starten mit rcatd start.

Ich hab schon die Runlevel in YaST nachgeschaut/gesetzt, das ganze über chkconfig
probiert.

Gibt's da eine Lösung?

MfG

whois · 30 Juli 2009

Ist denn hier das Startscript drin?

Code:

/etc/init.d/atd

http://de.opensuse.org/Paketbau/SUSE-Paketkonventionen/Init-Skripte

oelk · 30 Juli 2009

Ja, ist drin
Auf Konsole 10 kommt ein "I/O Permission denied"

MfG

whois · 30 Juli 2009

oelk schrieb:
Auf Konsole 10 kommt ein "I/O Permission denied"

Hmm?

Hast du dir mal die Rechte an dem Script angesehen,darf es ausgeführt werden?

/edit:Sorry ist ja Blödsinn sonst könnte es auch so nicht gestartet werden.

oelk · 30 Juli 2009

Hier nochmal die genaue Meldung:
Error Redirecting I/O: Permission denied

Nach abgschlossenem Boot-Prozess kann ich ihn starten (rcatd start)
und er läuft dann auch.

MfG

Anonymous · 31 Juli 2009

oelk schrieb:
Hier nochmal die genaue Meldung:
Error Redirecting I/O: Permission denied

Irgendwie kann ich nicht ganz glauben, das diese Meldung vom Start des atd kommen soll.
Zur Sicherheit aus der Konsole als Root noch mal neu als Runlevelscript aktivieren.

Code:

insserv -r atd
insserv  atd

dann sollte folgender Befehl etwas finden.

Code:

ls /etc/init.d/rc3.d/S*atd

neu gestartet würde er aber nach dieser neu Konfiguration auch erst mit dem nächsten reboot, oder einstweilen per Hand

robi

oelk · 31 Juli 2009

Hi,

hab ich so gemacht, brachte aber nichts.
Will ich über YaST/Runlevel den atd wieder starten, kommt die Meldung
das er den boot.clock auch starten will.
also hab ich das ganze Prozedere nochmal mit diesem gemacht.
Brachte aber auch nichts.

Nun, da geht ja so einiges nicht bei genauer Betrachtung:
Ruft zB man smb.conf auf, kommt erstmal

Code:

/usr/bin/nroff: line 8: /dev/null: Keine Berechtigung
/usr/bin/nroff: line 160: /dev/null: Keine Berechtigung

Eigentlich möchte ich auf der Maschine oracle-xe installieren, aber auch das bleibt hängen.

MfG

Anonymous · 31 Juli 2009

oelk schrieb:
Code:

/usr/bin/nroff: line 8: /dev/null: Keine Berechtigung /usr/bin/nroff: line 160: /dev/null: Keine Berechtigung

Nur mal so eine Vermutung

schau dir doch mal dein /dev/null etwas genauer an. Unter Umständen kommt es auch schon mal vor das man sich den Deviceknoten /dev/null löscht. Der nächste Befehl der dann nach /dev/null schreibt, legt dann dort durch die Konsolumleitung aber jetzt eine normale Datei an, und jeder Befehl der danach neu nach /dev/null schreibt wird diese normale Datei wieder überschreiben. Das geht zur Not auch ne ganze Weile gut, ist zwar langsamer, und kann uU auch mal den Speicherplatz auf der Festplatte sprengen, fällt aber oftmals erst auf, wenn jemand keine ausreichenden Rechte hat, dort hin zu schreiben. Bin mir jetzt nicht so ganz sicher wie das devfs bei Linux darauf beim hochfahren reagiert :???: , aber ich kenne ähnliche Fehlermeldungen und auch solche lustigen Probleme noch von früher und von anderen Unixsystemen.

Sicherheitshalber auch mal hier vorbeischauen, da es eventuell nur während der eventuellen frühen Bootphase auftreten könnte, könnte es durchaus auch ein Datei /dev/null betreffen die später beim mounten mit dem devfs überdeckt wird, und die du vom System aus also so gar nicht zu Gesicht bekommst. Ursache hier könnten zB sein, unqualifizierte Änderungen an Bootscripten, oder eigene Scripte die viel zu früh ausgeführt werden.

robi

josef-wien · 31 Juli 2009

oelk schrieb:
kommt die Meldung das er den boot.clock auch starten will

Voraussetzungen für das Init-Skript atd sind:

Code:

$remote_fs $time

Symbolische Parameter laut insserv.conf:

Code:

$remote_fs      $local_fs +nfs +smbfs
$local_fs       boot.localfs +boot.crypto
$time           boot.clock +xntpd

Ich vermute daher, daß atd deshalb nicht automatisch gestartet wird, weil die notwendigen Voraussetzungen nicht erfüllt sind. Dieser Umstand sowie Deine Fehlermeldungen lassen den Schluß zu, daß Dein System nicht widerspruchsfrei konfiguriert ist. Frage mich aber nicht, was Du tun mußt, denn mit derartigen Konfigurationen habe ich mich nicht befaßt.

oelk · 1 Aug. 2009

[/quote]

Nur mal so eine Vermutung

schau dir doch mal dein /dev/null etwas genauer an. Unter Umständen kommt es auch schon mal vor das man sich den Deviceknoten /dev/null löscht. Der nächste Befehl der dann nach /dev/null schreibt, legt dann dort durch die Konsolumleitung aber jetzt eine normale Datei an, und jeder Befehl der danach neu nach /dev/null schreibt wird diese normale Datei wieder überschreiben. Das geht zur Not auch ne ganze Weile gut, ist zwar langsamer, und kann uU auch mal den Speicherplatz auf der Festplatte sprengen, fällt aber oftmals erst auf, wenn jemand keine ausreichenden Rechte hat, dort hin zu schreiben. Bin mir jetzt nicht so ganz sicher wie das devfs bei Linux darauf beim hochfahren reagiert :???: , aber ich kenne ähnliche Fehlermeldungen und auch solche lustigen Probleme noch von früher und von anderen Unixsystemen.

Sicherheitshalber auch mal hier vorbeischauen, da es eventuell nur während der eventuellen frühen Bootphase auftreten könnte, könnte es durchaus auch ein Datei /dev/null betreffen die später beim mounten mit dem devfs überdeckt wird, und die du vom System aus also so gar nicht zu Gesicht bekommst. Ursache hier könnten zB sein, unqualifizierte Änderungen an Bootscripten, oder eigene Scripte die viel zu früh ausgeführt werden.
[/quote]

Ich weiss jetzt grad nicht was oder wie ich da nachschauen soll.
/dev/nul löschen ?
Jeder Installationsversuch geht übrigens bei mir so aus.

MfG

oelk · 1 Aug. 2009

josef-wien schrieb:
oelk schrieb:

kommt die Meldung das er den boot.clock auch starten will

Zum Vergrößern anklicken....

Voraussetzungen für das Init-Skript atd sind:

Code:

$remote_fs $time

Symbolische Parameter laut insserv.conf:

Code:

$remote_fs $local_fs +nfs +smbfs $local_fs boot.localfs +boot.crypto $time boot.clock +xntpd

Ich vermute daher, daß atd deshalb nicht automatisch gestartet wird, weil die notwendigen Voraussetzungen nicht erfüllt sind. Dieser Umstand sowie Deine Fehlermeldungen lassen den Schluß zu, daß Dein System nicht widerspruchsfrei konfiguriert ist. Frage mich aber nicht, was Du tun mußt, denn mit derartigen Konfigurationen habe ich mich nicht befaßt.

Die Logik krieg ich nicht zusammen:
warum brauch ich für atd ein $remote_fs $local_fs +nfs +smbfs ?
nfs wollte ich eigentlich nicht machen und boot.crypto ist standardmässig
auch nicht eingeschaltet.

Alles sehr merkwürdig...

MfG

oelk · 1 Aug. 2009

josef-wien schrieb:
oelk schrieb:

kommt die Meldung das er den boot.clock auch starten will

Zum Vergrößern anklicken....

Voraussetzungen für das Init-Skript atd sind:

Code:

$remote_fs $time

Symbolische Parameter laut insserv.conf:

Code:

$remote_fs $local_fs +nfs +smbfs $local_fs boot.localfs +boot.crypto $time boot.clock +xntpd

Ich vermute daher, daß atd deshalb nicht automatisch gestartet wird, weil die notwendigen Voraussetzungen nicht erfüllt sind. Dieser Umstand sowie Deine Fehlermeldungen lassen den Schluß zu, daß Dein System nicht widerspruchsfrei konfiguriert ist. Frage mich aber nicht, was Du tun mußt, denn mit derartigen Konfigurationen habe ich mich nicht befaßt.

Also, das war's jetzt auch nicht.
chkconfig boot.crypto on network-remotefs on
reboot
rcatd wird zwar gestartet, taucht aber in der Prozessliste nicht auf.

MfG

Anonymous · 1 Aug. 2009

oelk schrieb:
Ich weiss jetzt grad nicht was oder wie ich da nachschauen soll.
/dev/nul löschen ?
Jeder Installationsversuch geht übrigens bei mir so aus.

Code:

LINUX:~ # ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 Nov 25  2006 /dev/null
LINUX:~ # mount -o bind / /mnt
LINUX:~ # ls -l /mnt/dev/null
crw-rw-rw- 1 root root 1, 3 Aug  5  2007 /mnt/dev/null
LINUX:~ # umount /mnt

Wichtig dabei crw-rw-rw- .... root root 1, 3
sowas hier währe zB fehlerhaft

-rw-r--r-- 1 root root 1084 Jun 24 20:11 /dev/null

hier in dieser Befehlsfolge der 2. ls darf auch so hier ausgehen, das passt dann auch

Code:

ls: cannot access /mnt/dev/null: No such file or directory

nur wenn die Datei vorhanden sein sollte, dann sollte sie auch richtig sein.

reparieren läßt sich sowas folgerndermaßen

Code:

rm /dev/null
mknod -m 666 /dev/null c 1 3

-----------

oelk schrieb:
Jeder Installationsversuch geht übrigens bei mir so aus.

Zu unpäzise um damit was anzufangen. Installation was? genaue Fehlermeldung mit ca 10 Zeilen davor und eventuellen 5 Zeilen danach währen nicht schlecht?

oelk schrieb:
rcatd wird zwar gestartet, taucht aber in der Prozessliste nicht auf.

rcatd wird dort auch nicht auftauchen sondern sowas hier

Code:

LINUX:~ # ps -efl | grep atd
1 S at        3505     1  0  80   0 -   445 -      11:51 ?        00:00:00 /usr/sbin/atd

robi

oelk · 1 Aug. 2009

Also, ein ls -l /dev/null liefert mir:

Code:

ls -l /dev/null
crw-rw---- 1,3 root root /dev/null

Nach dem mounten:

Code:

ls -l /mnt/dev/null
crw-rw-rw- 1,3 root root /mnt/dev/null

oelk hat geschrieben:Jeder Installationsversuch geht übrigens bei mir so aus.

Damit meinte ich eigentlich nur, das passiert nicht nur manchmal sondern bei jedem Installationsversuch.
Ich probier das zuhause mit:
Host openSUSE 11.0
Virtualbox 3.0.2
und in der Firma auf realer HardwareHardware und immer und immer wieder.

LINUX:~ # ps -efl | grep atd

Ne, leider nur der Aufruf von grep.

Gut, nach dem löschen und neu anlegen von /dev/null
bringt er die Meldung mit "Failed services in runlevel 3 atd nicht mehr.

Aber beim Aufruf einer man-page steht oben drüber:

Code:

/usr/bin/nroff: line 8: /dev/null: keine Berechtigung

Hm, ich bin auf der Konsole als root, kein gnome oder kde
und ich darf es trotzdem nicht?

Wie erklärt sich das?

MfG

oelk · 1 Aug. 2009

Übrigens sthet es bei openSUSE 11.0 richtig drin

Code:

crw-rw-rw- l root root 1, 3 Nov 25 2009 /dev/null

In openSUSE 11.1 steht merkwürdigerweise in /etc/permissions:

Code:

/dev/null   root root  666

Das wird scheinbar nicht berücksichtigt.

Lösche ich /dev/null und setze es neu mit mknod kann man auch zB eine man-page aufrufen,
alles wunderbar.
Aber wehe ich boote neu, dann stimmt's wieder nicht.

MfG

Anonymous · 1 Aug. 2009

wenn du ständig nach dem booten die falschen Zugriffsrechte dort hast, dann überprüf mal folgendes

Code:

grep null /etc/udev/rules.d/*udev-default*

herauskommen sollte das hier

Code:

KERNEL=="null|zero|random",     MODE="0666"

steht da was anderes , dann als nächste mal das hier prüfen

Code:

rpm -V udev

wenn du dort eine Ausgabe bekommst, mit einer Zeile mit der obrigen Datei in der vorne bei den Eigenschaften mehr als Punkte und ein "T" stehen sollte (zb eine "5" ) , dann ist zu vermuten das irgend jemand nicht sauber an den udev-Regeln rumgespielt hat.

Dann währe zu überlegen das udev-Paket mal zu aktualisieren.

robi

PS habe das jetzt mal selbst ausprobiert. bei den udev-rules "null" auf 660 gesetzt und rebootet. Die Rootprozesse sind alle hochgekommen, die Userprozesse sind zT überhaupt nicht gestartet worden.
atd wird ja auch nicht als root gestartet und war wie bei dir auch nicht da. Nach Fehlern habe ich jetzt nicht weiter geschaut, aber die waren sicherlich auch da und ähnlich wie bei dir. Insoweit ist dein Fehler jetzt auch nachvollziehbar.

robi

oelk · 1 Aug. 2009

Hi,

wir sind dem Ding ein Stück näher.

Nach einigem Forschen kam ich auch darauf, das das mit udev zu tun haben muss,
wer generiert die Devices mit welchen Rechten.
In /etc/udev/rules.d/50-udev-default.rules stand nur eine Zeile, hm, ein bisschen wenig.
Auch die Anzahl der datein in diesem Verzeichnis war mit 13 etwas wenig.

Mit locate fand ich schnell /lib/udev/rules.d und hier war die 50-udev-default.rules
wesentlich umfangreicher.
Also zunächst ein

Code:

cat /lib/udev/rules.d/50-udev-default.rules >> /etc/udev/rules.d/50-udev-default.rules

und nach dem nächsten reboot war das Problem mit atd gelöst.

Die Frage ist nun, was ist mit den anderen Dateien in /lib/udev/rules.d/ ?
Auch mal nach /etc/udev/rules.d/ kopieren ?
Wenn's schief geht macht es nix, dafür läuft das ja in einer VM.

MfG

Anonymous · 2 Aug. 2009

oelk schrieb:
Die Frage ist nun, was ist mit den anderen Dateien in /lib/udev/rules.d/ ?
Auch mal nach /etc/udev/rules.d/ kopieren ?
Wenn's schief geht macht es nix, dafür läuft das ja in einer VM.

Besser ist es mit dem Paketmanager das Paket noch mal zu aktualisieren. War das eine fertige VM oder hast du die selbst installiert? Wenn es eine gehärtete fertige konfigurierte VM war, dann ist es möglich, das dort einiges nicht mehr ganz dem entspricht was in den orginal Paketen enthalten ist.

robi

oelk · 2 Aug. 2009

Moin,

nein, das war eine von mir installierte VM.
An das aktualisieren bzw neu installieren dachte ich auch schon,
aber das brachte nichts, der Zustand war derselbe.
Daher die dauernenden Neuinstallationen um heraus zu finden,
ob das jetzt ein Installationsfehler von mir ist oder ein Bock in der Installation
allgemein.

Ich würde eher sagen letzteres.
Ich habe jetzt so einige Installationsvarianten durch, minimal mit KDE, mit GNOME,
aber das Ergebnis ist immer dasselbe.

Hier sieht man auch, wo das wahrscheinlich herkommt:
http://www.novell.com/products/lin...oducts/linuxpackages/server11/ia64/udev.html

Ich will ja meine Installation scripten und werde zumindest das mal einbauen:

Code:

cat /lib/udev/rules.d/50-udev-default.rules >> /etc/udev/rules.d/50-udev-default.rules

Denn Rest der Dateien auch d areinkopieren halte ich für gewagt, wenn man
nicht absehen, was das für Folgen hat.

Dann lässt sich plötzlich auch die oracle-xe installieren.

Ich bedanke mich erstmal an dieser Stelle ganz dolle.

MfG

josef-wien · 2 Aug. 2009

oelk schrieb:
Ich will ja meine Installation scripten und werde zumindest das mal einbauen

Diese Lösung hat den Nachteil, daß Du Änderungen der Datei durch ein geändertes Paket "udev" nicht mitbekommst. Du solltest Dich auf die Suche machen, wo bei Dir die Datei "/etc/udev/rules.d/50-udev-default.rules" herkommt. Von der reinen Lehre her darf es sie nur geben, wenn bewußt die Datei "/lib/udev/rules.d/50-udev-default.rules" außer Kraft gesetzt werden soll (siehe auch die "manpage" von "udev"). Mit http://packages.opensuse-community.org/ finde ich lediglich das Paket "intel-iamt", das eine solche (einschließlich Leerzeilen aus 164 Zeilen bestehende) Datei enthält.

[gelöst] openSUSE 11.1 atd startet nicht

Member

Ultimate Guru

Member

Ultimate Guru

Member

Anonymous

Gast

Member

Anonymous

Gast

Ultimate Guru

Member

Member

Member

Anonymous

Gast

Member

Member

Anonymous

Gast

Member

Anonymous

Gast

Member

Ultimate Guru