[OpenSSH] fatal: daemon() failed: Success

[geertb]

Sinds ik vanochtend mijn Slackware 8.1 heb gerebooted (tis een 486sx) krijg ik opeens tijdens het starten van sshd (tijdens booten maar ook als ik 'm zelf start) de volgende error in mn /var/log/syslog :

fatal: daemon() failed: Success

Ik heb OpenSSH al hercompiled [nieuwste versie] en ik blijf het zelfde probleem houden... What to do? Ik baal er bestwel van want ik gebruik dat ding alleen als router en nog wat zooi, maar altijd remote...

sshd -D werkt wel, dus het blijkt dat als 'ie 'm wil daemonen dat dat mis gaat

[deadinspace]

Wat is de output van

code:

ls -l /dev/null

?

[geertb]

deadinspace schreef op 13 September 2003 @ 01:27:
Wat is de output van

code:

ls -l /dev/null

?

code:

-rw-r--r--    1 root     root            0 Sep 13 11:17 /dev/null

[Straphka]

@Deadinspace:
huh? Wat had je dan verwacht?


on-topic

Zijn er dingen die niet werken? Je zegt dat je SSH al opnieuw gecompileerd heb, maar je zegt erniet bij waarom je denkt dat het hieraan zou liggen

[geertb]

Straphka schreef op 13 September 2003 @ 14:19:
Zijn er dingen die niet werken? Je zegt dat je SSH al opnieuw gecompileerd heb, maar je zegt erniet bij waarom je denkt dat het hieraan zou liggen

Nope, dit was een tip van een kennis van me, die dacht dat het welweer zou werken na een recompile... Alles deed/doet het, behalve als daemon draaien...

[moto-moi]

Straphka schreef op 13 September 2003 @ 14:19:
@Deadinspace:
huh? Wat had je dan verwacht?

code:

hylke@kahlan:~$ ls -l /dev/null
crw-rw-rw-    1 root     root       1,   3 Jan  1  1970 /dev/null

Denk ik

En zo te zien klopt dat bij deze user niet. Al weet ik niet zeker hoe deze output eruit hoort te zien bij een niet devfsd systeem, dus ik wacht rustig op de reply van doodinderuimte

[Mark]

Op mijn Slackware 8.1 systeem:

code:

mark@sigma:~$ ls -l /dev/null
crw-rw-rw-    1 root     sys        1,   3 Jul 18  1994 /dev/null

Bekijk het verschil eens...

[geertb]

Mark schreef op 13 september 2003 @ 15:57:
Op mijn Slackware 8.1 systeem:

code:

mark@sigma:~$ ls -l /dev/null
crw-rw-rw-    1 root     sys        1,   3 Jul 18  1994 /dev/null

Bekijk het verschil eens...

I see the difference, maar hoe los ik et op?

Edit:

code:

root@luna:~# ls -l /dev/null
-rw-r--r--    1 root     root            0 Sep 13 18:35 /dev/null
root@luna:~#

Het blijkt ook dat elke keer als ik em ls -l doe dattie em overnieuw aangemaakt, gezien de datum & tijd..

[ Voor 29% gewijzigd door geertb op 13-09-2003 18:36 . Reden: ls -l bijgevoegd ]

[Verwijderd]

Niet perse. Als je devfs gebruikt kan het zijn dat ie de huidige tijd gebruikt als "creation time" voor die files iedere keer dat je ze stat(). Heb je al "chmod go+w /dev/null" geprobeerd?

[ Voor 4% gewijzigd door Verwijderd op 13-09-2003 22:24 ]

[deadinspace]

geertb schreef op 13 september 2003 @ 11:17:

code:

-rw-r--r--    1 root     root            0 Sep 13 11:17 /dev/null

That's your problem. Het is een gewone file, terwijl het een character device moet zijn (let op het eerste teken, dat is een -, terwijl het bij andere mensen een c is). Bovendien moet hij world-writable zijn, en de jouwe is alleen writable voor root.

moto-moi schreef op 13 september 2003 @ 14:59:
Al weet ik niet zeker hoe deze output eruit hoort te zien bij een niet devfsd systeem, dus ik wacht rustig op de reply van doodinderuimte

Devices zien er in een klassieke /dev directory hetzelfde uit als in devfs, afgezien misschien van de datum (die er niet zo toedoet)

geertb schreef op 13 september 2003 @ 18:34:
I see the difference, maar hoe los ik et op?

man rm, man mknod en man chmod

De major device nr moet 1 zijn, en de minor device nr moet 3 zijn, dat wil ik je wel zo geven (het is trouwens ook in de output van ls -l in de posts van andere mensen te zien).

Ik vind het overigens een interessantere vraag hoe je /dev/null zo komt... Harde resets / stroomuitvallen / etc gehad de laatste tijd?

[geertb]

Bedankt voor alle tips, het is gelukt met een mknod

Hoe het komt is idd een hele grote vraag, dat ding draaide 30 dagen, rond de 30 dagen gaat de load altijd wat omhoog en dus meer ratelgedrag en daarom reboot ik 'm meestal.
Tis een 486 die in de woonkamer onder de tv staat, dus het is niet fijn om 'm te horen ratelen [tenminste ouders vinden van niet ;)] .

[ Voor 3% gewijzigd door geertb op 13-09-2003 23:35 ]

[Verwijderd]

Er zijn een aantal onverlaten die denken dat

code:

mv <file> /dev/null

een andere manier is om een bestand te wissen. Ik heb gemerkt dat dat de meest gemaakte fout is.

[Confusion]

Verwijderd schreef op 14 September 2003 @ 10:20:
Er zijn een aantal onverlaten die denken dat

code:

mv <file> /dev/null

een andere manier is om een bestand te wissen. Ik heb gemerkt dat dat de meest gemaakte fout is.

Tjah, of je tikt wat fout als je errors naar /dev/null wilt sturen waardoor iets soortgelijks gebeurt. * Confusion spreekt uit ervaring. Daarna gaat booten ook niet zo lekker meer .

[geertb]

Verwijderd schreef op 14 September 2003 @ 10:20:
Er zijn een aantal onverlaten die denken dat

code:

mv <file> /dev/null

een andere manier is om een bestand te wissen. Ik heb gemerkt dat dat de meest gemaakte fout is.

Dat is niet mijn fout geweest, maybe 1 van mijn users, maar ik zelf niet

[deadinspace]

geertb schreef op 14 September 2003 @ 12:30:
Dat is niet mijn fout geweest, maybe 1 van mijn users, maar ik zelf niet

Users kunnen dat sowieso niet, omdat ze /dev/null niet kunnen verwijderen of overschrijven (tenzij ze schrijf-rechten in /dev hebben, wat tamelijk ongezond zou zijn).

Overigens is dit mv file /dev/null truukje een beetje OS-afhankelijk; op sommige andere (oudere) Unices werkte dit wel, vandaar het bestaan van deze verwarring