'/bin/* no such file or directory' Alles weg?

[paapje]

Ik heb vandaag een heel raar probleem ontdekt op 1 van onze servers (linux).
ik probeerde in te loggen via ssh maar dit lukte niet.

ik ben nu ingelod via een remote kvm switch, en kan wel commando's intypen op de machine.
maar bij alles geeft hij deze error. 'No such file or directory'..

er werkt bijna geen 1 commando meer, ik kan kan wel een change directory doen, en hiermee zag ik dat de commando's dus nog wel aanwezig zijn in /bin/bash, maar ik kan ze gewoon echt niet meer uitvoeren.

iemand enig idee wat ik hiermee moet beginnen?

[Rainmaker]

Ik snap em niet? Je kunt wel cd'en en je ziet dat alles in /bin er nog staat maar je kunt het niet uitvoeren?

Werkt ls -l nog? Kijk eens naar de rechten op de /bin directory. Zou ook kunnen dat de nsswitch.conf vernaggeld is door bijvoorbeeld filesystem corruptie.

Je zou kunnen beginnen met de machine in single user mode te booten en een fsck te doen. Als je dit nog uit kan voeren in ieder geval.

Mocht je hardwarematige RAID hebben, zet dan eerst 1 schijf uit de array, zodat je altijd nog een "backup" hebt.

[icyx]

Werkt echo nog wel? Omdat je bijna geen commando meer kan doen. Als het werkt:

code:

echo $PATH

Verder kan je ook nog

code:

PATH=/usr/local/bin:/usr/bin

doen, en kijken of je dan je commands tot je beschikking hebt.

[paapje]

ls werkt helaas ook niet meer, en de rechten kan ik dus momenteel ook niet meer checken.
het leuke van het verhaal is dat het een live db server is en ik hem nu niet even kan rebooten. (mysql e.d. draaien nog wel gewoon)..

Rainmaker schreef op maandag 27 oktober 2008 @ 12:55:
Ik snap em niet? Je kunt wel cd'en en je ziet dat alles in /bin er nog staat maar je kunt het niet uitvoeren?

Werkt ls -l nog? Kijk eens naar de rechten op de /bin directory. Zou ook kunnen dat de nsswitch.conf vernaggeld is door bijvoorbeeld filesystem corruptie.

Je zou kunnen beginnen met de machine in single user mode te booten en een fsck te doen. Als je dit nog uit kan voeren in ieder geval.

Mocht je hardwarematige RAID hebben, zet dan eerst 1 schijf uit de array, zodat je altijd nog een "backup" hebt.

[paapje]

echo werkt nog wel gewoon, de $PATH is ook gewoon nog wel gevuld.
ik kan het commando ook niet uitvoeren als ik in de desbetreffende directory ga staan.

dus cd /bin/bash, ./ls werkt ook niet helaas...

icyx schreef op maandag 27 oktober 2008 @ 12:57:
Werkt echo nog wel? Omdat je bijna geen commando meer kan doen. Als het werkt:

code:

echo $PATH

Verder kan je ook nog

code:

PATH=/usr/local/bin:/usr/bin

doen, en kijken of je dan je commands tot je beschikking hebt.

[gertvdijk]

paapje schreef op maandag 27 oktober 2008 @ 13:00:
het leuke van het verhaal is dat het een live db server is en ik hem nu niet even kan rebooten. (mysql e.d. draaien nog wel gewoon)..

Dat zou ik niet doen. Dan komt ie helemaal niet meer up vrees ik.
Als om een vage reden (de inhoud van) /bin weg is dan kan je dat nog wel herstellen met een bootable CD erin ofzo. Maar als je nu reboot moet je naar het datacenter.

[paapje]

Ja dat is ook een van mijn grootste 'problemen', hij draait nu nog als normaal. maar ik weet niet voor hoe lang.. en weet zeker niet wat er gebeurd als deze machine een reboot krijgt.

het lullige is, dat als ik in history kijk er wel een rm -r * commando staat en deze is niet door mij uitgevoerd (er kunnen ook nog wel andere mensen bij deze machine).. maar ik weet dus niet of dit er iets mee te maken heeft. de bestanden lijken nog wel gewoon aanwezig in de directory namelijk

gertvdijk schreef op maandag 27 oktober 2008 @ 13:05:
[...]

Dat zou ik niet doen. Dan komt ie helemaal niet meer up vrees ik.
Als om een vage reden (de inhoud van) /bin weg is dan kan je dat nog wel herstellen met een bootable CD erin ofzo. Maar als je nu reboot moet je naar het datacenter.

[gertvdijk]

paapje schreef op maandag 27 oktober 2008 @ 13:07:
het lullige is, dat als ik in history kijk er wel een rm -r * commando staat en deze is niet door mij uitgevoerd (er kunnen ook nog wel andere mensen bij deze machine)..

Hoe kan je nog in de history kijken dan? ik neem aan dat commando's als cat, less, more, etc. het ook niet meer doen?
En als je dat wel kan, dan zou ik even kijken in /var/log/auth.log wie daar voor het laatst op heeft ingelogd. (Of heb je gelijk root access? dat zou wel stom zijn.)

[paapje]

Het commando History doet het nog wel als een van de weinige, en ik kan niet in de log boeken kijken want de programmaatjes hiervoor werken ook niet meer..

gertvdijk schreef op maandag 27 oktober 2008 @ 13:11:
[...]

Hoe kan je nog in de history kijken dan? ik neem aan dat commando's als cat, less, more, etc. het ook niet meer doen?
En als je dat wel kan, dan zou ik even kijken in /var/log/auth.log wie daar voor het laatst op heeft ingelogd. (Of heb je gelijk root access? dat zou wel stom zijn.)

[gertvdijk]

Ik zou zeggen ga eerst redden wat er nog te redden valt. Van alle services die nog draaien de data backuppen (mysqldump bijvoorbeeld), je andere backups tevoorschijn toveren en je server opzoeken voor een grondige recovery als ie niet up wil na een reboot.

[ Voor 8% gewijzigd door gertvdijk op 27-10-2008 13:23 ]

[sparks]

Zou de backup maar opzoeken en gaan restoren op een andere server.

Mijn inschatting: einde oefening.

[paapje]

Dat zou ik al te graag doen, maar het commando mysqldump of mysqlhotcopy werken ook allemaal niet meer..

gertvdijk schreef op maandag 27 oktober 2008 @ 13:23:
Ik zou zeggen ga eerst redden wat er nog te redden valt. Van alle services die nog draaien de data backuppen (mysqldump bijvoorbeeld), je andere backups tevoorschijn toveren en je server opzoeken voor een grondige recovery als ie niet up wil na een reboot.

[gertvdijk]

paapje schreef op maandag 27 oktober 2008 @ 13:30:
Dat zou ik al te graag doen, maar het commando mysqldump of mysqlhotcopy werken ook allemaal niet meer..

Als je de boel weer snel up wil hebben: wat sparks zegt.
Als je zin hebt om echt alles te recoveren: server onderzoeken met bootable CD, chrooten en alle binaries opnieuw installeren.

[ Voor 26% gewijzigd door gertvdijk op 27-10-2008 13:46 ]

[paapje]

Bedankt voor al jullie reacties,
ik ga me voorbereiden om alles te verhuizen!

[CyBeR]

Voor de volledigheid: sommige commando's werken nog omdat dat bash built-ins zijn. Die worden dus door je shell geinterpreteerd.

echo *, een combinatie van een bash built-in en een shell glob, is een vervanging voor 'ls' als 't echt moet. (Als 't resultaat '*' is, is je dir leeg.) Een simpele vervanging voor 'cat': (while read i; do echo $i; done) < [file hier]

[ Voor 20% gewijzigd door CyBeR op 27-10-2008 13:55 ]

[Spider.007]

Het is wel raar dat alleen /bin/bash nog wel zou bestaan; maar als je de server wilt redden moet je via scp; of creatieve 'read' oplossingen busybox op de server krijgen; dan kun je weer wat meer. Je moet de server nog wel kunnen redden namelijk; maar dat gaat wel flink wat tijd kosten

Als ik jou was zou ik hem afsluiten; en een nieuwe installatie doen met behoud van bestaande data. Als je dan je daemons weer start zouden ze de bestaande data weer kunnen gebruiken

[remmelt]

Is de partitie vol? Dat wil nog wel eens interessante meldingen geven.

[paapje]

Maar betekend dat dan dat bash nog wel goed functioneerd, en dat alleen alle 'losse' commandos niet meer goed werken?

CyBeR schreef op maandag 27 oktober 2008 @ 13:50:
Voor de volledigheid: sommige commando's werken nog omdat dat bash built-ins zijn. Die worden dus door je shell geinterpreteerd.

echo *, een combinatie van een bash built-in en een shell glob, is een vervanging voor 'ls' als 't echt moet. (Als 't resultaat '*' is, is je dir leeg.) Een simpele vervanging voor 'cat': (while read i; do echo $i; done) < [file hier]

[CyBeR]

paapje schreef op maandag 27 oktober 2008 @ 14:35:
Maar betekend dat dan dat bash nog wel goed functioneerd, en dat alleen alle 'losse' commandos niet meer goed werken?


[...]

Tot zover wel. Maar check even op die manier of er echt nog files in /bin e.d. staan of dat je dat alleen maar denkt en wat er in je logs staat.

[sparks]

dat bash nog werkt is een unix/linux feature, ondanks dat je nog wat open hebt kun je files verwijderen. Het is niet zoals op windows dat je files niet kunt verwijderen als iemand het nog open heeft.
sluit je de zaak af dan heb je helemaal niets meer. niet dat je hier nog veel aan hebt.

[gertvdijk]

sparks schreef op dinsdag 28 oktober 2008 @ 16:20:
dat bash nog werkt is een unix/linux feature, ondanks dat je nog wat open hebt kun je files verwijderen.

Dat is omdat het nog in het geheugen is geladen. Zodra je het proces afsluit of killt is het foetsie. Daarom kan je ook gewoon patchen en upgraden terwijl alles nog draait en kan je het op een rustig moment restarten of gaat dit vanzelf wanneer iemand een nieuw proces ervan start.
Alleen voor dingen als de kernel moet je (voorlopig nog, tot ksplice goed werkt) nog herstarten.

[Kees]

mysqldump zou ik ook van een andere machine gaan draaien, niet vanaf de lokale machine, die kun je niet meer vertrouwens. Verder zullen alle open files nog wel open zijn, maar zijn weg zodra je het afsluit. Een reboot gaat met 99% zekerheid niet werken (afgezien dat de halt executable waarschijnlijk mist )

Dat bash nog werkt kan zijn omdat je nog ingelogt was via de kvm, dat ssh niet werkt is omdat ssh wel draait, maar niet de executable 'bash' meer kan vinden. Je kunt dus alleen interne bash commando's gebruiken zoals CyBeR al aangaf.

Wat je het beste kan doen is de mysql server backuppen, kijken wat er nog meer te redden valt (if any) en een rondvraag bij je collega's doen, en proberen te ahterhalen hoe dit heeft kunnen gebeuren. Eventueel, als het diskproblemen zijn, kun je geluk hebben en kan het na een reboot opgelost zijn, maar die kans is minimaal.

[pedorus]

Tsja, had je nou maar sash als shell. Misschien staan de permissies in /bin niet goed, is alles daar weg, etc. Misschien dat er wat commando's in andere directories het nog doen, waar je iets mee kan. En je hebt de builtins nog, maar daar zul je ook niet veel mee kunnen. Maar allereerst maar eens een backup maken, als je dat nog niet hebt gedaan... En geen processen afsluiten.

[sam.vimes]

paapje schreef op maandag 27 oktober 2008 @ 14:35:
Maar betekend dat dan dat bash nog wel goed functioneerd, en dat alleen alle 'losse' commandos niet meer goed werken?

Omdat bash in de directory /bin staat en het overgrote deel van alle andere commando's in /usr/bin.

Controleer eerst of /usr/bin echt leeg is met

echo /usr/bin/*

Als je hier de namen van allerlei commando's ziet, kun je ze aanroepen door de directorynaam ervoor te typen, dus /usr/bin/ls, /usr/bin/cat.

Als je hier alleen een * ziet, is de directory echt leeg en heb je echt een probleem. Dan denk ik dat je het best een herinstallatie van je OS kunt uitvoeren (de meeste backups maken alleen kopieën van variabele directory's zoals /home).

[DiedX]

Dat is gewoon zwaaaaar ***. Heb je nog wel een /var directory? En dan met name /var/lib/mysql (of in mijn geval /var/db?)