process kilövése - miért nem lehet root-ként?

Linux-kezdő

Az átlag user által kiadott:

dd if=/dev/zero of=nagyfile.valami bs=1024 count=1 seek=1024MB

-el induló folyamatot miért nem lehet kilőni root-ként, "kill -9 PID"-el??

9.04..

vagy csak nálam nem lehet kilőni? vagy csak órákat kéne várni mire leállítaná?

  • 2324 megtekintés

( uid_2716 | 2009. 11. 01., v – 19:02 )

Ha top-pal megnézed, milyen állapotban van a processz? D-ben (uninterruptible sleep) vagy R-ben? A %wa magas vagy valamelyik másik? Milyen file-rendszer milyen blokk device-on?

( uid_16591 | 2009. 11. 01., v – 19:09 )

nehogy mar kill -kill se lojje ki

[insert line here]
B.C. 3500 - DIY Vehicle / A.D. 30 - DIY Religion / A.D. 1991 - DIY OS

toma@ubx3:~$ dd if=/dev/zero of=nagyfile.valami bs=1024 count=1 seek=1024MB
1+0 beolvasott rekord
1+0 kiírt rekord
1024 bájt (1,0 kB) másolva, 0,000140767 mp, 7,3 MB/mp
toma@ubx3:~$ ls
összesen 1
-rw-r--r-- 1 toma toma 1048576001024 2009-11-04 19:33 nagyfile.valami

Én kipróbáltam, de a gép gyorsabb, esélyem sincs kilőni.
WTF?

konkrétan már néha lefagy a gép..poén kipróbálni a parancsot :D

dm_crypt-es lvm-ben van a full hdd, a /boot-ot kivéve

biztos ki lehetne lőni, csak hát gondolom 15 óra, mire eljut az agyáig, hogy ájjá' le mr. process

gbor@gbor:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 9.04
Release: 9.04
Codename: jaunty
gbor@gbor:~$ date
2009. nov. 4., szerda, 19.56.32 CET
gbor@gbor:~$ dd if=/dev/zero of=nagyfile.valami bs=1024 count=1 seek=1024MB
^C^C^C

^C^C^C^C^C^C^C^C^C

^C^C^C^C^C^C

^C^C^C
^C

^C^C

( gd | 2009. 11. 04., sze – 20:11 )

Milyen fájlrendszerre írsz? (Nem NFS véletlenül?)

Nálam ez a parancs eleve kb. ezredmásodperc alatt lefut.

Szerk.: hülyeséget írtam, a seek a célfájlban seekel, így elvileg egy nagy fájlt hoz létre, de a nagy részébe nem ír. Ha jól rémlik, a fájlrendszeren ilyenkor nem lesz lefoglalva nagy terület, csak az a jelzés, hogy ott "luk" van a fájlban. De nem vagyok benne biztos, hogy ezt minden fájlrendszer támogatja, valószínűleg nálad valóban 1 GB-t akar seekelni.

Azt nem értem, hogy nálad ext3-on miért hoz létre a lemezen is ekkora fájlt, és miért nem hole-t rak bele - mert akkor úgy tűnik, gyors. Viszont ha tényleg a lemezen is lefoglalja a területet, és emiatt maga az lseek rendszerhívás tart sokáig, akkor érthető, hogy nem lehet megszakítani; gondolom, csak az után szakad meg, hogy a rendszerhívás visszatért.

( Proci85 v | 2010. 12. 31., p – 13:56 )

Sziasztok

Egy lvm snapshot valamiért néhány napja éjjel befagyott.
Azóta 100% környékén pörgeti az egyik cpu magot. Nem lövi le a kill, kill -9, -15, kill -kill sem.
Sajnos nem indíthatom újra a gépet. 


# kill -9 20999
#  
# ps aux | grep 20999
root     20999 87.5  0.0  16824   932 ?        R    Dec29 2973:50 mount /dev/vg/lvmsnapshot /mnt/lvmsnapshot

A messages logba folyamatosan ilyen csúnyaságokat ír napi több giga logot termelve: 


# tail -f /var/log/messages
Dec 31 12:44:05 kernel: uncatuncating inode 6392ununcatinuncating inode 6uncauncatiuncuncauncuncauncuncatinguncating inode 63927uuncauncating inode 639272 to 0 bytes
Dec 31 12:44:05 kernel: uncating iuncatinuncating inode 6392uncating inouncuncating iuncating uncating inode 639272 to 0 uncating inode 6uncatiuncatinuncating uncauncatuncating inode 6392uncating iununcatinguncatiuncating inodeuncauncating inuncating inode 63927uncating inode 639272 to 0 bytes
Dec 31 12:44:05 kernel: uncauncuncating inode 6uncating inodeuncating inode uncatuncatuncating inuncauncatiuncating inode 639uncating inuncating iuncuncatinguncating inode 639272 to 0 bytes
Dec 31 12:44:05 kernel: 7uncating inode 6392uncating inode 639uncuncating inode uncating inode uncating inouncating inouncauncating inuncuncating inoduncating inode uncating uncating uncauncating inode 63uncating inode 639272 touncating inoduncatuncatinuncatuncating inoduncating inouncatinuncating inode 639uncating inode 639272 to 0 bytes
Dec 31 12:44:05 kernel: uncating inode 639272 to 0 bytes
Dec 31 12:44:05 kernel: uncating inoduncatinuncating inode 639272 to 0 buncating inode 639272 to 0 bytes
Dec 31 12:44:05 kernel: uncating inode 63927uncating inode 639272 to 0 bytes
Dec 31 12:44:05 kernel: 7ununcauncatiuncatiununcuncuncatuncatuncauncatiuncatuncating inode 639272 to 0 byteununcatuncuncating iuncating inode 639272 to 0 bytes
Dec 31 12:44:05 kernel: 7uncating inode 639272 tuncating inode 639272 to 0 bytes
Dec 31 12:44:05 kernel: uncating inode 639272 uncating inode 639272 to 0 bytes
Dec 31 12:44:05 kernel: uncating inode 639272 to 0 buncating inodeuncating inode 6392uncauncating inuncatuncating inode 639272 to 0 bytes

Dmesg-re pedig ezeket kapom: 


ext3_orphan_cleanup: truncating inode 639272 to 0 bytes
ext3_orphan_cleanup: truncating inode 639272 to 0 bytes

Google pajtással semmi használhatót nem találtam.

Mount, df -h között nem látszik, umountolni nem tudom, mert nincs mountolva. A /dev/vg/lvmsnapshot-t nem tudom törölni az LVM közül, mert használatban van. 


  --- Logical volume ---
  LV Name                /dev/vg/lvmsnapshot
  VG Name                vg
  LV UUID                Y3v6uc-4xxB-2sz5-XmRq-iKK2-G8vx-Dm2tvU
  LV Write Access        read/write
  LV snapshot status     active destination for /dev/vg/data2
  LV Status              available
  # open                 1
  LV Size                15,00 GB
  Current LE             3840
  COW-table size         15,00 GB
  COW-table LE           3840
  Allocated to snapshot  9,27%
  Snapshot chunk size    4,00 KB
  Segments               2
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     2048
  Block device           253:90

Hogyan lehetne kilőni a processzt gép leállítás nélkül?
Előre is köszönöm a válaszokat.

azóta volt ehhez hasonló problémám, rákérdeztem különböző levlistákon, és két választ kaptam, amitől jobbat szerintem a hup-on se kapsz:

gond/kérdés: "kill AKÁRMI PID"-el sem lehet kilőni valamit, mert pl.: zombi
sum válasz:

1) A ppid-jét kell restartolni [a befagyott pid-jű process-nek], nálam itt annyi volt a gond, hogy az az "/sbin/init" volt.., de azért megpróbáltam egy "kill -HUP 1"-el, de nem működött, akkor is ott volt a process 100%-ban terhelve a gépet

2) most figyelj, "hivatalos" válasz: reboot. [Linux.]

szóval tervezz be egy restartot( ha az 1) nem jött be ), miután kinyomoztad, h. miért ragadt be [update volt?], logokat menteni esetleg, amik reboot-kor elveszhetnek.

htop fa nézetben nálam is az init 3-ból jön. Furcsálom is, mert cronból indítom.
Ha nincs jobb akkor majd 1x egy tervezett restart.
Update nem volt. Viszont az lvm-ben volt néhány régebbi inaktív partíció amiről megfeledkeztem és emiatt lehet, hogy a snapshotot már nem tudta rendesen addolni.
Mondjuk ettől elég volna egy hibát dobnia...
Persze azóta az inaktívakat töröltem, ismét van bőven felhasználható terület.

Ha egy process kernel space-ben akad el, akkor a signalok sem jutnak el hozza.
Preemptible kernellel kisebb az esely ilyenre, de az sem mindenhato megoldas.
Tessek megnezni, hogy mi az ami miatt kernel space hivas elakadt. Tobbnyire HW hiba szokott lenni.
ez a problema minden OSben jelen van.

( petya | 2010. 12. 31., p – 18:45 )

A process state a kulcs. Pl. ps aux-szal tudod megnezni. Ha a processz D allapotban van (io-ra var), akkor nem tudod kiloni, mert a linux kernel abba a queue-ba nem tud signalt kuldeni.