[01:07] <YokoZar> Is there a dpkg-source --clean type command?
[01:53] <mwhudson> does anyone have any tips for how to manage distro patches for gcc without going crazy?
[01:58] <mwhudson> i've tried gbp pq a bit but it fails for reasons i don't understand
[02:22] <mwhudson> oh, i think i see why it failed for me
[03:16] <cjwatson> tokolike debuild clean?
[03:16] <cjwatson> err
[03:17] <cjwatson> YokoZar: like debuild clean?
[03:20] <YokoZar> cjwatson: I was more interested in a sort of revert type feature.  Basically a package's clean instructions weren't completely cleaning it so a second binary build was balking about having uncommitted changes to the source.
[03:21] <cjwatson> YokoZar: oh, well, use a version control system.
[03:21] <cjwatson> or re-unpack.
[03:21] <YokoZar> Yeah that's what I thought :p
[03:22] <YokoZar> Or maybe reverse apply the patch shown in the temp file
[03:22] <cjwatson> it's a bug if clean doesn't clean, of course.
[03:22] <YokoZar> Yeah, already filed that one :P
[04:40] <pitti> Good morning
[04:45] <pitti> stgraber: ack; I filed bug 1361964
[06:45] <dholbach> good morning
[06:54] <LocutusOfBorg1> cjwatson, can you please unblock insighttoolkit4? it should just be three "no change rebuild" away :)
[06:54] <LocutusOfBorg1> hi dholbach :)
[06:55] <dholbach> hi LocutusOfBorg1
[06:59] <LocutusOfBorg1> sil2100, did you ask to remove lucene++ from new queue?
[06:59] <LocutusOfBorg1> I got a strange mail, I would like to ask you prior to ask more informations ;)
[07:09] <dholbach> ivoks, happy birthday! :)
[07:21] <ivoks> dholbach: :) thanks
[07:27] <cjwatson> LocutusOfBorg1: not after midnight, find another victim :)
[07:30] <cjwatson> LocutusOfBorg1: err, in any case, insighttoolkit4 isn't blocked
[07:49] <LocutusOfBorg1> cjwatson, no problem ;)
[07:50] <LocutusOfBorg1> have a nice day :D
[08:19] <LocutusOfBorg1> how can I ask something to ubuntu-security people?
[08:19] <LocutusOfBorg1> I'm wondering about CVE-2014-5119
[08:53] <infinity> LocutusOfBorg1: I'll be uploading to utopic for that tomorrow, and we'll get it sorted in stables soon.
[09:35] <LocutusOfBorg1> thanks infinity :)
[10:21] <darkxst> pitti, is it possible to cache packages when using adt-run?
[10:21] <pitti> darkxst: I just use apt-cacher-ng on my workstation; mk-sbuild, adt-build-lxc, and adt-buildvm-ubuntu-cloud all detect and use that automatically
[10:22] <pitti> yes, otherwise you'll go crazy
[10:23] <darkxst> pitti, ok, will try that out
[10:23] <pitti> darkxst: curious, you are the second person today who asks me about that; perhaps it's time for a blog post :)
[10:26] <darkxst> pitti, could be ;) I never used to care when I had a 100Mbps internet connection, but now suffering slow adsl
[10:27] <pitti> darkxst: yeah, I'm just going to blog about it this afternoon, lest I'll explain it n times again :)
[10:27] <darkxst> and I guess I mostly use pbuilder and sbuild which do cache, but possibly I configured that
[10:29] <pitti> darkxst: schroot doesn't cache by default
[10:30] <pitti> (i. e. sbuild)
[10:31] <darkxst> pitti, it does here, though like I said, probably had to tweak config for that
[10:31] <pitti> *nod*
[10:32] <darkxst> and with cached packages and eatmydata, sbuild is incredibly fast
[10:34] <pitti> darkxst: I put all overlays (schroot, lxc, qemu) on /tmp which is on a tmpfs for me; even faster
[10:34]  * pitti will include that in the blog post
[10:35] <pitti> it's a bit ironic that first one buys an expensive 500 MB/s SSD and then puts quite some effort in not touching it by  keeping everything in RAM, but it's still worth it :)
[10:36] <tjaalton> sure is :)
[10:36] <tjaalton> my first ssd broke after a year, the warranty replacement has been going for nearly 2y now..
[10:37] <tjaalton> guess doing builds on tmpfs helps a bit
[10:37] <pitti> but seeing a schroot with 300 build deps download and unpack in 5 seconds is pretty neat
[10:37] <jtaylor> pitti: if you are writting a sbuild/pbuilder performance tip post, putting this in fstab /dev/mapper/lvm-chroot /srv/chroots ext4 data=writeback,commit=3600,nobarrier 0   1
[10:37] <pitti> yeah, /tmp is my cwd most of the time :)
[10:37] <jtaylor> is useful if you don't have enough ram to build large packages
[10:38] <jtaylor> (probably less important with ssd)
[10:38] <pitti> jtaylor: ah, that probably needs some more setup (LVM), though? I guess you should perhaps blog about this too
[10:38] <pitti> I have 16 GB, thus 8 GB tmpfs, I never ran into trouble so far
[10:38] <jtaylor> pitti: you can mount any partition you use as BUILDPLACE like that, though don't put important data on it :)
[10:38] <pitti> I'm not Sweetsha1k or the kernel team, of course :)
[10:39] <pitti> jtaylor: ah nice, like a bind mount with degraded data integrity guarantees?
[10:40] <pitti> not a bind mount, a proper mount
[10:40] <pitti> but one needs to set up the devmapper fist
[10:40] <pitti> first
[10:40] <jtaylor> yes its just a workspace partition which will likely get corrupted on stuff like powercuts
[10:40] <pitti> jtaylor: tell you what, I'll create a wiki page instead of a blog post; probably more useful
[10:41] <jtaylor> lvm makes it easy to have special purpose partitions, but you could use real partitions too
[11:06] <pitti> jtaylor, darkxst: I edited https://wiki.ubuntu.com/SimpleSbuild which already has most of the stuff
[11:06] <pitti> it uses /dev/shm/ which is always a tmpfs, and avoids mangling the symlinks in /var/lib/schroot/
[11:10] <darkxst> pitti, ok, will take a look tomorrow ;)
[12:44] <LocutusOfBorg1> sil2100, can you please remove lucene++ from mentors?
[12:45] <LocutusOfBorg1> I would like to upload again the -1 version
[12:45] <LocutusOfBorg1> and BTW how do you feel about maintaining under git in collab-maint?
[13:11] <tedg> stgraber, hallyn, so I ran the uitoolkit tests last night and we're still getting a 8% failure with cgroups enabled.
[13:11] <tedg> So I don't think the underlying bug is fixed.
[13:11] <tedg> What should I capture for a debug log?
[13:13] <ogra_> yeah, why would it be fixed ...
[13:13] <hallyn> capture the /var/log/upstart/cg{manager,proxy}.log and /proc/pid/cgroup of the login job;  but it also may be worth instrumenting systemd-shim
[13:13] <hallyn> ogra_: bc cgmanager should now always be running when the login job starts
[13:13] <ogra_> your change definitely didnt change the phone boot process
[13:14] <tedg> ogra_, We uploaded a new cgmanager package with a proposed fix.
[13:14] <ogra_> (as i said yesterday)
[13:14] <hallyn> can you post some bootcharts?
[13:14] <tedg> So I don't think this is a boot issue.
[13:14] <ogra_> not atm, i have non submitted code on all devices i could test on
[13:14] <tedg> Because in the same user session I'm getting ones that work and ones that don't.
[13:15] <ogra_> you can use phablet-bootchart from phablet-tools to generate a chart though
[13:15] <tedg> Specifically, over 288 application instances created about 8% aren't getting cgroups.
[13:15] <hallyn> tedg: huh.  that's not in keeping with info i'd gotten from jodh
[13:17] <tedg> hallyn, I think he might have ended up chasing something different.
[13:18] <tedg> hallyn, The only thing in cgmanger log is: cgmanager:per_ctrl_move_pid_main: Could not determine the requested cgroup
[13:18] <mapreri> pitti: <3 :)
[13:18] <pitti> mapreri: yw :)
[13:19] <tedg> hallyn, And I actually have that as many times as I have failure.
[13:19] <ogra_> tedg, hallyn, are we sure the old kernels we use on the phone have actually all features and functions in cgroups that we use ?
[13:19] <ogra_> dont forget we are using BSP kernls
[13:19] <mapreri> pitti: 7 minutes between the request and the sponsorship. You can mark it as a personal record :)
[13:20] <hallyn> they don't have all the features which is why both cgmanager and cgproxy have to run
[13:20] <pitti> mapreri: I think I've been faster with IRC requests, but thanks :)
[13:20] <mapreri> ^^
[13:21] <ogra_> hallyn, hmm
[13:21] <ogra_> i wonder if one steps on the toes of the other then
[13:23] <tedg> hallyn, So do you know what could cause that error?
[13:23] <tedg> hallyn, Is there a way to turn on more verbose debugging from cgmanager?
[13:24] <hallyn> tedg: /etc/default/cgmanager -> "cgmanager_opts="--debug"".  jodh was doing that plus extra debugging with a custom patch
[13:25] <hallyn> but at this point, i think what we need to know,
[13:25] <hallyn> is at your 8% failures, (1) what was the cgroup of the upstart job itself,
[13:25] <hallyn> (2) the upstart job contents, and (3) what was the cgroup of the launched app
[13:26] <hallyn> in the cases jodh was pursuing, the upstart job wasn't in a cgroup it controlled.  But that was because the whole login session in his cases were not in the right cgroup
[13:26] <hallyn> if it's 8% not getting the right cgroups, then you're hitting something different
[13:27] <hallyn> so last night my thinkpad sudenly went dark, wouldn't turn back on, and smelled of burning wire.  this morning it turns on.  but do i want it to....
[13:27] <tedg> hallyn, So we're creating an cgroup for the upstart job, so I'm not sure what you mean by "what was the cgroup of the upstart job itself" or "it's contents"
[13:27] <tedg> The app is then put into that created cgroup
[13:28] <tedg> So there's no other group for the app
[13:30] <pitti> wgrant: to confirm, RTM langpacks shoudl appear at https://translations.launchpad.net/ubuntu-rtm/14.09/+language-packs , right? (once this is set up)
[13:30] <hallyn> tedg: something forks the task which will become the user upstart job
[13:30] <ogra_> pitti, btw https://lists.ubuntu.com/archives/rtm-14.09-changes/2014-August/thread.html ... in case you want to subscribe
[13:31] <pitti> ogra_: ah, thanks; but after many years I actually managed to ween myself off reading -changes
[13:31] <ogra_> haha
[13:31] <pitti> (in some desperate attempt to reduce my ginormous email/IRC budget a bit)
[13:31] <pitti> "wean"
[13:31] <tedg> hallyn, Yes, upstart does that internally.
[13:32] <hallyn> tedg: and i want the cgroup at that point
[13:32] <ogra_> i still use these lists ... but 90% of the mail is just marked read
[13:32] <tedg> hallyn, Hmm, okay, perhaps stgraber knows how to get that.
[13:34] <hallyn> tedg: if there is simply a user-owned /sbin/init (and it is the one that will fork) then its cgroup will be fine
[13:34] <tedg> hallyn, Ah, okay, I can get that.
[13:35] <tedg> hallyn, http://pastebin.ubuntu.com/8159489/
[13:37] <wgrant> pitti: Yep, that's the place. Just worked out the last ubuntu<->ubuntu-rtm sharing issue today.
[13:38] <hallyn> tedg: yeah, but the question is is that somehow different when the 8% failing jobs start.
[13:38] <pitti> wgrant: awesome!
[13:38] <hallyn> is it always a different subset of jbos that fail?
[13:39] <tedg> hallyn, Yes, guessing it's a race of some kind. Specifically the UI Toolkit seems to show it the best which has a bunch of "applications" which are each tested for a couple seconds.
[13:41] <hallyn> tedg: is that 'Yes, it's always a different set of tasks' ?
[13:42] <tedg> hallyn, It's always the same job, but a different set of tests. All the applications are under the "application-legacy" job, but have an individual instance. Different sets of those instances fail each time.
[13:43] <tedg> hallyn, So the "application-legacy" job fails to start (like no logs, no nothing) 8% of the time.
[13:43] <hallyn> wait, fails to start at all, or fails to start int he right cgroup?
[13:43] <tedg> Fails to start at all
[13:44] <hallyn> sorry if we're talking in circles here - but do we know they are failing to start bc of cgroups not being set up?
[13:45] <tedg> No problem, we know that if we remove the cgroup directive of the Upstart job things work.
[13:45] <tedg> And we know that we get the error from cgmanager
[13:45] <tedg> (or I know, others may know more)
[13:47] <hallyn> ok i think i will add some nih_traces to cgmanager to help us debug there
[13:56] <hallyn> tedg: pushing a new cgmanager (0.30-1ubuntu2) would like to see the /var/log/upstart/cgmanager.log with that pkg
[13:57] <tedg> hallyn, Cool, I have a run going with the --debug flag I'll grab that package when it's up.
[14:06] <tedg> hallyn, Hmm, I must have screwed that up, I got no cgmanager log this time. http://pastebin.ubuntu.com/8159755/
[14:13] <hallyn> tedg: /var/log/upstart/cgmanager.log doesn't exist?  you've done 'stop cgmanager; start cgmanager' ?
[14:14] <tedg> hallyn, Well, I rebooted.
[14:15] <tedg> hallyn, But, yes, no log
[14:15] <tedg> hallyn, Looking in cgproxy log I see a couple odd messages "cgmanager_create: returning 0; existed is -1"
[14:15] <tedg> hallyn, Sometimes that's a "1" sometimes "-1"
[14:16] <hallyn> those are fine.  returning 0 means it worked
[14:17] <tedg> K
[14:47] <flexiondotorg> cjwatson, When I run ./update for my meta package I see the following in the logs '! Setting features {no-follow-recommends} for seed required'
[14:47] <flexiondotorg> What does that mean exactly and what action is required?
[14:48] <flexiondotorg> I've noticed that the installed system is not installing recommended package by default and suspect this message may trying to tel me something 😉
[14:48] <shadeslayer> flexiondotorg: it means that recommends of recommends are not added
[14:48] <shadeslayer> flexiondotorg: see man germinate
[14:49] <flexiondotorg> shadeslayer, Thanks.
[14:49]  * flexiondotorg goes reading
[14:49] <shadeslayer> ah hm
[14:49] <shadeslayer> no, just 1st level is off
[14:49] <shadeslayer> so recommends of a package in the seed are not added
[14:49] <shadeslayer> flexiondotorg: yw
[14:51] <flexiondotorg> shadeslayer, Why is no-follow-recommends being enabled. I have not set it in my seeds.
[14:51] <shadeslayer> possibly turned on by default?
[14:51] <shadeslayer> I never bothered investigating tbh
[15:05] <ubuntu-baltix> Hi devs :)
[15:25] <ubuntu-baltix> could someone merge usb-modeswitch from Debian unstable - currently usb-modeswitch from Ubuntu 14.10 and 14.04 doesn't work with latest usb-modeswitch-data releases and doesn't support lots of Huawei (and other) modems :(
[15:25] <Saviq> oSoMoN, I frown at your HTML emails :P
[15:26] <ubuntu-baltix> See bug #1308895 , bug #1192297 and other bugs at https://bugs.launchpad.net/ubuntu/+source/usb-modeswitch and https://bugs.launchpad.net/ubuntu/+source/usb-modeswitch-data
[15:29] <oSoMoN> Saviq, my what? since when am I sending HTML emails?
[15:30] <oSoMoN> that would be a terrible heresy
[15:31] <Saviq> oSoMoN, I got https://lists.launchpad.net/ubuntu-phone/msg09661.html in HTML
[15:32] <oSoMoN> Saviq, blame gmail then, I just replied inline using the web interface, as I always do
[15:32] <Saviq> and couldn't find your reply, because I frown at not cutting the irrelevant parts out ;)
[15:32] <Saviq> oSoMoN, I blame gmail for a lot of things, yeah :)
[15:32] <oSoMoN> Saviq, right, my bad for not removing irrelevant context, I’m in a rush…
[15:33] <Saviq> oSoMoN, like we all are, no worries :)
[15:36] <ubuntu-baltix> also for example bug #1328412
[17:38] <shadeslayer> anyone have a idea how autologin configs get written from ubiquity?
[17:57] <apachelogger> shadeslayer: casper?
[17:57] <apachelogger> I'd suppose that casper writes a lightdm autologin conf
[17:57] <shadeslayer> nope the option from the installer
[17:57] <shadeslayer> I've already put in sddm support in casper
[17:57] <apachelogger> yeah, that simply closes ubiquity-dm I suppose
[17:58] <apachelogger> ubiquity-dm unit stops -> proper DM starts -> find autologin logs in
[17:58] <shadeslayer> but in ubiquity you can do "Log in automatically"
[17:58] <apachelogger> ah that one
[17:58] <shadeslayer> yes
[17:58] <shadeslayer> that one :p
[17:58] <apachelogger> surely somewhere in ubiquity :P
[17:58] <shadeslayer> I found self.preseed_bool('passwd/auto-login', auto_login)
[17:58] <apachelogger> that's debconf though, isn't it
[17:58] <shadeslayer> right
[17:58] <shadeslayer> so what actually writes the config then
[17:59] <shadeslayer> ( FYI that snippet is from ubiquity )
[18:01] <apachelogger> user-setup? if that still is a thing
[18:01] <apachelogger> shadeslayer:
[18:01] <apachelogger> ./user-setup-apply:autologin-session=lightdm-autologin"
[18:01] <apachelogger> ./user-setup-apply:                                     sed -i "s/^\(\(str  *\)\?autologin-user\)=.*$/\1=$USER/g;" $ROOT/etc/lightdm/lightdm.conf
[18:02] <shadeslayer> ah
[18:02] <shadeslayer> cheerio
[18:03] <shadeslayer> apachelogger: huh, grepping from bzr doesn't give me anything
[18:04] <apachelogger> grepped from pkg
[18:04] <apachelogger> lp:~ubuntu-core-dev/user-setup/ubuntu says the control
[18:04] <shadeslayer> https://code.launchpad.net/~ubuntu-installer/user-setup/master says git
[18:05] <apachelogger> the cake is a lie!
[18:05] <shadeslayer> ^^ :p
[18:05] <apachelogger> shadeslayer: well, that's the import, since we use lightdm the coredev branch surely is our derivate of it ;)
[18:06] <shadeslayer> yeah I guess
[18:09] <shadeslayer> anyway, will fix it tomorrow
[18:21] <tedg> hallyn, Here's the cgmanager log, don't see anything obvious, looking for which apps failed now: http://paste.ubuntu.com/8161530/
[18:23] <tedg> hallyn, It looks like the group is getting removed and then someone is looking for it?
[18:25] <tedg> hallyn, Seems like normally it's "created/moved/removed" but there are cases of "created/removed/invalid path"
[18:27] <hallyn> tedg: the cgroup will be removed if it becomes completely empty.  could that be happening?
[18:27] <hallyn> (that is, no tasks in the cgroup and no sub-directories)
[18:28] <tedg> hallyn, Guessing it must because there's no move.
[18:28] <tedg> hallyn, So it's created, nothing is moved in, so it's empty.
[18:29] <hallyn> no, it has to become empty
[18:30] <hallyn> there has to be a task, which is moved out or exits,
[18:30] <hallyn> then the cgroup is autoremoved
[18:30] <hallyn> tedg: but that paste doesn't have any failures
[18:30] <hallyn> oh there' sone
[18:30] <tedg> hallyn, It has the "Invalid path"
[18:31]  * tedg searched for "fail" first too :-)
[18:32] <tedg> Hmm, looks like it's being removed before anything is moved into it.
[18:32] <hallyn> tedg: Removed /run/cgmanager/fs/freezer//user.slice/user-32011.slice/session-c1.scope/upstart/application-legacy-tmpa3LBk3-1409158710956199 for 9587 (0:0)
[18:32] <hallyn> yeah
[18:33] <hallyn> who's removing it
[18:33] <hallyn> mind you cgmanager won't actually remove it if tasks are in it,
[18:33] <tedg> 9587 :-)
[18:33] <hallyn> heh
[18:34] <tedg> It strikes me that it is PID+1
[18:34] <hallyn> suppose cgmanager could spit out /proc/pid/cmdline, but not sure that'd be meaningful
[18:34] <hallyn> so where/when does upstart remove it
[18:35] <hallyn> sigh, i'll probably be dropping in about 20 mins - bc my new hotspot's batt life is apparently < 2 hrs.  poc
[18:35] <hallyn> tedg: you're running stock utopic upstart?
[18:35] <tedg> Correct
[18:35] <tedg> 1.13.1-0ubuntu3
[18:39] <hallyn> upstart never calls cgmanager_remove_sync.
[18:40] <hallyn> is there a way you can have application-legacy be straced?
[18:43] <tedg> Uhm, I can strace the binary, but last time it looked like our binary wasn't even getting called.
[18:44] <tedg> Like it stopped before execing to us.
[18:45] <tedg> Wait, I'm looking at the one "tmpN5uJfu" and it seems like it's getting created twice.
[18:46] <tedg> Wondering if we're getting duplication in the tmp file generator.
[18:46] <tedg> No, because the timestamps are the same.
[18:47] <tedg> Looks like it gets created 3 times, removed once.
[18:47] <hallyn> and why is it getting creatd 3 time?
[18:48] <hallyn> shouldn't each one have a separate tmpnam?
[18:48] <tedg> In theory, but more so the timestamp should be incrementing.
[18:48] <hallyn> but my q is - is the pid which is asking for the removal showing up in the strace?  (i.e. is it part of the app somehow, or is it upstart)
[18:49] <tedg> Huh, so it looks like they're all created 3 times.
[18:49] <tedg> Guessing job, post-start, post-stop.
[18:49] <hallyn> heh makes sense
[18:49] <hallyn> can you pb the upstart job?
[18:49] <tedg> pb?
[18:49] <hallyn> pastebin
[18:50] <tedg> Ah, sure
[18:50] <hallyn> 12% battery remaining, will be lunchtime soon
[18:50] <hallyn> maybe time fo ran email to warthogs asking for best hotspot batt life
[18:50] <tedg> http://paste.ubuntu.com/8161783/
[18:52] <tedg> So It looks like the last create is the one that doesn't get moved in.
[18:52] <hallyn> tedg: oh.
[18:52] <hallyn> the remove is being done on behalf of cgm-release-agent
[18:53] <hallyn> (I'm assuming)
[18:53] <hallyn> I'd forgotten it actually goes through dbus to cgmanager as well
[18:54] <hallyn> so workarounds would include (a) an upstart job which sets notify-on-release to 0 for all mounted cgroups,
[18:54] <hallyn> (b) an option to cgmanager ot say don't remove on empty,
[18:54] <hallyn> (c) upstart simply not setting remove-on-empty
[18:54] <hallyn> having typed that, c seems most reasonable for now
[18:55] <tedg> Would it be bad if we had a lot of left over cgroups?
[18:55] <hallyn> so i think upstart should wait until post-stop is run (if any) before setting remove-on-empty, then attempt to remove by hand
[18:55] <hallyn> over time, yes
[18:55] <tedg> I mean we expect people to never reboot their phone.
[18:55] <hallyn> but i'm not saying never remove them
[18:55] <hallyn> i'm saying wait until we know the job is done before setting automreove
[18:55] <tedg> Ah, okay. That makes sense to me.
[18:56] <hallyn> as a short-term workaround, just remove the calls to cgmanager_remove_on_empty_sync()
[18:56] <hallyn> (in init/cgroup.c)
[18:56] <hallyn> then we should probably wait for jodh to get back for the proper fix
[18:56] <tedg> So, *I* can't do that.
[18:56] <tedg> :-)
[18:56] <tedg> stgraber, can you? ^
[18:56] <hallyn> well, we only want it on that phone for now right?
[18:56] <hallyn> or do we want it in all of utopic?
[18:57] <tedg> The goal is to not have a special build for phone.
[18:57] <hallyn> ok, my hotspot is about gone - i'll be back after lunch, sorry.
[18:57] <tedg> If we have to, I guess that's possible, but would prefer not to.
[18:57] <hallyn> SO disappointed
[18:57] <tedg> NP
[18:57] <hallyn> tedg: let's decide in like an hour
[18:57] <tedg> +1
[18:58] <hallyn> (and maybe when i look at the upstart source it'll be obvious how to do the proper fix myself)
[20:22] <hallyn> seems like just doing it at job_process_terminated() should suffice
[20:24] <hallyn> hm, upstart is source v 1.0.  that's nerve-wracking
[20:56] <tedg> hallyn, Does that run when all the job processes are done, or just the main one?
[20:56] <tedg> hallyn, It seems like in some cases it is the post-stop that's having issues.
[20:58] <hallyn> tedg: the reason it is having issues is that it runs after the job has exited, meaning the cgroup gets removed :)
[20:58] <hallyn> and the reason it's a race is that the post-stop *does* create the cgroup,
[20:59] <hallyn> but sometimes the autoremove happens after the last create, but before the exec
[21:00] <tedg> Yes, I see that, but I was worried that if you're setting the autoremove after the main job, then it'd be the same.
[21:00] <hallyn> right
[21:28] <hallyn> tedg: anothe rpossibility would be to ues a different cgroup name at post-stop
[21:28] <hallyn> but, lp:ubuntu/utopic/upstart/cgroup-race1 is the first guess
[21:29] <hallyn> hm, i'll create a tree with my second guess too.  then the ppl who actually know what they're doing can critize both
[21:35] <hallyn> i haz doubts on upstart init/cgroup.c:439
[21:35] <hallyn> it checks for cgname->expanded being NULL, but that's after having done a strcmp including it
[21:36] <hallyn> oh, nm
[21:45] <tedg> hallyn, So are you by chance at debconf?
[21:45] <hallyn> so lp:~serge-hallyn/ubuntu/utopic/upstart/cgroup-race2 would be the other way.  What are the odds that would actually work...
[21:45] <hallyn> tedg: nope
[21:45] <tedg> Would like to figure out the "final" solution between folks
[21:45] <tedg> Hmm, okay.
[21:46] <tedg> I'll put together an e-mail to see if we can grab those folks that are.
[21:46] <hallyn> tedg: I suspect the right answer will simply be removing for real (including killing any remaining jobs) at FINAL job state
[21:47] <hallyn> meanwhile though i'm going to build a package with cgroup-race2
[21:47] <tedg> hallyn, Honestly, that'd be cool as I'm doing that in the job currently "cgroup-reaper" but would love to have Upstart do it for me :-)
[21:47] <hallyn> tedg: yeah and it really should do that
[21:48] <hallyn> or, cgmanager should perhaps offer a 'RemoveAndKill' method
[21:48] <hallyn> and upstart should then use that
[22:50] <hallyn> tedg: incroyable!  my patch seems to work
[22:51] <hallyn> pre-start is in /xxx_2, script in /xxx_0, post-stop, well, hasn't started yet
[22:51] <hallyn> (xxx_4)
[22:52] <hallyn> and after stop, cgroups are gone
[22:52] <hallyn> it does multiply the cgroup setup being done, but i think that' sok
[23:03] <hallyn> tedg: tossed the patch to jodh (in the form of a merge proposal against the wrong tree)