Synology-Forum.nl
Tweaks / Addons A.K.A. The Underground => Algemeen => Topic gestart door: Phoenix77 op 08 augustus 2014, 11:53:22
-
Hallo,
N.a.v. synolocker eens wat kritischer naar lopende processen gaan kijken op mijn NAS.
In de lijst staat een proces 0000:01:17:0 , weet iemand wat voor een proces dit is / van welke package dit proces is?
Mvgr,
Phoenix77
-
Geen idee, bij mij loopt er niet zo'n process.
Kill het process eens dan zie je vanzelf of er een package niet meer werkt.
-
Ik heb ook even mij bij gekeken op de DS213+ maar ook daar zie ik hem niet.
Zag wel wat crypto processen maar dat bleek standaard te zijn ipv het synocrypt process
-
Zegt XEN (mailing list software) je iets?
https://www.google.nl/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=%220000:01:17:0%22+process&safe=off
-
Killen lukt (mij) niet, zelfs kill -9 haalt niets uit.
Xen heb ik niet geïnstalleerd, wellicht is het een overblijfsel van een package dat ik ooit geïnstalleerd heb gehad.
Iemand een tip hoe ik kan nagaan of Xen ergens is achtergebleven?
-
zelfs kill -9 haalt niets uit.
Oei....das sterk :twisted:
kill -KILL <process>Werkt ook niet ?
-
Ken die hele Xen niet ::)
Iemand een tip hoe ik kan nagaan of Xen ergens is achtergebleven?
Je zou een find kunnen doen ?
find / -name *Xen*of
find / -name *xen*
-
Dat xen komt tevoorschijn als je googled op die procesnaam.
Betwijfel of het er iets mee te maken heeft.
Een process dat niet te killen is? Was je wel root op dat moment? (Dus geen admin)
-
Allemaal hartelijk dank voor jullie reacties.
kill -KILL <process>
Werkt vreemd genoeg ook niet.Ken die hele Xen niet ::)
Iemand een tip hoe ik kan nagaan of Xen ergens is achtergebleven?
Je zou een find kunnen doen ?
find / -name *Xen*of
find / -name *xen*
Geen Xen/xen aanwezig op mijn Synology.
BLijft een vreemd ding dat proces, Synology geeft aan dat DSM opnieuw installeren de enige manier is om er vanaf te komen. Iemand anders nog andere ideeën ?
Alvast bedankt.
-
Kijk even welk processid hij heeft en doe dan:
kill pid
Je moet zoals ik al zei wel als root ingelogd zijn en niet als admin.
-
Via ssh ben ik ingelogd als root, maar kill pid werkt vreemd genoeg niet.
-
Ik zou doen wat Synology heeft aangeraden en dat kun je doen zonder data verlies, let wel op de Opmerking:
http://www.synology.com/nl-nl/support/tutorials/493#t3
Vanaf punt 3.
-
Kan het te maken hebben met het feit dat het proces als status SW< heeft?
-
Denk het niet maar ik wil dat proces wel eens zien, kun je die eens even kopiëren in deze Topic ?
Neem aan dat je PuTTY gebruikt, maak dan eerst de window groter zodat we de hele regel kunt kopiëren.
Overigens, de betekenis van SW< :
S sleeping
W has no resident pages
< high-priority process
-
Het proces ziet er als volgt uit:
PID USER VSZ STAT COMMAND
3311 root 0 SW< [0000:01:17.0]
-
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
kill -9 3311
-
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.
-
kill -9 3311 zou process 3311 "de nek om moeten draaien" dus zonder pardon om zeep brengen.
-
Misschien dat een ander proces direct weer een nieuwe instantie van het proces start als het gekilled is?
-
[attachimg=1]
-
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 ?
-
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.
-
Heb je al eens gereboot?
-
Mijn NAS gaat elke avond uit en start elke ochtend weer op.
Ik zal hem morgen na een kill commando eens direct herstarten.
-
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.
-
(Link naar bijlage)
Zal morgen eens kijken of ik dit ook kan uitvoeren of dat ik onder root überhaubt niets kan killen.
-
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
-
Dat is zeker een optie, m.a.w. je zou in PuTTY daar het volgende kunnen uitlezen:
Ga eerst naar /proc/3311
cd proc/3311
Dan eens kijken of er hier wat bruikbare info te vinden is.
cat stat
cat cmdline
cat environ
cat status
cat cmdline
-
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.
-
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:
cat /etc/crontab
-
Taskscheduler geeft:
#minute hour mday month wday who command
3 4 * * 1,2,3,4,6 root /usr/syno/bin/synopkg chkupgradepkg
5 6 * * 5 root /var/packages/AntiVirus/target/bin/synoavscan --all
5 6 * * 1,2,3,4 root /var/packages/AntiVirus/target/bin/synoavscan --system
5 7 * * 0,6 root /var/packages/AntiVirus/target/bin/synoavscan --system
0 0 1 * * root /usr/syno/bin/syno_disk_health_record
34 3 * * 1,4 root /usr/syno/sbin/synoupgrade --fetch-all
30 23 * * 0,1,2,3,4 root /usr/syno/bin/syno_poweroff_feasible_check
59 23 * * 5,6 root /usr/syno/bin/syno_poweroff_feasible_check
30 6 * * * root /tmp/synoschedtask --run id=2
Ik heb een job gedefinieerd om DTS audio om te zetten in AC3, wellicht dat het deze job is?
-
Lijkt mij niet want deze task wordt alleen om 6:30 gestart dus, als je nu zou rebooten dan loopt deze task niet maar je krijgt wel proces 3311 weer terug.
-
Ik ga eens rebooten, kijken wat er gebeurt.
Zoals verwacht is hij er nog.
-
En wil je er toch helemaal zeker van zijn dan, kun je in crontab even een # voorzetten en dan rebooten:
#30 6 * * * root /tmp/synoschedtask --run id=2
Maar dit kan niet het proces zijn waar we op zoek naar zijn ;)
-
Zoals verwacht geen resultaat.
Misschien toch maar eens een herinstallatie van DSM doen, daar zit ik alleen niet echt op te wachten :S
-
Zou een kernel log nog bij kunnen dragen? http://www.wijngaard.org/how-to-get-the-synology-kernel-log/
-
In DSM5 werkt dat niet meer.
-
Hmm, da's jammer. Dat heb ik nog niet meegekregen.
-
Kwam er net ook pas achter hoor ;D
-
Ik vond een andere methode. Het schijnt tegenwoordig in het Support Center te zitten onder Support Services. Daar is een knop 'Generate logs' die een debug.dat uitspuugt.
-
Heel goed, was deze al kwijt of alweer vergeten ;)
Ingepakt is deze onder de 1 MB.
Zou die file wel eens willen onderzoeken maar dat kun je zelf natuurlijk ook.
De file is debug.dat en is gewoon een zip file, dus unzippen en kijken (mogelijk 4 MB)
Je mag de file debug.dat ook naar mij toesturen via mail. [attachimg=1]
-
Hoi Birdy,
Zojuist een e-mail gestuurd, ben benieuwd of jij iets kan vinden.
Is het wellicht de SPI controller voor de SD kaartlezer?
[Sat Aug 16 07:00:37 2014] Intel(R) SPI FLASH CONTROLLER Driver built on Jun 6 2014 @ 10:48:58
[Sat Aug 16 07:00:37 2014] ce5xx-spi-flash 0000:01:17.0: csr iobase 0xdffe0100, iosize 0x100 , mapped to 0xdae0e100
[Sat Aug 16 07:00:37 2014] ce5xx-spi-flash 0000:01:17.0: mem iobase 0xd8000000, iosize 0x4000000 , mapped to 0xdae80000
Mvgr,
Phoenix77
-
In dat geval zou ie tot leven moeten komen als je er een sd kaartje instopt.
-
Heb je E-mail gelezen en wat specifiek gaan zoek op internet en ben er van overtuigd geraakt dat je zelf het antwoord al gegeven hebt ;)
0000:01:17:0 is kennelijk het PCI hardware adres voor je SD reader waarbij SPI de Serial Peripheral Interface Bus is die dus over de I/O gaat.
M.a.w. [0000:01:17:0] process staat in feite daar en te wachten op I/O, dus als je een SD kaart erin doet dan zal deze gezien worden via dit process, dat is mijn theorie.
Daarom is het ook niet mogelijk om een dergelijk process te killen, dat zou je NAS van onderuit kunnen gaan, dus beveiligd dan wel het wordt direct weer gestart met dezelfde PID.
Aangezien ik geen SD reader heb in 1 van mijn Nassen, kon ik dit process dus ook niet terugvinden ;D
Denk dat andere DS bezitters met een SD reader een dergelijk process ook zullen aantreffen.
Dus, de vraag "In de lijst staat een proces 0000:01:17:0 , weet iemand wat voor een proces dit is / van welke package dit proces is?" is, denk ik, hierbij beantwoord. ;)
Have fun.
-
Zojuist een SD kaartje erin gestopt maar het proces blijft rustig. Zal straks even een paar Gb heen en weer gooien om te kijken of het proces dan wel iets doet.
Vindt het wel gek dat Synology support FR aangeeft dat het geen synology eigen proces is / het proces niet te kennen.
Ik zal nog eens terug reageren naar support of zij kunnen bevestigen of het proces bij de Intel(R) SPI FLASH CONTROLLER Driver hoort.
-
Zojuist een SD kaartje erin gestopt maar het proces blijft rustig.Het process blijft volgens mij inactief en fungeert alleen als I/O (pipe).
Als je nou toch gaat testen dan heb je dus grote kans dat je dan wel output krijgt zoals omschreven in mijn bericht. (http://www.synology-forum.nl/algemeen/onbekend-proces-000001170/msg121533/#msg121533)
Moet je alleen wel genoeg data sturen of lezen achter elkaar.
-
Helaas weinig output, alleen cat stat en cat status geven resultaat.
3311 (0000:01:17.0) S 2 0 0 0 -1 2216722496 0 0 0 0 0 0 0 0 0 -20 1 0 2720 0 0 4294967295 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 2 0 0 0 0 0
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
-
Ok....ik had iets anders verwacht.....maar goed dan jouw opmerking:
Vindt het wel gek dat Synology support FR aangeeft dat het geen synology eigen proces is / het proces niet te kennen.
Je zou nu terug kunnen gaan naar Synology en hen dan het volgende voorleggen:
[Sat Aug 16 07:00:37 2014] Intel(R) SPI FLASH CONTROLLER Driver built on Jun 6 2014 @ 10:48:58
[Sat Aug 16 07:00:37 2014] ce5xx-spi-flash 0000:01:17.0: csr iobase 0xdffe0100, iosize 0x100 , mapped to 0xdae0e100
[Sat Aug 16 07:00:37 2014] ce5xx-spi-flash 0000:01:17.0: mem iobase 0xd8000000, iosize 0x4000000 , mapped to 0xdae80000
Stuur dan ook debug.dat op zodat ze het gehele plaatje hebben. ;)
-
Vandaag bevestiging van Synology:
Finally I received feedback and I can confirm that it belongs to that driver.
0000:01:17.0 is the pci device of Evansport SOC SPI flash controller.
The process in the ps list is a kernel thread of single thread workqueue initialized in the flash controller driver.
Het is dus inderdaad het proces dat bij de SD kaart lezer hoort, mysterie opgelost ;D
-
Mooi.....daar zijn we dan uit ;)
Bedankt!