View Full Version : [VU+ Duo] Enigma 2 Process - Memory Leak? (3.0.268)
Hi Guys,
I'm running ViX Team Image 3.0.268 on a Vu Duo. After a few days (2-3 days) without rebooting, the box response gets quite sluggish - 10 to 20 seconds elapse before the pushes of the remote have any effect.
I used ssh to connect to the box - everything seems fine, except for the fact that enigma2 which seems to take all the memory
Mem: 126496K used, 11884K free, 0K shrd, 324K buff, 3768K cached
CPU: 0% usr 12% sys 4% nic 80% idle 0% io 0% irq 4% sirq
Load average: 3.09 1.77 1.20 2/83 8718
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
8716 8677 root R 2656 2% 8% top
370 365 root S 235m 174% 4% /usr/bin/enigma2
8309 1 root S 7284 5% 0% /usr/sbin/smbd
[…]
Over the past couple of days I tried to find out what's triggering the issue. I couldn't figure it out. The utilized memory increases gradually over several days (when I'm watching it seems to be stable though... It looks like I loose 10 to 20 MB in discrete steps :rolleyes: )
A few notes about my ViX configuration:
- Installed 208 (did not restore old Config files of course), Upgraded to 268 via online update a couple of days ago.
- Installed Samba, nothing else (no plugins)
- swapfile is on USB Stick (92 MB)
- I deleted the EPG files, which reside on a USB Stick, while Enigma was sleeping. This did not help
- tried upgrading to the latest unstable ViX Image today, did not work (Enigma crashed on launch)
Would you have any ideas for further troubleshooting?
I really apologize if I missed any important information or troubleshooting steps. Currently I'm a bit short on time due to my job. I would defer getting help until I have time, but my family seems a bit bothered about the unreliabilty of the tv.
Thanks in advance for your help.
There is a known but not especially common problem with some Duo models suffering a memory leak on the 3.1.1 kernel. Vu are aware of this, but as of yet no fix is available than to go back to a earlier 2.6.18 kernel based image.
Sent from my GT-I9300 using Tapatalk 2
Hi Phoenix,
thanks for the info. That makes sense.
I think I will try to set the box to do a nightly reboot. That'll hopefully be enough to mitigate the issue in the short term.
Hi Phoenix,
thanks for the info. That makes sense.
I think I will try to set the box to do a nightly reboot. That'll hopefully be enough to mitigate the issue in the short term.
There is at least one plugin available that can flush the memory of the box when as and when you want to, although i'm not too sure of the name at present as it's been a long time since i tried it.
Sounds interesting, although I would not know how that kind of software might work. It can't know which sections of the memory are in use after all, I guess.
Nevertheless I seem to be getting closer to the root of the issue.
I am now fairly certain that reloading the EPG is causing my leak.
I can reliably reproduce the issue on my system now:
Go to Menu > Settings > System > EPG > Load / Save > Load EPG.
Accept by clicking "yes"
Repeat above mentioned steps ad lib. On my system the memory usage increases every time by 0.5 MB to 10 MB (I presume depending on the size of my EPG.dat file)
I previously set my EPG to reload every couple of hours, so over time that was causing my box to struggle. I disabled that now and will see how it goes.
Sounds interesting, although I would not know how that kind of software might work. It can't know which sections of the memory are in use after all, I guess.
Nevertheless I seem to be getting closer to the root of the issue.
I am now fairly certain that reloading the EPG is causing my leak.
I can reliably reproduce the issue on my system now:
Go to Menu > Settings > System > EPG > Load / Save > Load EPG.
Accept by clicking "yes"
Repeat above mentioned steps ad lib. On my system the memory usage increases every time by 0.5 MB to 10 MB (I presume depending on the size of my EPG.dat file)
I previously set my EPG to reload every couple of hours, so over time that was causing my box to struggle. I disabled that now and will see how it goes.
setting the EPG to refresh every couple of hours is fairly extreme and frankly overkill, once a day is more than adequate, all of mine are set to update in the early hours at around 04:00 and are good after that. also be aware that EPG data is held in live memory and only written to or read from storage media upon bootup or shutdown.
setting the EPG to refresh every couple of hours is fairly extreme and frankly overkill, once a day is more than adequate, all of mine are set to update in the early hours at around 04:00 and are good after that.
Oh, I think there's a misunderstanding. I don't talk about downloading the EPG. This I also set to do only once in the early morning hours.
I (think) I'm talking about periodic write / read of epg.dat. This - at least if my interpretations of the settings are correct - should not be required at all. As you state, the System automatically loads / saves the data when shutting down / boot up.
(I did enable this setting because I had trouble with the epg getting lost occasionally - turned out it was a bad usb stick - after replacing the stick I naturally forgot to disable both settings... silly me)
I'd still consider this behavior to be a bug, but luckily it should not affect me in the future.
Anyways: Phoenix, thanks for your support.
Have you an internal HDD in the Duo?
I moved EPG to internal HDD & picons to flash about 6 months ago & have never had any EPG related issues on the DUO since.
Saying that, I never set automatic refresh on EPG & see no need to.
Does seem like the auto refresh is killing your box though, thanks for the pointers.
Hi judge,
yes, I've gotten an internal HDD as well. I think it makes sense for me to move EPG to the internal drive as well. I might try that for the future.
Hi judge,
yes, I've gotten an internal HDD as well. I think it makes sense for me to move EPG to the internal drive as well. I might try that for the future.
Well worth trying as EPG is only read on boot & download, written on shutdown.
Internal HDD seems to be a better option for the DUO.
You're absolutely right. I didn't know that back when I first set up the box.
I already modified my config accordingly.
Cheers, Christian
Not a solution to your issues but helps us recommend preferred options while we look into them.
If you have a working internal HDD, EPG seems better stored there.
Rob van der Does
19-09-12, 06:50
I would use some stronger words here: flash is the worst possible location for EPG.
The amount of EPG-data, and hence the storage file, can grow enormously. Even to the point of filling flash completely and making the box unbootable; this is especially the case on low-memory boxes like Solo, DUO and ET5000. Using a HDD or an USB device makes no difference, but flash is 'not done'.
For picons however flash is fine.
Today I did just that. EPG resides on my internal hard drive now. It is indeed a better fit.
Cheers, Christian
I would use some stronger words here: flash is the worst possible location for EPG.
The amount of EPG-data, and hence the storage file, can grow enormously. Even to the point of filling flash completely and making the box unbootable; this is especially the case on low-memory boxes like Solo, DUO and ET5000. Using a HDD or an USB device makes no difference, but flash is 'not done'.
For picons however flash is fine.
A few notes about my ViX configuration:
[…]
- I deleted the EPG files, which reside on a USB Stick, while Enigma was sleeping.
I never used the internal flash to store the EPG Database
I have been having this issue too, using 3.1.1 kernel
I had my EPG on HDD previously but this didn't seem to make any difference.
Suspecting it was due to too many EPG sources I decided to disable EPG entirely and this seemed to have resolved it, no issues after week or two. Although I wasn't checking memory usage at the time.
I then enabled just one CrossEPG provider (XEPGDB) with 3 Rytec XMLTV (Italy, Poland, UK).
Things seem to be going OK for a week or so until just now.
Checking memory usage confirmed engima2 was using 234Mb. Having read this thread I used used CrossEPG Downloader and observed this process usage increase by several Mb.
Next I tried Engima restart using on-screen menu (long power button). ViX logo was spinning for some time and after several minutes there was still no change to engima2 process so I then restarted the process via SSH using the command "killall -HUP enigma2". Within a few seconds I was back to normal, with enigma2 process showing 74548 (e.g. ~73Mb) and seems to be stable.
Downloading EPG again as before saw enigma2 process increase to about 80Mb as it hit the merging, dropping back to around 74Mb.
Once it reached the final Loading Data I saw enigma2 increase again, settling at 103Mb.
So it does seem EPG leaks into engima2, kind of like a misbehaving browser plugin or something.
Although confusingly after a reboot via the on-screen menu engima2 is using 101Mb. :confused:
No EPG loaded as I have not enabled loading during boot.
Repeated rebooted as before, now 106Mb
Next tried "reboot" via SSH, this time 108 Mb.
Restarted engima using "killall -HUP engima2" and now engima2 process is consuming 132 Mb (98%) WTF?!
So I suspect CrossEPG is not the cause but is merely bringing it on or triggering that bit quicker due it's regular spikes in memory usage.
Loading EPG at this point brings engima2 usage to 139Mb (103%).
So I have decided to use Cron Manager (via ViX menu) to restart engima2 every day. Hopefully that will do for now.
Rob van der Does
13-01-13, 07:18
So it does seem EPG leaks into engima2, kind of like a misbehaving browser plugin or something.
No, I wouldn't dare concluding that.
It is known that Cross-EPG is a very memory hungry task, and not all boxes are capable of handling that.
Using a (large) SWAP-file and CacheFlush usually helps.
In fact (daily) rebooting the box serves the same purpose, but the above way is more subtile and doesn't interfere with the normal usage of the box.
guy's there is nothing wrong with e2 taking all available ram it is supposed too, just designed this way, it is not USING it all it has just cached it. for faster access.
No, I wouldn't dare concluding that.
It is known that Cross-EPG is a very memory hungry task, and not all boxes are capable of handling that.
Using a (large) SWAP-file and CacheFlush usually helps.
In fact (daily) rebooting the box serves the same purpose, but the above way is more subtile and doesn't interfere with the normal usage of the box.
Definetely not concluding, I don't have anywhere enough understanding and evidence for that.
But engima2 process does include EPG and other data?
Would be nice if this could be kept as a child process.
I am using largest allowed swap. Thanks for suggestion of CacheFlush, I'll give this a try.
guy's there is nothing wrong with e2 taking all available ram it is supposed too, just designed this way, it is not USING it all it has just cached it. for faster access.
Understood, but surely something is going wrong somewhere when it's exceeding 100%, and keeps climbing to the point where system becomes unresponsive?
Understood, but surely something is going wrong somewhere when it's exceeding 100%, and keeps climbing to the point where system becomes unresponsive?
my top (from solo2)
Mem: 144292K used, 427448K free, 0K shrd, 2540K buff, 48816K cachedCPU: 0% usr 0% sys 0% nic 98% idle 0% io 0% irq 0% sirq
Load average: 0.03 0.04 0.05 2/72 1483
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
1414 1409 root R 115m 21% 1% /usr/bin/enigma2
383 1 avahi S 3820 1% 0% avahi-daemon: running [vusolo2.local]
384 383 avahi S 3692 1% 0% avahi-daemon: chroot helper
360 1 messageb S 3048 1% 0% /usr/bin/dbus-daemon --system
371 1 root S 3032 1% 0% /usr/sbin/inetd
592 371 root S 2984 1% 0% telnetd
1483 593 root R 2980 1% 0% top
593 592 root S 2980 1% 0% -sh
364 1 root S 2664 0% 0% /usr/sbin/dropbear -r /etc/dropbear/dropbear_rsa_host_key -p 22
376 1 root S 2656 0% 0% /sbin/klogd -n
374 1 root S 2656 0% 0% /sbin/syslogd -n -O /var/log/messages
340 1 root S 2656 0% 0% udhcpc -R -b -H vusolo2 -p /var/run/udhcpc.eth0.pid -i eth0
1409 1 root S 2656 0% 0% {enigma2.sh} /bin/sh /usr/bin/enigma2.sh
1 0 root S 1916 0% 0% init [3]
17 2 root SW 0 0% 0% [khubd]
9 2 root SW 0 0% 0% [ksoftirqd/1]
3 2 root SW 0 0% 0% [ksoftirqd/0]
108 2 root SW 0 0% 0% [nx_sched_low]
105 2 root RW 0 0% 0% [nx_sched_high_a]
44 2 root SW 0 0% 0% [ubi_bgt0d]
5 2 root SW 0 0% 0% [kworker/u:0]
35 2 root SW 0 0% 0% [scsi_eh_1]
36 2 root SW 0 0% 0% [kworker/u:1]
12 2 root SW 0 0% 0% [kdevtmpfs]
92 2 root SW 0 0% 0% [jbd2/sda1-8]
1056 2 root SW 0 0% 0% [kworker/0:0]
2 0 root SW 0 0% 0% [kthreadd]
8 2 root SW 0 0% 0% [kworker/1:0]
132 2 root SW 0 0% 0% [fbt0]
1027 2 root SW 0 0% 0% [kworker/0:2]
6 2 root SW 0 0% 0% [migration/0]
7 2 root SW 0 0% 0% [migration/1]
11 2 root SW< 0 0% 0% [khelper]
13 2 root SW 0 0% 0% [sync_supers]
14 2 root SW 0 0% 0% [bdi-default]
15 2 root SW< 0 0% 0% [kblockd]
16 2 root SW< 0 0% 0% [ata_sff]
18 2 root SW< 0 0% 0% [cfg80211]
19 2 root SW< 0 0% 0% [rpciod]
20 2 root SW 0 0% 0% [kswapd0]
22 2 root SW 0 0% 0% [fsnotify_mark]
23 2 root SW< 0 0% 0% [nfsiod]
24 2 root SW< 0 0% 0% [crypto]
34 2 root SW 0 0% 0% [scsi_eh_0]
40 2 root SW 0 0% 0% [mtdblock0]
41 2 root SW 0 0% 0% [mtdblock1]
and ultimo
Mem: 179312K used, 96040K free, 0K shrd, 40980K buff, 31272K cachedCPU: 1% usr 0% sys 0% nic 97% idle 0% io 0% irq 0% sirq
Load average: 0.07 0.13 0.40 1/99 26858
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
405 399 root S 167m 62% 2% /usr/bin/enigma2
26857 26856 root R 2980 1% 0% top
373 1 root S 78112 28% 0% /opt/bin/mediasrv -d --no-nodes --wait-for-devices
455 454 root S < 8636 3% 0% /usr/softcams/oscam -b
374 373 root S 6772 2% 0% /opt/bin/mediasrv -d --no-nodes --wait-for-devices
454 1 root S 4380 2% 0% /usr/softcams/oscam -b
360 1 avahi S 3796 1% 0% avahi-daemon: running [vuultimo.local]
361 360 avahi S 3692 1% 0% avahi-daemon: chroot helper
314 1 messageb S 3048 1% 0% /usr/bin/dbus-daemon --system
325 1 root S 3032 1% 0% /usr/sbin/inetd
26855 325 root S 2984 1% 0% telnetd
26856 26855 root S 2980 1% 0% -sh
318 1 root S 2664 1% 0% /usr/sbin/dropbear -r /etc/dropbear/dropbear_rsa_host_key -p 22
353 1 root S 2656 1% 0% /sbin/klogd -n
351 1 root S 2656 1% 0% /sbin/syslogd -n -O /var/log/messages
399 1 root S 2656 1% 0% {enigma2.sh} /bin/sh /usr/bin/enigma2.sh
290 1 root S 2656 1% 0% udhcpc -R -b -H vuultimo -p /var/run/udhcpc.eth0.pid -i eth0
344 1 root S 2576 1% 0% /usr/sbin/rpc.mountd -f /etc/exports
346 1 root S 2256 1% 0% /usr/sbin/rpc.statd
301 1 daemon S 2000 1% 0% /sbin/portmap
1 0 root S 1916 1% 0% init [3]
107 2 root SW 0 0% 0% [sched_high]
20 2 root SW 0 0% 0% [kswapd0]
8 2 root SW 0 0% 0% [kworker/1:0]
3 2 root SW 0 0% 0% [ksoftirqd/0]
92 2 root SW 0 0% 0% [jbd2/sda1-8]
410 2 root SW 0 0% 0% [ci_kthread]
37 2 root SW 0 0% 0% [kworker/1:1]
409 2 root SW 0 0% 0% [ca:0:4]
106 2 root SW 0 0% 0% [sched_low]
9 2 root SW 0 0% 0% [ksoftirqd/1]
47 2 root SW 0 0% 0% [ubi_bgt0d]
25460 2 root SW 0 0% 0% [kworker/0:0]
105 2 root SW 0 0% 0% [sched]
17 2 root SW 0 0% 0% [khubd]
48 2 root SW 0 0% 0% [ubifs_bgt0_0]
33 2 root SW 0 0% 0% [scsi_eh_0]
13 2 root SW 0 0% 0% [sync_supers]
34 2 root SW 0 0% 0% [scsi_eh_1]
2 0 root SW 0 0% 0% [kthreadd]
5 2 root SW 0 0% 0% [kworker/u:0]
12 2 root SW 0 0% 0% [kdevtmpfs]
35 2 root SW 0 0% 0% [kworker/u:1]
As you've shown me yours I'll show you mine. :p
Mem: 124012K used, 14228K free, 0K shrd, 368K buff, 31776K cached
CPU: 0% usr 4% sys 0% nic 95% idle 0% io 0% irq 0% sirq
Load average: 0.08 0.16 0.25 1/71 888
PID PPID USER STAT VSZ %MEM %CPU COMMAND
612 605 root S 179m 133% 0% /usr/bin/enigma2
413 1 root S 3312 2% 0% /usr/sbin/inetd
844 413 root S 3268 2% 0% telnetd
845 844 root S 3264 2% 0% -sh
411 1 root S 3200 2% 0% /usr/sbin/crond -c /etc/cron/crontabs
432 1 root S 3012 2% 0% /sbin/getty 38400 tty1
416 1 root S 2948 2% 0% /sbin/syslogd -n -O /var/log/messages -s 32 -b 1 -m 20
418 1 root S 2948 2% 0% /sbin/klogd -n
605 1 root S 2948 2% 0% /bin/sh /usr/bin/enigma2.sh
888 845 root R 2948 2% 0% top
372 1 root S 2948 2% 0% [udhcpc]
1 0 root S 1800 1% 0% init [3]
20 2 root SW 0 0% 0% [kswapd0]
133 2 root SW 0 0% 0% [sched_high]
45 2 root SW 0 0% 0% [usb-storage]
83 2 root SW 0 0% 0% [jbd2/sda1-8]
134 2 root SW 0 0% 0% [sched_idle]
3 2 root SW 0 0% 0% [ksoftirqd/0]
132 2 root SW 0 0% 0% [sched_low]
78 2 root SW 0 0% 0% [kworker/0:2]
4 2 root SW 0 0% 0% [kworker/0:0]
35 2 root SW 0 0% 0% [kworker/u:1]
169 2 root SW 0 0% 0% [lcd]
39 2 root SW 0 0% 0% [mtdblock2]
440 2 root SW 0 0% 0% [ca:0:4]
820 2 root SW 0 0% 0% [kdvb-ad-0-fe-0]
38 2 root SW 0 0% 0% [mtdblock1]
41 2 root SW 0 0% 0% [mtdblock4]
9 2 root SW 0 0% 0% [ksoftirqd/1]
42 2 root SW 0 0% 0% [mtdblock5]
441 2 root SW 0 0% 0% [ci_kthread]
16 2 root SW 0 0% 0% [khubd]
2 0 root SW 0 0% 0% [kthreadd]
809 2 root SW 0 0% 0% [kworker/1:1]
40 2 root SW 0 0% 0% [mtdblock3]
37 2 root SW 0 0% 0% [mtdblock0]
43 2 root SW 0 0% 0% [mtdblock6]
112 2 root SW 0 0% 0% [jbd2/sdb1-8]
33 2 root SW 0 0% 0% [scsi_eh_0]
34 2 root SW 0 0% 0% [scsi_eh_1]
5 2 root SW 0 0% 0% [kworker/u:0]
6 2 root SW 0 0% 0% [migration/0]
7 2 root SW 0 0% 0% [migration/1]
11 2 root SW< 0 0% 0% [khelper]
12 2 root SW 0 0% 0% [sync_supers]
13 2 root SW 0 0% 0% [bdi-default]
14 2 root SW< 0 0% 0% [kblockd]
15 2 root SW< 0 0% 0% [ata_sff]
17 2 root SW< 0 0% 0% [cfg80211]
As you've shown me yours I'll show you mine. :p
Mem: 124012K used, 14228K free, 0K shrd, 368K buff, 31776K cached
CPU: 0% usr 4% sys 0% nic 95% idle 0% io 0% irq 0% sirq
Load average: 0.08 0.16 0.25 1/71 888
PID PPID USER STAT VSZ %MEM %CPU COMMAND
612 605 root S 179m 133% 0% /usr/bin/enigma2
413 1 root S 3312 2% 0% /usr/sbin/inetd
844 413 root S 3268 2% 0% telnetd
845 844 root S 3264 2% 0% -sh
411 1 root S 3200 2% 0% /usr/sbin/crond -c /etc/cron/crontabs
432 1 root S 3012 2% 0% /sbin/getty 38400 tty1
416 1 root S 2948 2% 0% /sbin/syslogd -n -O /var/log/messages -s 32 -b 1 -m 20
418 1 root S 2948 2% 0% /sbin/klogd -n
605 1 root S 2948 2% 0% /bin/sh /usr/bin/enigma2.sh
888 845 root R 2948 2% 0% top
372 1 root S 2948 2% 0% [udhcpc]
1 0 root S 1800 1% 0% init [3]
20 2 root SW 0 0% 0% [kswapd0]
133 2 root SW 0 0% 0% [sched_high]
45 2 root SW 0 0% 0% [usb-storage]
83 2 root SW 0 0% 0% [jbd2/sda1-8]
134 2 root SW 0 0% 0% [sched_idle]
3 2 root SW 0 0% 0% [ksoftirqd/0]
132 2 root SW 0 0% 0% [sched_low]
78 2 root SW 0 0% 0% [kworker/0:2]
4 2 root SW 0 0% 0% [kworker/0:0]
35 2 root SW 0 0% 0% [kworker/u:1]
169 2 root SW 0 0% 0% [lcd]
39 2 root SW 0 0% 0% [mtdblock2]
440 2 root SW 0 0% 0% [ca:0:4]
820 2 root SW 0 0% 0% [kdvb-ad-0-fe-0]
38 2 root SW 0 0% 0% [mtdblock1]
41 2 root SW 0 0% 0% [mtdblock4]
9 2 root SW 0 0% 0% [ksoftirqd/1]
42 2 root SW 0 0% 0% [mtdblock5]
441 2 root SW 0 0% 0% [ci_kthread]
16 2 root SW 0 0% 0% [khubd]
2 0 root SW 0 0% 0% [kthreadd]
809 2 root SW 0 0% 0% [kworker/1:1]
40 2 root SW 0 0% 0% [mtdblock3]
37 2 root SW 0 0% 0% [mtdblock0]
43 2 root SW 0 0% 0% [mtdblock6]
112 2 root SW 0 0% 0% [jbd2/sdb1-8]
33 2 root SW 0 0% 0% [scsi_eh_0]
34 2 root SW 0 0% 0% [scsi_eh_1]
5 2 root SW 0 0% 0% [kworker/u:0]
6 2 root SW 0 0% 0% [migration/0]
7 2 root SW 0 0% 0% [migration/1]
11 2 root SW< 0 0% 0% [khelper]
12 2 root SW 0 0% 0% [sync_supers]
13 2 root SW 0 0% 0% [bdi-default]
14 2 root SW< 0 0% 0% [kblockd]
15 2 root SW< 0 0% 0% [ata_sff]
17 2 root SW< 0 0% 0% [cfg80211]
what build ?
Build: 213
Build 213 is ancient now and by comparison almost a different image in it self, we are currently on 562 plus.
I would create a settings backup using the ViX backup manager and flash the image from fresh to 562 from the image server, then restore your backup.
The image server can be found here,
http://www.world-of-satellite.com/enigma2/openvix/index.php?dir=
Build 213 is ancient now and by comparison almost a different image in it self, we are currently on 562 plus.
I would create a settings backup using the ViX backup manager and flash the image from fresh to 562 from the image server, then restore your backup.
The image server can be found here,
http://www.world-of-satellite.com/enigma2/openvix/index.php?dir=
Thanks!
I was under the impression stable releases would update via the in-built software update.
I'll give this a try and report back.
They do yes, although as i said your current image is over 300 plus builds old and in that time there have been many thousands of updates and fixes for the image, if you do update all the way it will likely cause instabilities, thats if it even updates that far as certain builds require a full fresh flash due to changes made etc.
Here's my top running build 562:
Mem: 127376K used, 11004K free, 0K shrd, 780K buff, 6376K cached
CPU: 0% usr 0% sys 0% nic 97% idle 0% io 0% irq 1% sirq
Load average: 0.24 0.35 0.43 1/72 1031
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
439 434 root S 162m 120% 1% /usr/bin/enigma2
1031 975 root R 2980 2% 0% top
143 2 root SW 0 0% 0% [sched_high]
3 2 root SW 0 0% 0% [ksoftirqd/0]
972 2 root SW 0 0% 0% [kdvb-ad-0-fe-0]
358 1 avahi S 3692 3% 0% avahi-daemon: running [vuduo.local]
359 358 avahi S 3692 3% 0% avahi-daemon: chroot helper
335 1 messageb S 3048 2% 0% /usr/bin/dbus-daemon --system
346 1 root S 3032 2% 0% /usr/sbin/inetd
974 346 root S 2984 2% 0% telnetd
975 974 root S 2980 2% 0% -sh
351 1 root S 2656 2% 0% /sbin/klogd -n
349 1 root S 2656 2% 0% /sbin/syslogd -n -O /var/log/messages
315 1 root S 2656 2% 0% udhcpc -R -b -H vuduo -p /var/run/udhcpc.eth0.pid -i et
434 1 root S 2656 2% 0% {enigma2.sh} /bin/sh /usr/bin/enigma2.sh
1 0 root S 1916 1% 0% init [3]
44 2 root SW 0 0% 0% [usb-storage]
21 2 root SW 0 0% 0% [kswapd0]
142 2 root SW 0 0% 0% [sched_low]
48 2 root SW 0 0% 0% [ubi_bgt0d]
46 2 root SW 0 0% 0% [mtdblock5]
93 2 root SW 0 0% 0% [kworker/0:2]
41 2 root SW 0 0% 0% [mtdblock3]
369 2 root SW 0 0% 0% [ca:0:4]
5 2 root SW 0 0% 0% [kworker/u:0]
4 2 root SW 0 0% 0% [kworker/0:0]
47 2 root SW 0 0% 0% [mtdblock6]
370 2 root SW 0 0% 0% [ci_kthread]
38 2 root SW 0 0% 0% [mtdblock0]
39 2 root SW 0 0% 0% [mtdblock1]
40 2 root SW 0 0% 0% [mtdblock2]
42 2 root SW 0 0% 0% [mtdblock4]
179 2 root SW 0 0% 0% [lcd]
769 2 root SW 0 0% 0% [kworker/1:0]
95 2 root SW 0 0% 0% [jbd2/sda1-8]
49 2 root SW 0 0% 0% [ubifs_bgt0_0]
128 2 root SW 0 0% 0% [jbd2/sdb1-8]
9 2 root SW 0 0% 0% [ksoftirqd/1]
12 2 root SW 0 0% 0% [kdevtmpfs]
17 2 root SW 0 0% 0% [khubd]
35 2 root SW 0 0% 0% [scsi_eh_1]
36 2 root SW 0 0% 0% [kworker/u:1]
2 0 root SW 0 0% 0% [kthreadd]
6 2 root SW 0 0% 0% [migration/0]
7 2 root SW 0 0% 0% [migration/1]
11 2 root SW< 0 0% 0% [khelper]
13 2 root SW 0 0% 0% [sync_supers]
14 2 root SW 0 0% 0% [bdi-default]
15 2 root SW< 0 0% 0% [kblockd]
16 2 root SW< 0 0% 0% [ata_sff]
So far so good and memory seems OK:
total used free shared buffers
Mem: 138380 127468 10912 0 780
-/+ buffers: 126688 11692
Swap: 98300 25544 72756
EPG running with daily updates, no automatic restart of enigma process or device.
Fingers crossed it remains stable.
Thanks again for the help guys, much appreciated. :)
Just to update, still experienced some issues until about 2 ViX updates.
Currently on build 600, uptime 17 days, no need to restart any processes either :)
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.