[CentOS]tar-process killen

[Witte]

Op een linux-server zijn een aantal tar-processen in de soep gelopen. Hierdoor loopt de nachtelijke backup niet.
Kunnen deze tar-processen gekilled worden? Met kill -9 lukt het niet.

[pistole]

zijn ze zombie geworden? (wat is de status van de processen)

Check ook eens met lsof of anderszins wat de processen aan handles open hebben staan, wellicht dat dat een indicatie kan geven wat er fout is gegaan

[Witte]

ik heb het advies gekregen om de server te herstarten, maar daar heb ik weinig trek in. Kan ik 100 gebruikers gaan vertellen dat hun erp-pakket even niet werkt.

met top zie ik dat er 1 active process, 255 sleeping en 0 zombie zijn.
lsof output van een PID:

code:

[root@CERM root]# lsof|grep 24130
tar       24130    root  cwd    DIR        8,1       4096          2 /
tar       24130    root  rtd    DIR        8,1       4096          2 /
tar       24130    root  txt    REG        8,1     149676      36844 /bin/tar
tar       24130    root  mem    REG        8,1    1568904      87760 /lib/tls/libc-2.3.2.so
tar       24130    root  mem    REG        8,1     106900      73132 /lib/ld-2.3.2.so
tar       24130    root  mem    REG        8,1      51896      73165 /lib/libnss_files-2.3.2.so
tar       24130    root    0r  FIFO        0,5               4534819 pipe
tar       24130    root    1w   REG        8,3    1403371    2900017 /usr/v5/tmp/backup2.log
tar       24130    root    2w   REG        8,3    1403371    2900017 /usr/v5/tmp/backup2.log
tar       24130    root    3w   CHR        1,3                 30855 /dev/null
tar       24130    root    4r   DIR        8,3      16384    5914723 /usr/v5/dbs/b00.dbs/brf/obv/994

kan ik hier iets mee???


Mjah, ik kan wel uiteraard even inloggen om 22:45 en rebooten, wel vervelend voor onze avondploeg.

[ Voor 87% gewijzigd door Witte op 23-04-2008 16:58 ]

[TheBorg]

Maak je een cron dat ie vannacht 10 minuten voor de backup reboot. Wel maf dat ze niet te killen zijn.

[ Voor 6% gewijzigd door TheBorg op 23-04-2008 16:49 ]

[Freezerator]

code:

ps aux | grep (naam tar process)

Wat zegt je process daar? Misschien kan je dan per id killen?

[ Voor 7% gewijzigd door Freezerator op 23-04-2008 16:59 ]

[Witte]

ik heb geprobeerd per id te killen, werkt niet, ze blijven gewoon staan.
killall -9 tar heb ik indd ook al geprobeerd, werkt niet.

[ Voor 29% gewijzigd door Witte op 23-04-2008 17:04 ]

[TheBorg]

Probeer eens:
killall -9 tar

[BitProcessor]

ps axjf

-> krijg je een volledige process-tree te zien, inclusief de parents (visueel) - misschien word je daar wat wijzer uit ?

[deadinspace]

Er zijn nou al twee mensen (pistole en Freezerator, om precies te zijn) die hebben gevraagd naar de status van de processen en/of hun ps aux output.

Doe daar eens wat mee, dan kunnen we er misschien meer over zeggen

[ Voor 0% gewijzigd door deadinspace op 23-04-2008 17:05 . Reden: Damn you G8KeePeR :P ]

[Witte]

* processen zijn sleeping
* ps aux output (stukje):

code:

[root@CERM root]# ps aux|grep tar
root     30830  0.0  0.0  1708  700 ?        D    Apr20   0:00 tar cvf /dev/null etc/hosts etc/fstab etc/exports etc/group etc/passwd etc/profile etc/term.conf etc/resolv.conf etc/printcap etc/cups etc/samba/smb.conf usr/users var/spool/cron/root var/spool/lpd usr/local/cerm/backup usr/local/cerm/mirror usr/v5/cer/prof
root      2912  0.0  0.0  1704  696 ?        D    Apr20   0:11 tar cvf /usr/cerm backup/diskbackup.tar etc/hosts etc/fstab etc/exports etc/group etc/passwd etc/profile etc/term.conf etc/resolv.conf etc/printcap etc/cups etc/samba/smb.conf usr/users var/spool/cron/root var/spool/lpd usr/local/cerm/backup usr/local/cerm/m

ps axjf laat zien dat de paretpid pid 1 is, en er zijn geen childs.

[ Voor 4% gewijzigd door Witte op 23-04-2008 17:16 ]

[deadinspace]

Ja, ze zijn in uninterruptable sleep (status D; "normale", interruptible sleep is status S).

Dat wil zeggen dat zo'n proces een systemcall (systeemroutine) heeft aangeroepen en dat die systemcall (nog) niet klaar is. Omdat een proces pas verder gaat als de aangeroepen systemcall klaar is hangt het proces, en omdat zo'n systemcall ononderbreekbaar is, reageert het proces ook niet op SIGKILL, en heet de status uninterruptible sleep.

Typische oorzaken van status D processen zijn:

• driver bugs (status D netwerktools vanwege een brakke netwerkdriver bijvoorbeeld)
• brakke of onverwacht verdwenen hardware (een harddisk die problemen heeft of er zomaar uitgetrokken wordt, verdwenen network filesystems, vroeger ook wel USB sticks)

Als ik naar je lsof output kijk, dan vermoed ik dat dat tar proces geblokkeerd is op een systemcall op filedescriptor 4 (/usr/v5/dbs/b00.dbs/brf/obv/994). Dat vermoeden is wel te bevestigen of ontkrachten door 24130 te stracen.

Kun je /usr/v5/dbs/b00.dbs/brf/obv/994 nog wel gewoon benaderen via de shell of op andere manieren? Op wat voor medium staat dat filesystem, en zou daar wat mee aan de hand kunnen zijn?

[u_nix_we_all]

Wat ik niet snap:
- Waarom heeft een hangend tar process als gevolg dat de backup niet loopt ? Zijn er files in use ?
- De command line uit de ps die je post impliceert dat je de tarfiles naar resp. /dev/null en /usr/cern schrijft, dat lijkt me niet de bedoeling ?

Maar goed, dat helpt je niet om de tar te killen, daar heb ik geen oplossing voor helaas.

[Witte]

deadinspace schreef op woensdag 23 april 2008 @ 17:29:
Ja, ze zijn in uninterruptable sleep (status D; "normale", interruptible sleep is status S).

Dat wil zeggen dat zo'n proces een systemcall (systeemroutine) heeft aangeroepen en dat die systemcall (nog) niet klaar is. Omdat een proces pas verder gaat als de aangeroepen systemcall klaar is hangt het proces, en omdat zo'n systemcall ononderbreekbaar is, reageert het proces ook niet op SIGKILL, en heet de status uninterruptible sleep.

Typische oorzaken van status D processen zijn:

• driver bugs (status D netwerktools vanwege een brakke netwerkdriver bijvoorbeeld)
• brakke of onverwacht verdwenen hardware (een harddisk die problemen heeft of er zomaar uitgetrokken wordt, verdwenen network filesystems, vroeger ook wel USB sticks)

Als ik naar je lsof output kijk, dan vermoed ik dat dat tar proces geblokkeerd is op een systemcall op filedescriptor 4 (/usr/v5/dbs/b00.dbs/brf/obv/994). Dat vermoeden is wel te bevestigen of ontkrachten door 24130 te stracen.

Kun je /usr/v5/dbs/b00.dbs/brf/obv/994 nog wel gewoon benaderen via de shell of op andere manieren? Op wat voor medium staat dat filesystem, en zou daar wat mee aan de hand kunnen zijn?

Het lijkt er inderdaad op dat ik niet in die folder kan. Als ik daar een ls doe, hangt mijn telnet-sessie!
M.a.w. het lijkt inderdaad op een corrupt filesystem. Een reboot zal me dus niet helpen.
En nu is de helpdesk van de leverancier gesloten (Belgen).

die dev/null is onderdeel van de controle van de backup.

[Zwerver]

Witte schreef op woensdag 23 april 2008 @ 17:48:
[...]


Het lijkt er inderdaad op dat ik niet in die folder kan. Als ik daar een ls doe, hangt mijn telnet-sessie!
M.a.w. het lijkt inderdaad op een corrupt filesystem. Een reboot zal me dus niet helpen.
En nu is de helpdesk van de leverancier gesloten (Belgen).

Je m.a.w. is wel heel kort door de bocht? Het kan nl ook zijn dat er een andere reden is dat je dat deel van je filesystem niet kan benaderen....

[Witte]

is waar.

maar kan een reboot + fsck -a /usr geen kwaad?

[Zwerver]

Witte schreef op woensdag 23 april 2008 @ 18:33:
is waar.

maar kan een reboot + fsck -a /usr geen kwaad?

Wat zeggen je logs? Wat zegt je dmesg bijv? Want meestal kan je met een gare FS wel wat errors verwachten? Als je /usr umount, dan kan je hem direct fsck-en << dat gaat niet lukken gok ik, omdat tar nog steeds probeert die partitie te benaderen.

[Witte]

ik heb toch maar een reboot gedaan, en een fsck. deze laatste gaf wat fouten die gefixed zijn. Nu loopt de backup weer ok.
Het baart me toch zorgen dat het fs fouten heeft. Kan dit aan mijn schijven liggen? (= mirror).
Is er een soort van event-viewer waar ik hardware-problemen kan zien?
(of is dit een te noob vraag)

edit: in dmesg staat niets vreemds, gewoon dat hij alles detecteert.

[ Voor 10% gewijzigd door Witte op 24-04-2008 09:31 ]

[Jaap-Jan]

Als er iets mis is met de schijven, zou je dat terug moeten zien in /var/log, dan krijg je dingen te zien als:

code:

kernel: hda: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
kernel: hda: drive_cmd: error=0x04 { DriveStatusError }

Volgens mij komt dat in je kernel.log te staan.