Active Topics

 


Reply
Thread Tools
int_ua's Avatar
Posts: 676 | Thanked: 1,067 times | Joined on Jul 2010 @ Kyiv, Ukraine
#1
Looks like I've found the reason of my N900's reboots every 6 days of uptime: dbus-daemon takes more and more RAM.
It's only 3Mb on the start but doubles every 24 hours.
I'm going to file a bug report, you can help by checking yours with
Code:
uptime
sudo pmap $(pidof dbus-daemon) | grep total
How can I restart dbus-daemon? Even when I tried it from user 30000 it just reboots the phone.

Update: it looks like it was recaller's fault.

Update: no, it was batterypatch-non-kp

Last edited by int_ua; 2012-10-03 at 19:23.
 
joerg_rw's Avatar
Posts: 2,222 | Thanked: 12,651 times | Joined on Mar 2010 @ SOL 3
#2
since dbus is of paramount importance to whole system, I think you hardly can restart it without system reboot


btw you must have something special there, I had uptimes of >150 days.

/j
__________________
Maemo Community Council member [2012-10, 2013-05, 2013-11, 2014-06 terms]
Hildon Foundation Council inaugural member.
MCe.V. foundation member

EX Hildon Foundation approved
Maemo Administration Coordinator (stepped down due to bullying 2014-04-05)
aka "techstaff" - the guys who keep your infra running - Devotion to Duty http://xkcd.com/705/

IRC(freenode): DocScrutinizer*
First USB hostmode fanatic, father of H-E-N
 

The Following User Says Thank You to joerg_rw For This Useful Post:
int_ua's Avatar
Posts: 676 | Thanked: 1,067 times | Joined on Jul 2010 @ Kyiv, Ukraine
#3
Code:
$ sudo /etc/init.d/dbus restart
sort: unrecognized option `--reverse'
BusyBox v1.10.2 (Debian 3:1.10.2.legal-1osso30+0m5) multi-call binary
Looks like it was never tested.
Update: I've replaced the sort with a GNU sort and the script worked but it just spawns third dbus-daemon without closing the first one.

Last edited by int_ua; 2012-08-09 at 06:31.
 

The Following User Says Thank You to int_ua For This Useful Post:
Posts: 32 | Thanked: 30 times | Joined on Jul 2012 @ Deb & Ian's dooryard
#4
I have no experience handling dbus, but this may help to debug it.

No leak in my case:
Code:
date >> dbus.log; ps avx | grep dbus-daemon >> dbus.log
Code:
Thu Aug  9 05:11:07 CEST 2012
 1198 messageb  3380 S <  /usr/bin/dbus-daemon --system --nofork 
 1559 user      3008 S <  /usr/bin/dbus-daemon --fork --print-pid 5 --print-add
 2205 user      2092 S    grep dbus-daemon 
Thu Aug  9 05:15:17 CEST 2012
 1198 messageb  3380 S <  /usr/bin/dbus-daemon --system --nofork 
 1559 user      3008 S <  /usr/bin/dbus-daemon --fork --print-pid 5 --print-add
 2209 user      2092 S    grep dbus-daemon 
Thu Aug  9 11:56:09 CEST 2012
 1198 messageb  3380 S <  /usr/bin/dbus-daemon --system --nofork 
 1559 user      3008 S <  /usr/bin/dbus-daemon --fork --print-pid 5 --print-add
 2213 user      2092 S    grep dbus-daemon 
Thu Aug  9 13:21:36 CEST 2012
 1198 messageb  3380 S <  /usr/bin/dbus-daemon --system --nofork 
 1559 user      3008 S <  /usr/bin/dbus-daemon --fork --print-pid 5 --print-add
 2217 user      2092 S    grep dbus-daemon 
Thu Aug  9 13:53:17 CEST 2012
 1198 messageb  3380 S <  /usr/bin/dbus-daemon --system --nofork 
 1559 user      3008 S <  /usr/bin/dbus-daemon --fork --print-pid 5 --print-add
 2220 user      2092 S    grep dbus-daemon
 

The Following User Says Thank You to conred For This Useful Post:
Posts: 1,808 | Thanked: 4,272 times | Joined on Feb 2011 @ Germany
#5
uptime 18+ days

dbus-daemon (session): 3160K
dbus-daemon (system): 3556K

I wouldn't call that a leak (at least in my case).
 

The Following User Says Thank You to reinob For This Useful Post:
int_ua's Avatar
Posts: 676 | Thanked: 1,067 times | Joined on Jul 2010 @ Kyiv, Ukraine
#6
So I started deleting all suspicious packages one by one and it looks like it was recaller's fault. Memory stays at 3552K for ~10 hours.
 

The Following 2 Users Say Thank You to int_ua For This Useful Post:
int_ua's Avatar
Posts: 676 | Thanked: 1,067 times | Joined on Jul 2010 @ Kyiv, Ukraine
#7
Actually it stopped only after removing batterypatch-non-kp
 

The Following User Says Thank You to int_ua For This Useful Post:
Posts: 1,163 | Thanked: 1,873 times | Joined on Feb 2011 @ The Netherlands
#8
Another example of how great these "patches" are :P
__________________
N900 loaded with:
CSSU-T (Thumb)
720p recording,
Pierogi, Lanterne, Cooktimer, Frogatto
N9 16GB loaded with:
Kernel-Plus
--
[TCPdump & libpcap | ngrep]
--
donate
 

The Following 3 Users Say Thank You to mr_pingu For This Useful Post:
Posts: 1,808 | Thanked: 4,272 times | Joined on Feb 2011 @ Germany
#9
Originally Posted by mr_pingu View Post
Another example of how great these "patches" are :P
Indeed. But it seems to be even too much for batterypatch.

Batterypatch uses dbus-scripts, which could (maybe) responsible for the leak.

The scripts run by batterypatch, which are invoked by dbus-scripts, also execute dbus commands (to know whether a call is active or not).

So perhaps this provoke-dbus-event while handle-dbus-event may trigger a bug in dbus itself. (Maybe, this is not really a re-entrancy issue, and in any case one must assume that dbus, however crappy it is, and it is, has to be re-entrant, otherwise it would be just way too crappy).

Is somebody using frequently-run dbus-activated scripts *and* also having this memory leak?

If so, is this using dbus-scripts, dbuscron, or some other means?
 

The Following 2 Users Say Thank You to reinob For This Useful Post:
Reply


 
Forum Jump


All times are GMT. The time now is 15:52.