[Gentoo] Root filesystem kan niet unmounten bij shutdown

[_eXistenZ_]

Ik draai op een servertje met 4 schijven deze schijfconfiguratie:

/dev/md1: /dev/sda1, /dev/sdb1, /dev/sdc1, /dev/sdd1 4x32MB in raid1 Ext3, /boot
/dev/sda2 512MB swap	/dev/sdb2 512MB swap	/dev/sdc2 512MB swap	/dev/sdd2 512MB swap
/dev/md2: /dev/sda3, /dev/sdb3, /dev/sdc3, /dev/sdd3 4x5GiB in raid5 ReiserFS, /
/dev/md3: /dev/sda4, /dev/sdb4, /dev/sdc4, /dev/sdd4 4xde rest (450GiB oid) in raid5 ReiserFS, /data

Bij het afsluiten krijg ik deze melding:

mdadm: stopped /dev/md1
mdadm: stopped /dev/md3
mdadm: fail to stop array; device or resource busy (/dev/md2)

Waardoor tijdens het opstarten mijn journalreplay aanschiet.
Mijn rootpartitie kan dus bij het slapen gaan niet unmounted worden.

Dit is mijn /etc/fstab:

code:

# <fs>                  <mountpoint>    <type>          <opts>                  <dump/pass>
/dev/md1                /boot           ext3            noatime                 0       2
/dev/md2                /               reiserfs        notail                  0       1
/dev/md3                /data           reiserfs        noatime                 0       2
/dev/sda2               none            swap            sw,pri=1                0       0
/dev/sdb2               none            swap            sw,pri=1                0       0
/dev/sdc2               none            swap            sw,pri=1                0       0
/dev/sdd2               none            swap            sw,pri=1                0       0

# glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for
# POSIX shared memory (shm_open, shm_unlink).
# (tmpfs is a dynamically expandable/shrinkable ramdisk, and will
#  use almost no memory if not populated with files)
shm                     /dev/shm        tmpfs           nodev,nosuid,noexec     0       0

Dit gedrag is natuurlijk niet de bedoeling. Wie weet waar dit aan kan liggen?

[daft_dutch]

vreemd
Heb ik bij debian ook wel eens. Maar dan remount die read only. waarna het ding gewoon uit gaat

[burne]

_eXistenZ_ schreef op donderdag 06 maart 2008 @ 22:55:
Wie weet waar dit aan kan liggen?

Er draait nog iets op het moment van unmounten wat files open heeft. Nou weet ik niet of gentoo systemV of bsd-style init is, dus gerichte adviezen zijn iets lastiger.

System V: ga naar /etc/rc0.d en kijk welke taak het hoogste nummer heeft. Bij mij S01Halt, maar dat kan wisselen. Ergens in het shellscript zie je umount met wat awk ofzo er omheen. In de regels ervoor knutsel je de volgende commando's:

code:

lsof > /tmp/openfiles
ps uax > /tmp/runningtasks
sync

Op een bsd-style systeem zul je iets soortgelijks moeten uitvoeren in waarschijnlijk rc.shutdown. Ook daar zoek je naar het punt waar het systeem klaar zou moeten zijn met de shutdown op het unmounten van filesystems na, en ook daar zet je precies dezelfde drie regels.

Vervolgens doe je een shutdown, en na de restart kijk je wat er nog draait en wat welke files open heeft op het moment van unmounten. Dat is je dader. Waarom 'ie nog draait wordt de volgende stap.

[_eXistenZ_]

Ik ga er vanuit dat dit systemV is, omdat ik naar even speuren in de file /etc/inittab dit tegenkom:
$Header: /var/cvsroot/gentoo-x86/sys-apps/sysvinit/files/inittab.
Echter heb ik geen /etc/rc0.d/ , maar ben nog even aan het zoeken waar ik dergelijke dingen neer kan zetten

/edit

/etc/conf.d/local.stop mocht niet, bij bleef hangen bij Stopping local... en ik moest een harde reset geven.

[ Voor 19% gewijzigd door _eXistenZ_ op 07-03-2008 17:36 ]

[laurencevde]

offtopic:
Gentoo heeft sysv een beetje verbeterd. het heeft nog wel init-scripts, maar voor de rest is het behoorlijk anders. Je init-script staan nog steeds in /etc/init.d, en die roep je nog steeds met "start" en "stop" aan, maar de runlevels vind je terug in /etc/runlevels. De init-scripts hebben zelf dependency-tracking, en hoeven dus niet in een bepaalde volgorde te staan. bij shutdown worden alle gestarte init-scripts zaken gestopt, en halt.sh gedraaid.

lsof is niet standaard geïnstalleerd op gentoo. Dat dus eerst even.
Die 2 regels van burne kan je bovenaan in /etc/init.d/halt.sh zetten.
Nu is het vziw niet eens mogelijk om / te unmounten, omdat er altijd wel iets een bestand open heeft. / hoort dan ook ro geremount te worden als vrijwel laatste stap bij het aflsuiten.

[_eXistenZ_]

Hmm et schijnt allemaal wel mee te vallen. Hij roept dattie de / niet kan unmounten, waarna ie m remount als readonly. Daarna reboot ie. Tijdens het booten gaattie /data replayen, niet /, dat is een beetje raar... Duurt ook lang. Deze wordt wel gewoon goed unmount op et end.

Dus ik heb het in het begin niet goed verteld, denk dat het allemaal nog wel meevalt

[GX]

Bij mij remount Gentoo al m'n filesystems, altijd. Er zit nooit een unmount voor m'n halt. Volgens mij heb ik ook niets gedaan om het zo ver te krijgen, dus even uitzoeken wat je zelf veranderd hebt

[burne]

_eXistenZ_ schreef op zaterdag 08 maart 2008 @ 18:07:
Tijdens het booten gaattie /data replayen, niet /, dat is een beetje raar... Duurt ook lang.

Je kunt een keer met de hand fsck.reiserfs loslaten op /data? De fsck tijdens booten is geen grondige fsck maar enkel bedoeld om het systeem in de lucht te krijgen, en fsck.reiserfs wijkt in een aantal opzichten af van de andere fsck.*. Uit de fsck manpage:

code:

       -n     For some filesystem-specific checkers, the -n option will cause the fs-specific fsck to avoid attempting
              to repair any problems, but simply report such problems to stdout.  This is however  not  true  for  all
              filesystem-specific  checkers.   In particular, fsck.reiserfs(8) will not report any corruption if given
              this option.  fsck.minix(8) does not support the -n option at all.