[linux-l] "device is busy" im Single-User-Mode (was: tune2fs / fsck @ Ubuntu 6.06)

[Mike Dornberger]

Hallo Volker,

On Tue, Oct 03, 2006 at 08:21:27PM +0200, Volker Grabsch wrote:
> On Tue, Oct 03, 2006 at 05:01:38PM +0200, Mike Dornberger wrote:
> > On Mon, Oct 02, 2006 at 09:46:33AM +0200, Steffen Dettmer wrote:
> > > * Norman Steinbach wrote on Mon, Oct 02, 2006 at 00:25 +0200:
> > > > >    Hast du z.B. /home oder /usr als extra Partition die du checken
> > > > >    willst, dann einfach unmounten und fsck drüberjagen.
> > > > habe ich - aber umount geht nicht, er sagt mir: device is busy (ist
> > > > /als usr eingehängt)
> > > 
> > > init S (oder init 1) vergessen?
> > 
> > root wird wohl bash als Shell haben. Die hat viele libs in /usr/lib
> > geöffnet. lsof | grep "^/usr" kann helfen. Mal 'ne andere Shell
> > exec'uten (vorher natürlich installieren). dash, ash, posh, sash,
> > busybox vielleicht?
> 
> Bitte nicht unnötig die Leute verwirren. Norman hat einfach nur voreilig
> kein "init 1" gemacht.

das war aber nicht ersichtlich. Stefan formulierte es ja auch als Frage und
ich ging einfach mal von "Nein" als Antwort aus. Ich traue den Lesern auf
(technischen) Mailinglisten zu, das sie dies erkennen und ggf. meine Antwort
ignorieren, wenn meine (nicht formulierten) Voraussetzungen nicht zutreffen.
Außerdem solltest Du auch bedenken, daß es ein Mailinglisten- Archiv gibt
und so meine Antwort auch als Anregung für andere dienen könnte, die dieses
Problem vielleicht auch gerade haben.

> Obiger Absatz ist in vielerlei Hinsich falsch.

Nun, genau genommen war er "nur" etwas ungenau formuliert. Vielleicht sollte
ich so spät auch keine E-Mails mehr schreiben.

Falsch war, daß die Pfadnamen zu den offenen Dateien nicht am Zeilenanfang,
sondern am Zeilenende der Ausgabe von lsof stehen, es hätte also `grep
"/usr"' (ohne das ^ vor /usr) heißen müssen. Da hab ich mich wohl durch die
Ausgabe auf einem 80 Spalten breiten Terminal täuschen lassen.

Auch nicht richtig war, daß die Bash _viele_ Bibliotheken im Sinne von ELF
shared objects unterhalb von /usr offen hat. Wohl aber hat sie bei mir hier
gerade (Runlevel 2) folgende Dateien unter /usr offen, nämlich
/usr/lib/gconv/ISO8859-15.so (tatsächlich eine ELF-Bibliothek) und
/usr/lib/locale/locale-archive. Im gewissen Sinne kann man letztgenannte
Datei wohl aber auch als Bibliothek betrachten. :^)

Ich habe den Tip mit lsof aus dem Kopf geschrieben, da ich vor vielen
Monaten (Jahren?) auch vor dem Problem stand, trotz Runlevel 1 /usr nicht
umount'en zu können. Und in meiner Erinnerung war die Bash schuld, weil sie
einiges unterhalb von /usr offen hatte, ich glaube mich zu erinnern, mehr
als diese zwei Dateien. Gelöst hatte ich das damals dann wirklich, indem ich
eine Shell exec'utete, die wirklich dafür "gebaut" war, im Single-User-Mode
zum Einsatz zu kommen.

Gut, das Problem mit dem fehlerhaften regulären Ausdruck hätte ich durch
normales Überprüfen herausfinden können. Ich weiß nicht, warum ich es hier
nicht getan hatte, wie ich das sonst normalerweise tue. Vielleicht war ich
wohl wirklich schon zu müde oder ich hatte mir gedacht, daß ich jetzt nicht
extra meinen Rechner nur wegen eines Tips, den ich an eine Mailingliste
gebe, in Runlevel 1 versetze - und dabei vergessen, daß lsof und grep auch
in anderen Runleveln funktionieren. ;-)

> Es ist gerade Sinn und Zweck der Programme in /bin, möglichst wenig
> Abhängigkeiten zu haben, unbesondere keine nach /usr.

Das kann ich so weder aus [1] noch aus [2] lesen. Auf den Seiten der
[3]OpenGroup.org habe ich dazu nichts gefunden. Aus [1, 2] lese ich
lediglich, daß die Programme dort auch ohne eingehängtes /usr laufen müssen.
Eine zulässige Interpretation ist dann wohl, daß Dateien unter /usr benutzt
werden können, wenn sie vorhanden sind, es aber keinen (I/O-)Fehler geben
darf, wenn sie nicht da sind.

  [1] http://de.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#.2Fbin_:_grundlegende_Systembefehle_.28f.C3.BCr_alle_Benutzer.29
  [2] http://www.pathname.com/fhs/pub/fhs-2.3.html#BINESSENTIALUSERCOMMANDBIN
  [3] http://www.opengroup.org/

Ein `ll `which bash`' sagt mir, daß das Binary wirklich unter /bin/bash zu
finden ist. Hm, wäre interessant zu probieren, was eigentlich passiert, wenn
man die Bash starten will, ohne das /usr eingehängt ist. Aber mangels
Testrechner kann ich das jetzt nicht machen.

> Die bash gehört auch dazu, wie jede andere Shell. Bibliotheken-
> Abhängigkeiten ermittelt man besser nicht via "lsof". "ldd" erfüllt
> direkt diesen Zweck:
[...]
> Bash hängt also nur von einigen Bibliotheken in /lib ab.

Nunja, wie Du oben gesehen hast, ist das aber wohl nicht ausreichend. `ldd'
sagt Dir im wesentlichen nur, welchen Shared Libraries der Loader ld.so oder
ld-linux.so laden soll, bevor er das Programm startet (soweit ich das
verstanden habe). Aber nichts hält ein Programm davon ab, beliebige Dateien
zu öffnen, wenn es erstmal läuft - auch andere Dateien mit Codeteilen, eben
um diese auch zur Ausführung zu bringen. Das Plugin-Konzept von einigen
Programmen fällt mir hierzu ein. Mplayer benutzt beispielsweise Windows-
Codecs zum Abspielen einiger Formate oder libdvdcss, wenn sie vorhanden
sind, funktioniert aber auch ohne diese.

> Unnötig komplizierte Theorien, die darüberhinaus auch noch falsch
> sind, genauso wie unverifiziertes Halbweissen, sind wirklich das
> Letzte, was man einem Linux-Anfänger antun sollte. Kein Wunder,
> dass die meisten das für viel zu umständlich und zu kompliziert
> halten, wenn *solche* Hilfe bekommen.

Ich weiß nicht, was Dich den Tag dazu geleitet hat, so etwas zu schreiben.
Ehrlich gesagt, habe ich mich sehr über diesen Absatz geärgert, was auch ein
wesentlicher Grund ist, daß ich jetzt erst auf Deinen Beitrag antworte
(=postponed und Zeitmangel sind andere).

Ich glaube, gezeigt zu haben, daß meine "Theorie" weder unnötig noch falsch
ist (bis auf das ^ wohl). Auch denke ich nicht, daß es wesentlich
komplizierter als ein `ldd' ist. Im übrigen hätten ja auch andere Prozesse
noch schuld sein können (= haben Dateien unter /usr offen), die durch den
Runlevelwechsel nicht beendet worden waren. Ob dies Norman dann anhand der
Ausgabe von lsof bemerkt hätte, weiß ich nicht. Gut, das hätte ich explizit
hinschreiben könne, aber ich wollte auch mal keine überlange E-Mail
schreiben (zu der diese ja nun auch schon wieder ausartet). ;^)

Ich weiß wirklich nicht, was Dich veranlaßt hat, mir unverifiziertes
Halbwissen vorzuwerfen. Ich kann mich nicht erinnern, hier oder anderswo
"dummes Zeug" geschrieben zu haben, sodaß Du Dir dieses Urteil über mich
bilden konntest. Sollte das doch so sein, bin ich über konstruktive Kritik
natürlich sehr dankbar, denn schließlich sehe ich den Sinn von Mailinglisten
wie diesen darin, etwas zu lernen.

Auch sind wir meiner Meinung nach schon längst an einem Punkt gewesen, der
für viele User "umständlich" und "kompliziert" ist. Zu allererst:
Partitionierung der Festplatte, um ein separates /usr u. a. zu haben. Um mit
einem Linux herumzuspielen oder (Büro-)Arbeit zu erledigen ist das nicht
zwingend notwendig. Damit sie den Sinn davon versteht, müssen sie sich
wenigstens ein paar Stunden damit beschäftigen, sprich einiges lesen (oder
es sich erklären lassen). Gerade auch, um die Probleme, die damit evt.
verknüpft sein können (z. B. /usr zu klein dimensioniert), zu verstehen.
Außerdem hat sich dieser Thread ja nun auch damit befaßt, wie, warum und
womit man ein bestimmtes fs (auch den Begriff und den Sinn hinter der
Existenz verschiedener müssen die User ersteinmal verstehen) dahingehend
modifiziert, daß es nicht bei jedem x-ten Booten überprüft wird und wie man
das dann manuell auslösen kann. Und auch dies nicht auf dem Niveau "gehe ins
K-Menü, Einstellungen... und klicke da den Haken bei xyz ab und ignoriere
die große, rote Warnung" sondern mit Kommandozeilen-Werkzeugen, die root
verwenden muß, damit da überhaupt was funktioniert.

Zum anderen auch, die Sache mit den Runleveln. "Was ist das, wozu braucht
man das?" Sieht das nicht auf den ersten Blick umständlich und kompliziert
aus? Auch hier gibt es wieder viel zu lernen. Oder mit ldd in den
Eingeweiden von Programmen und ihrem Zusammenspiel mit dem System
herumschnüffeln...

Im übrigen kann ich mich nicht erinnern, gelesen zu haben, daß man mit einer
Live-CD auch die fs überprüfen kann, was wohl wesentlich einfacher geht, als
sich mit Runleveln und beschäftigten Dateisystemen zu befassen.

Nungut, vielleicht wollte ja Norman so eine große, rote Box mit einem
OK-Knopf, damit man sie schnell wegklicken kann, aber es gibt sie meines
Wissens nach nicht, also kann man nur "laß es lieber so wie es ist" als
Antwort geben oder eben halt, wie es "kompliziert" geht. Aber diese
Nichtexistenz kannst Du anderen _Usern_ nicht vorhalten.

Gruß,
 Mike