Onbekend proces 0000:01:17:0

[Basalt]

Het proces ziet er als volgt uit:

  PID USER  VSZ  STAT  COMMAND
3311 root    0     SW<  [0000:01:17.0]

Wat gebeurt er precies als je inlogt als root en het volgende commando geeft

Code: [Selecteer]

kill -9 3311

[Phoenix77]

Het lijkt erop dat het commando wordt uitgevoerd. Geen foutmeldingen of iets dergelijks.

Als ik daarna PS weer opnieuw uitvoer dan zie ik het proces nog steeds in de lijst staan.

[Birdy]

Code: [Selecteer]

kill -9 3311 zou process 3311 "de nek om moeten draaien" dus zonder pardon om zeep brengen.

[Phoenix77]

Misschien dat een ander proces direct weer een nieuwe instantie van het proces start als het gekilled is?

[Birdy]

[Birdy]

Misschien dat een ander proces direct weer een nieuwe instantie van het proces start als het gekilled is?

Dat kan, maar dan krijg je wel een ander process ID.

@Phoenix77
Is dat zo ?

[Basalt]

Misschien dat een ander proces direct weer een nieuwe instantie van het proces start als het gekilled is?

Nee, dat zou een andere pid krijgen.
Als root moet je ieder proces met "kill -9" direct kunnen beëindigen, heel raar dat het in dit geval niet werkt.

[Basalt]

Heb je al eens gereboot?

[Phoenix77]

Mijn NAS gaat elke avond uit en start elke ochtend weer op.

Ik zal hem morgen na een kill commando eens direct herstarten.

[Phoenix77]

Misschien dat een ander proces direct weer een nieuwe instantie van het proces start als het gekilled is?

Dat kan, maar dan krijg je wel een ander process ID.

@Phoenix77
Is dat zo ?

Nee hij houdt pid 3311, ik snap er echt niets van. Proces heeft sinds ik hem gezien heb altijd pid 3311 gehad.

Vast iets wat is blijven hangen van een vd packages die ik geïnstalleerd had.

[Phoenix77]

(Link naar bijlage)

Zal morgen eens kijken of ik dit ook kan uitvoeren of dat ik onder root überhaubt niets kan killen.

[Basalt]

Nog wat gegoogled: er wordt gesproken over Zombie processen die in de kernel code blijven hangen, mogelijk in een I/O wait (bijv door hardware of NFS probleem). Je zou dan zijn parent kunnen killen, waardoor het proces zelf wellicht alsnog verdwijnt.

Maar als je na reboot direct weer zo'n Zombie hebt, dan is handmatig killen geen echte oplossing. Je zou dan onder /proc/<pid> (bijv /proc/3311) eens kunnen kijken of je wat wijzer wordt waar dit proces vandaan komt.

/Erik

[Birdy]

Dat is zeker een optie, m.a.w. je zou in PuTTY daar het volgende kunnen uitlezen:

Ga eerst naar /proc/3311

Code: [Selecteer]

cd proc/3311
Dan eens kijken of er hier wat bruikbare info te vinden is.

Code: [Selecteer]

cat stat

Code: [Selecteer]

cat cmdline

Code: [Selecteer]

cat environ

Code: [Selecteer]

cat status

Code: [Selecteer]

cat cmdline

[Phoenix77]

Vanochtend was proces 3311 er weer.

Even gecontroleerd of ik überhaubt een proces kan killen en het lukt mij om mijn ssh proces te killen.

N.a.v. de hints van Birdy hier de resultaten:

cat stat: 3311 (0000:01:17.0) S 2 0 0 0 -1 2216722496 0 0 0 0 0 0 0 0 0 -20 1 0 2730 0 0 4294967295 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 2 0 0 0 0 0

cat status:
Name:   0000:01:17.0
State:  S (sleeping)
Tgid:   3311
Pid:    3311
PPid:   2
TracerPid:      0
Uid:    0       0       0       0
Gid:    0       0       0       0
FDSize: 32
Groups:
Threads:        1
SigQ:   1/5561
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: ffffffffffffffff
SigCgt: 0000000000000000
CapInh: 0000000000000000
CapPrm: ffffffffffffffff
CapEff: ffffffffffffffff
CapBnd: ffffffffffffffff
Cpus_allowed:   f
Cpus_allowed_list:      0-3
voluntary_ctxt_switches:        2
nonvoluntary_ctxt_switches:     0

de overige cat commando's leverde niets op.

[Birdy]

Bedankt echter, helaas (voor mij althans) geeft 'stat' geen nuttige info.
V.w.b.

de overige cat commando's leverde niets op.

geeft mij de indruk dat het een zombie proces is echter, de vraag blijft, waardoor wordt deze opgestart.

Hiervoor zou het gehele opstart proces van de DS op nagezien moeten worden (b.v. rc.d scripts) en dat is een hele klus en daarbij is het de vraag of je het daar kunt vinden.

Het enige wat je wel snel zou kunnen checken is de crontab, misschien wordt dat proces van daaruit gestart:

Code: [Selecteer]

cat /etc/crontab