On Sat, Jan 11, 2014 at 12:00:45AM +0100, Michał Sawicz wrote: > On 10.01.2014 23:58, Steve Langasek wrote: > >Oh, ok - yes, dying with SIGSEGV after receiving SIGTERM from upstart would > >certainly trigger that behavior.
> >Is the SIGTERM being sent because the user session is exiting? If so, > >overriding the kill timeout may not be enough, because upstart will also > >hard-kill any lingering processes after a separate timeout in order to avoid > >being hard-killed/itself/ by lightdm and leaving spare processes behind. > In our case it's after `initctl stop unity8` when unity8 is > restarted between tests. Ok. I don't see any reason that the kill timeout would be insufficient for this case. Tested in a user session with the attached python program and upstart job, and I get the expected results in ~/.cache/upstart/kill-test.log. Maybe the kill timeout isn't high enough for apport to finish processing the unity8 core. Is this reproducible if you raise the timeout higher than 30 sec? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
kill timeout 30 exec /home/vorlon/bin/kill-me
#!/usr/bin/python3
import os, sys, time, datetime, signal
def sigterm_handle(signum, frame):
global sigged
sigged = 1
print(datetime.datetime.now().isoformat(' ') + ": SIGTERM received.");
sigged = 0
signal.signal(signal.SIGTERM, sigterm_handle)
while True:
time.sleep(1)
if sigged:
print(datetime.datetime.now().isoformat(' ') + ": sleeping.");
signature.asc
Description: Digital signature
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
