=== buxy_bak is now known as buxy | ||
=== catbus1 is now known as catbus1-afk | ||
YokoZar | Is there a dpkg-source --clean type command? | 01:07 |
---|---|---|
mwhudson | does anyone have any tips for how to manage distro patches for gcc without going crazy? | 01:53 |
mwhudson | i've tried gbp pq a bit but it fails for reasons i don't understand | 01:58 |
mwhudson | oh, i think i see why it failed for me | 02:22 |
cjwatson | tokolike debuild clean? | 03:16 |
cjwatson | err | 03:16 |
cjwatson | YokoZar: like debuild clean? | 03:17 |
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:20 |
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:21 |
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 | 03:22 |
=== _salem` is now known as _salem | ||
pitti | Good morning | 04:40 |
pitti | stgraber: ack; I filed bug 1361964 | 04:45 |
ubottu | bug 1361964 in calibre (Ubuntu) "FFE: Port to Qt5" [Undecided,New] https://launchpad.net/bugs/1361964 | 04:45 |
=== _morphis is now known as morphis | ||
=== asac` is now known as asac | ||
dholbach | good morning | 06:45 |
LocutusOfBorg1 | cjwatson, can you please unblock insighttoolkit4? it should just be three "no change rebuild" away :) | 06:54 |
LocutusOfBorg1 | hi dholbach :) | 06:54 |
dholbach | hi LocutusOfBorg1 | 06:55 |
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 ;) | 06:59 |
dholbach | ivoks, happy birthday! :) | 07:09 |
=== dbarth__ is now known as dbarth | ||
ivoks | dholbach: :) thanks | 07:21 |
cjwatson | LocutusOfBorg1: not after midnight, find another victim :) | 07:27 |
cjwatson | LocutusOfBorg1: err, in any case, insighttoolkit4 isn't blocked | 07:30 |
LocutusOfBorg1 | cjwatson, no problem ;) | 07:49 |
LocutusOfBorg1 | have a nice day :D | 07:50 |
=== inaddy is now known as tinoco | ||
=== henrix_ is now known as henrix | ||
=== ValicekB_ is now known as ValicekB | ||
LocutusOfBorg1 | how can I ask something to ubuntu-security people? | 08:19 |
LocutusOfBorg1 | I'm wondering about CVE-2014-5119 | 08:19 |
ubottu | ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-5119) | 08:19 |
infinity | LocutusOfBorg1: I'll be uploading to utopic for that tomorrow, and we'll get it sorted in stables soon. | 08:53 |
=== ikonia_ is now known as ikonia | ||
=== Riddelll is now known as Riddell | ||
=== soren_ is now known as soren | ||
LocutusOfBorg1 | thanks infinity :) | 09:35 |
=== timrc is now known as timrc-afk | ||
darkxst | pitti, is it possible to cache packages when using adt-run? | 10:21 |
=== marcustomlinson is now known as marcustomlinson| | ||
=== marcustomlinson| is now known as marcustomlinson | ||
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:21 |
pitti | yes, otherwise you'll go crazy | 10:22 |
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:23 |
darkxst | pitti, could be ;) I never used to care when I had a 100Mbps internet connection, but now suffering slow adsl | 10:26 |
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:27 |
pitti | darkxst: schroot doesn't cache by default | 10:29 |
pitti | (i. e. sbuild) | 10:30 |
darkxst | pitti, it does here, though like I said, probably had to tweak config for that | 10:31 |
pitti | *nod* | 10:31 |
darkxst | and with cached packages and eatmydata, sbuild is incredibly fast | 10:32 |
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:34 | |
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:35 |
tjaalton | sure is :) | 10:36 |
tjaalton | my first ssd broke after a year, the warranty replacement has been going for nearly 2y now.. | 10:36 |
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:37 |
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:38 |
pitti | jtaylor: ah nice, like a bind mount with degraded data integrity guarantees? | 10:39 |
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:40 |
jtaylor | lvm makes it easy to have special purpose partitions, but you could use real partitions too | 10:41 |
=== timrc-afk is now known as timrc | ||
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:06 |
darkxst | pitti, ok, will take a look tomorrow ;) | 11:10 |
=== MacSlow is now known as MacSlow|lunch | ||
=== Sweetsha1k is now known as Sweetshark | ||
=== superm1_ is now known as superm1 | ||
=== _salem is now known as salem_ | ||
=== MacSlow|lunch is now known as MacSlow | ||
=== NComman`` is now known as NCommander | ||
=== NCommander is now known as Guest81462 | ||
=== Pici` is now known as Pici | ||
=== smoser` is now known as smoser | ||
LocutusOfBorg1 | sil2100, can you please remove lucene++ from mentors? | 12:44 |
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? | 12:45 |
=== Guest81462 is now known as NCommander | ||
=== salem_ is now known as _salem | ||
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:11 |
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:13 |
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:14 |
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:15 |
tedg | hallyn, I think he might have ended up chasing something different. | 13:17 |
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:18 |
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:19 |
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:20 |
ogra_ | hallyn, hmm | 13:21 |
ogra_ | i wonder if one steps on the toes of the other then | 13:21 |
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:23 |
hallyn | tedg: /etc/default/cgmanager -> "cgmanager_opts="--debug"". jodh was doing that plus extra debugging with a custom patch | 13:24 |
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:25 |
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:26 |
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:27 |
tedg | So there's no other group for the app | 13:28 |
=== _salem is now known as salem_ | ||
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:30 |
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:31 |
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:32 |
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:34 |
tedg | hallyn, http://pastebin.ubuntu.com/8159489/ | 13:35 |
wgrant | pitti: Yep, that's the place. Just worked out the last ubuntu<->ubuntu-rtm sharing issue today. | 13:37 |
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:38 |
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:39 |
hallyn | tedg: is that 'Yes, it's always a different set of tasks' ? | 13:41 |
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:42 |
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:43 |
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:44 |
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:45 |
hallyn | ok i think i will add some nih_traces to cgmanager to help us debug there | 13:47 |
hallyn | tedg: pushing a new cgmanager (0.30-1ubuntu2) would like to see the /var/log/upstart/cgmanager.log with that pkg | 13:56 |
tedg | hallyn, Cool, I have a run going with the --debug flag I'll grab that package when it's up. | 13:57 |
tedg | hallyn, Hmm, I must have screwed that up, I got no cgmanager log this time. http://pastebin.ubuntu.com/8159755/ | 14:06 |
hallyn | tedg: /var/log/upstart/cgmanager.log doesn't exist? you've done 'stop cgmanager; start cgmanager' ? | 14:13 |
tedg | hallyn, Well, I rebooted. | 14:14 |
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:15 |
hallyn | those are fine. returning 0 means it worked | 14:16 |
tedg | K | 14:17 |
=== Mikee_C is now known as Mikee_C_afk | ||
=== Mikee_C_afk is now known as Mikee_C | ||
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:47 |
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:48 |
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:49 |
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 | 14:51 |
=== mbarnett` is now known as mbarnett | ||
ubuntu-baltix | Hi devs :) | 15:05 |
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:25 |
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:26 |
ubottu | bug 1308895 in usb-modeswitch (Ubuntu) "Please merge usb-modeswitch from Debian unstable - Huawei E3531 does not automatically switches to modem mode (no udev rules for this modem in Ubuntu's /lib/udev/rules.d)" [Medium,Confirmed] https://launchpad.net/bugs/1308895 | 15:26 |
ubottu | bug 1192297 in usb-modeswitch-data (Baltix) "Huawei E3131 mobile modem not recognized" [Medium,Confirmed] https://launchpad.net/bugs/1192297 | 15:26 |
oSoMoN | Saviq, my what? since when am I sending HTML emails? | 15:29 |
oSoMoN | that would be a terrible heresy | 15:30 |
Saviq | oSoMoN, I got https://lists.launchpad.net/ubuntu-phone/msg09661.html in HTML | 15:31 |
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:32 |
Saviq | oSoMoN, like we all are, no worries :) | 15:33 |
ubuntu-baltix | also for example bug #1328412 | 15:36 |
ubottu | bug 1328412 in usb-modeswitch-data (Ubuntu) "Huawei E398 GSM modem configuration data not included" [Undecided,Confirmed] https://launchpad.net/bugs/1328412 | 15:36 |
=== rww_ is now known as rww | ||
=== Zic_ is now known as Zic | ||
shadeslayer | anyone have a idea how autologin configs get written from ubiquity? | 17:38 |
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:57 |
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:58 |
shadeslayer | ( FYI that snippet is from ubiquity ) | 17:59 |
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:01 |
shadeslayer | ah | 18:02 |
shadeslayer | cheerio | 18:02 |
shadeslayer | apachelogger: huh, grepping from bzr doesn't give me anything | 18:03 |
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:04 |
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:05 |
shadeslayer | yeah I guess | 18:06 |
shadeslayer | anyway, will fix it tomorrow | 18:09 |
tedg | hallyn, Here's the cgmanager log, don't see anything obvious, looking for which apps failed now: http://paste.ubuntu.com/8161530/ | 18:21 |
tedg | hallyn, It looks like the group is getting removed and then someone is looking for it? | 18:23 |
tedg | hallyn, Seems like normally it's "created/moved/removed" but there are cases of "created/removed/invalid path" | 18:25 |
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:27 |
=== kirkland` is now known as kirkland | ||
=== kirkland is now known as Guest82850 | ||
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:28 |
hallyn | no, it has to become empty | 18:29 |
hallyn | there has to be a task, which is moved out or exits, | 18:30 |
hallyn | then the cgroup is autoremoved | 18:30 |
=== Guest82850 is now known as kirkland` | ||
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:30 |
* tedg searched for "fail" first too :-) | 18:31 | |
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:32 |
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:33 |
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:34 |
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:35 |
hallyn | upstart never calls cgmanager_remove_sync. | 18:39 |
hallyn | is there a way you can have application-legacy be straced? | 18:40 |
tedg | Uhm, I can strace the binary, but last time it looked like our binary wasn't even getting called. | 18:43 |
tedg | Like it stopped before execing to us. | 18:44 |
tedg | Wait, I'm looking at the one "tmpN5uJfu" and it seems like it's getting created twice. | 18:45 |
tedg | Wondering if we're getting duplication in the tmp file generator. | 18:46 |
tedg | No, because the timestamps are the same. | 18:46 |
tedg | Looks like it gets created 3 times, removed once. | 18:47 |
hallyn | and why is it getting creatd 3 time? | 18:47 |
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:48 |
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:49 |
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:50 |
=== roadmr is now known as roadmr_afk | ||
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:52 |
hallyn | (I'm assuming) | 18:53 |
hallyn | I'd forgotten it actually goes through dbus to cgmanager as well | 18:53 |
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:54 |
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:55 |
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:56 |
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:57 |
hallyn | (and maybe when i look at the upstart source it'll be obvious how to do the proper fix myself) | 18:58 |
=== plars_ is now known as plars | ||
=== Mikee_C is now known as Mikee_C_afk | ||
hallyn | seems like just doing it at job_process_terminated() should suffice | 20:22 |
hallyn | hm, upstart is source v 1.0. that's nerve-wracking | 20:24 |
=== roadmr_afk is now known as roadmr | ||
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:56 |
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:58 |
hallyn | but sometimes the autoremove happens after the last create, but before the exec | 20:59 |
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:00 |
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:28 |
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:29 |
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:35 |
hallyn | oh, nm | 21:36 |
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:45 |
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:46 |
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:47 |
hallyn | or, cgmanager should perhaps offer a 'RemoveAndKill' method | 21:48 |
hallyn | and upstart should then use that | 21:48 |
=== salem_ is now known as _salem | ||
=== asac` is now known as asac | ||
hallyn | tedg: incroyable! my patch seems to work | 22:50 |
hallyn | pre-start is in /xxx_2, script in /xxx_0, post-stop, well, hasn't started yet | 22:51 |
hallyn | (xxx_4) | 22:51 |
hallyn | and after stop, cgroups are gone | 22:52 |
hallyn | it does multiply the cgroup setup being done, but i think that' sok | 22:52 |
hallyn | tedg: tossed the patch to jodh (in the form of a merge proposal against the wrong tree) | 23:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!