I've tested on a mako device here, and the memory usage is not all due to a misbehaved client. I've tracked down all the clients of the session init; unity8 is the only long-lived client other than the bridges, and if I kill unity8 and let it respawn, upstart gains back some of the memory, but *not all*: if I feed events into the session init, bringing its memory usage up to 93.3MB, and then kill unity8 (and, in fact,if I go through one-by-one and kill *all* the processes related to the session), upstart frees *some* memory, but its total usage remains at 88MB - compared to 5MB when it starts out.
Another thing I've found out, though, is that if I force a re-exec of the session init with 'telinit u', the memory usage drops down... and never rises again, even if I spam it with more events. This suggests a possible workaround of just re-execing the session init immediately after startup. But that probably requires landing a fix for bug #1238078 first. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1235649 Title: uevent spam causes libdbus client code in session upstart to consume massive amounts of memory on Ubuntu Touch To manage notifications about this bug go to: https://bugs.launchpad.net/upstart/+bug/1235649/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
