=== darkxst_ is now known as darkxst
=== Quintasan_ is now known as Quintasan
[04:22] <pitti> Good morning
[04:24] <pitti> stgraber: so current systemd in vivid works reasonably well with per-session containers if you log in through the VT or ssh, but not in lightdm sessions; there is some kind of weird race condition there which I've tried tracking down for like 3 days now
[04:25] <pitti> stgraber: but at least for those ssh/VT logins you should be in the user-XXXX.slice cgroups in all controllers and user containers should work
[04:25] <stgraber> pitti: go back to bed! :)
[04:26] <pitti> stgraber: heh, couldn't sleep any more after my wife got up
[04:26] <pitti> and so much to do
[04:26] <stgraber> :)
[04:26] <stgraber> usually I take you saying good morning as a sign that I should really be sleeping but every so often you're just up way too early :)
[04:27] <stgraber> pitti: so what do you end up with when you hit that race condition?
[04:28] <pitti> stgraber: sometimes processes propagate up to user.slice, sometimes all the way to /
[04:28] <pitti> stgraber: I added all kinds of debugging cgroups ops (http://paste.ubuntu.com/9278143/), and I see that the lightdm session-child gets correctly placed into all controllers, and cgroups are created
[04:29] <pitti> but then they somehow disappear from those groups
[04:29] <pitti> and nothing in the systemd logs (i. e. the cgroups ops) tell me why
[04:29] <stgraber> that's pretty scary
[04:30] <pitti> I disabled cgroups trimming (that seems to work fine, but with that I can see that the empty cgroups are still there), and logged all migrations
[04:30] <pitti> so somewhere in the chain of operations there's something which I don't understand which triggers a race condition
[04:30] <stgraber> because if that happens after the unprivileged process was spawned, then it means that there may be a way for someone to escape their cgroup through some systemd weirdness...
[04:31] <stgraber> hmm, so you suspect the cgroup becomes empty briefly and gets destroyed by systemd or something like that?
[04:31] <pitti> stgraber: well, that can't "just happen", can it? once lightdm-session-child is in e. g. memory:/user.slice/user-1000.slice, it shouldn't "just" go away
[04:32] <stgraber> you could try to unset the release_agent for all the cgroups and see if things then look reasonable, if so, then it'd indicate that the cgroup somehow got empty and triggered the release_agent (systemd's hook)
[04:32] <pitti> at least that initial lightdm process is still running after all
[04:32] <stgraber> yeah, it shouldn't be possible
[04:32] <pitti> stgraber: ah, good idea
[04:32] <pitti> stgraber: I thought I already disabled the release agent by commenting out the trimming, but I might have missed something
[04:32] <pitti> stgraber: anyway, I keep digging, just an intermediate status report
=== Yufei_ is now known as Yufei
[04:33] <pitti> the "systemd" controller is alright, so I guess there's some hidden cleanup or other thing which I'm missing
[07:16] <seb128> bdmurray, hey, we are supposed to have reports of unity-settings-daemon in vivid today (several users hitting a segfault with yesterday's update), any idea why that doesn't register on e.u.c?
[07:35] <dholbach> good morning
[08:24] <mvo> pitti: hey, good morning! do you happen to know what "[Install]\nWantedBy=.target" I need to put in a systemd unit file if I want to ensure its started after the sysv scripts got run?
[08:24] <pitti> mvo: in meeting, brb
[08:28] <mvo> pitti: no problem, it seems like "Reqires=runlevel2.target" is sufficient, but I double check now
[08:31] <mvo> pitti: hm, no "After=" it seems, but lets talk when you have time :)
[08:32] <didrocks> mvo: we don't run runlevel targets in ubuntu IIRC
[08:33] <didrocks> mvo: maybe I can give you some hand, do you strictly want it to be started after all sysv scripts ran?
[08:34] <mvo> didrocks: well, strictly after apparmor which is currently a sysv init script is run
[08:34] <mvo> didrocks: its run early in rcS so maybe its already good, but I would prefer to be explicit about it and don't take any chances
[08:35] <didrocks> mvo: yeah, better to be explicit, you are raising an interesting question actually, I wonder if you can depend on generated units
[08:35] <didrocks> mvo: let me have a try
[08:35] <mvo> ta
[08:36] <didrocks> mvo: FYI, you are looking for sysinit.target, but let's see if you can depend explicitly on apparmor
[08:36] <didrocks> mvo: sorry, I meant multi-user.target
[08:39] <didrocks> nice, that works ;)
[08:40] <mvo> didrocks: so I add "After=multi-user.target"?
[08:40] <didrocks> mvo: so, you need multiple things, your service can't be socket-activated or have a hook started by apparmor?
[08:41] <mvo> didrocks: not socket activated, not problably no hook either, this is pretty generic
[08:41] <didrocks> mvo: tell me if I got you right:
[08:41] <didrocks> - it can only starts if apparmor started
[08:42] <didrocks> - it should go down if apparmor stops
[08:42] <mvo> didrocks: yes
[08:42] <didrocks> and it can't be started in parallel with apparmor?
[08:42] <mvo> didrocks: no, strictly after
[08:42] <didrocks> ah, can be started in // then?
[08:42] <mvo> what is "//" ?
[08:43] <didrocks> parallel :)
[08:43] <mvo> heh :)
[08:43] <mvo> well, it needs to run when apparmor is ready, not before, it needs to use the apparmor confinement
[08:43] <didrocks> ok
[08:43] <didrocks> mvo: so you need that: http://paste.ubuntu.com/9280190/
[08:44] <mvo> didrocks: cool, this works? very nice
[08:44] <didrocks> mvo: yeah ;)
[08:44] <mvo> didrocks: thanks a lot
[08:44] <didrocks> yw :)
[08:44] <didrocks> for reference:
[08:44] <didrocks> After -> ensure it's running only after service A (can't be started before)
[08:45] <didrocks> Requires -> if A requires B, stopping B will stop A (stronger than wants), starting A will start B, but they will both starts in parallel
[08:45] <didrocks> (hence the After)
[08:45] <didrocks> but nothing asks your service to starts
[08:45] <didrocks> so WantedBy=multi-user.target
[08:45] <didrocks> then you systemctl enable <your-service>
[08:46] <didrocks> (after a systemctl daemon-reload if you just changed your .service file)
[08:46] <mvo> cool
[08:46] <mvo> thanks again
[08:46] <didrocks> yw
[08:47] <didrocks> speaking of which… /me looks at making a apparmor real unit then
[08:48] <tkamppeter> mvo, hi
[08:49] <mvo> hi tkamppeter
[08:49] <tkamppeter> mvo, I have seen you have sometimes uploaded aptdaemon, can you help me with some problem with it?
[08:49] <mvo> tkamppeter: maybe, unfortunately I'm super busy but I can have a look
[08:50] <tkamppeter> mvo, I have forwarded an e-mail to you now.
[08:51] <tkamppeter> mvo, I want to add a package repo with a given source.list line ("deb ....") which works on trusty but fails on Utopic+.
[08:52] <mvo> ok
[08:52] <mvo> tkamppeter: I will reply to the mail, ok?
[08:53] <tkamppeter> OK.
[08:57] <pitti> mvo: right, WantedBy= is just which target pulls it in; ordering is Before=/After=, so I think I'd just use After=multi-user.target
[08:57] <mvo> pitti: yeah, thanks
[08:58] <pitti> mvo: yeah, better avoid "runlevel2" or such, it's a legacy notion
=== zsombi_ is now known as zsombi
[09:06]  * hyperair wonders if anyone else has unity-settings-daemon taking up ~1GB of memory
=== LeonBo is now known as LBo
[09:25] <apw> hyperair, you have one which works, you are pretty lucky
[09:25] <hyperair> apw: eh?
[09:25] <apw> hyperair, mine is exploding every 20s and making my screen jump
[09:25] <hyperair> urgh
[09:25] <hyperair> that sounds terrible
[09:25] <apw> i am starting to feel a bit sick yes
[09:26] <hyperair> do you have any idea what's wrong?
[09:28] <cking> hyperair, https://launchpadlibrarian.net/191396414/upstart.unity-settings-daemon.log.txt
[09:28] <apw> hyperair, Laney seems to be on the case
[09:28] <hyperair> ah, i see.
[09:29] <hyperair> looks upower related
[09:29] <apw> well i am interpreting his "everyone is telling me" to mean that
[09:29] <pitti> apw: just downgrade to the previous version
[09:29]  * pitti did that this morning
[09:30] <apw> pitti, yeah will do, when i can get a copy, but i want to know how something which dumps with SIGABRT got past CI
[09:30] <pitti> we have no CI for u-s-d
[09:31] <seb128> apw, Laney tested on a desktop and the issue seems to happen only if you have a battery
[09:31] <apw> seb128, yeah but we have CI which tests on real things ... right
[09:31] <pitti> apw: only for touch :)
[09:32] <cking> like most users are on battery powered devices nowadays ;-)
[09:32] <apw> seb128, and can i just say ... we tested a power related change on something which doesn't have power related things in it .. erm
[09:32] <apw> pitti, well that is a fail and no mistake
[09:32] <ogra_> and on touch only after the fact ...
[09:32] <ogra_> (once an app is in the image)
[09:32] <pitti> apw: oh for sure, I'm just saying that we don't have automatic tests for that
[09:33] <seb128> apw, the power plugin doesn't only do that, it handles screen blanking, suspend, etc
[09:33] <cking> and i thought we were coverity scanning this code - I guess that's not happening now to catch this kind of bugs
[09:34] <Laney> yeah great Laney is a failure, good work
[09:34] <apw> Laney, Laney isn't a fail, the automated testing which approved the change is a fail
[09:34] <apw> i am sure we make more than our fair share of errors in the kernel
[09:35] <cking> i sure make enough coding errors, that's why I shove all my code through static analysers like cppcheck etc
=== vrruiz_ is now known as rvr
[11:10] <didrocks> pitti: I'm looking at xdiagnose upstart job, what do you think for systemd to have graphical.target Requires a dm instead of wants, creating a graphical-failsafe.target and OnFailure=graphical-failsafe.target?
[11:13] <didrocks> (xdiagnose only worked with lightdm and gdm btw in the upstart job)
[11:25] <jamespage> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jamespage
[11:32] <didrocks> pitti: hum, it seems that xfailsafe is already not working with upstart anyway…
[11:32] <didrocks> (if you installed another dm in addition to the "failing one")
[11:33] <pitti> didrocks: you're unstoppable :)
[11:33] <pitti> didrocks: i. e. this only runs if lightdm actually fails to load, not if it succeeds and shows garbage, ok
[11:33] <pitti> didrocks: ah, so you want to bind this on failure of graphical.target?
[11:33] <pitti> didrocks: yeah, not sure why it's just a wants; presumably to avoid degraded mode if you uninstall or disable all WMs
[11:33] <pitti> err, DMs
[11:33] <pitti> didrocks: got disconnected, replaying
[11:34] <pitti> didrocks: you're unstoppable :)
[11:34] <pitti> didrocks: i. e. this only runs if lightdm actually fails to load, not if it succeeds and shows garbage, ok
[11:34] <pitti> didrocks: ah, so you want to bind this on failure of graphical.target?
[11:34] <pitti> didrocks: yeah, not sure why it's just a wants; presumably to avoid degraded mode if you uninstall or disable all WMs
[11:34] <pitti> err, DMs
[11:34] <pitti> didrocks: so why can't we bind that directly to display-manager.service instead of graphical.target (which might have other and unrelated things included)?
[11:34] <didrocks> pitti: I'm unsure about the wants= only as well. (and yes, it's actually if the DM exit != 0)
[11:35] <didrocks> pitti: hum, you mean, dynamically removing display-manager.service symlinks and retarget it?
[11:35] <pitti> didrocks: no, I mean start up failsafe if display-manager.service fails, not graphical.target
[11:36] <didrocks> I wonder if we have a case nowdays of graphical.target without dm (knowing that lightdm can run now without a greeter)
[11:36] <didrocks> pitti: it means we need to replace the Alias by an unit copy
[11:36] <didrocks> or have all DMs having OnFailure=
[11:36] <didrocks> which was my other option :)
[11:37] <pitti> didrocks: ah, we can't put alias names into dependencies?
[11:37] <didrocks> I just wonder if graphical.target succeeding without a DM makes sense
[11:37] <pitti> didrocks: is there a "reverse" OnFailure?
[11:37] <didrocks> pitti: hum, it's the other way around, right?
[11:37] <didrocks> I don't think so, let me check
[11:37] <didrocks> pitti: not in the man, at least
[11:38] <pitti> didrocks: and I meant that an admin might hook other things into graphical.target which may fail, but then we don't want the DM fallback
[11:38] <didrocks> you think other Requires=, not Wants, right?
[11:39] <didrocks> yeah, maybe there can be a case for this, seems quite unlikely though
=== _salem is now known as salem_
[11:41] <didrocks> waow, if we succeed being back from failsafe, it's running gdm (unconditionally)
[11:41] <didrocks> I wonder how much this xdiagnose is broken anyway and if we shouldn't just purge it until we have Mir supporting that
[11:44] <didrocks> mlankhorst: you touched it last, so maybe you have an opinion as well? ^
[11:47] <pitti> didrocks: yes
[11:47] <pitti> didrocks: but as this is a fallback for a DM, I think we should hook it into DM
[11:47] <pitti> didrocks: anyway, if Requires= makes things easier, we can also start with that
[11:47] <pitti> didrocks: you are thinking of adding OnFailure= to graphical.target?
[11:47] <didrocks> pitti: exactly, and create either an unit or a graphical-fallback target
[11:48] <didrocks> + fix the script to be systemd and all dms more friendly
[11:50] <mlankhorst> didrocks: not really, just don't break it :P
[11:51] <didrocks> mlankhorst: well, TBH, it's already broken if you don't have gdm installed :)
[11:52] <didrocks> but nothing unfixable
=== doko_ is now known as doko
=== MacSlow is now known as MacSlow|lunch
=== dholbach_ is now known as dholbac
=== dholbac is now known as dholbach
=== MacSlow|lunch is now known as MacSlow
=== tdc_ is now known as tdc
[14:44] <jamespage> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[14:45] <jamespage> a somewhat disrupted piloting session I'm afraid...
=== roadmr is now known as roadmr_afk
[15:36] <mdeslaur> infinity: so I'm looking at fixing CVE-2012-6656, CVE-2014-6040 and CVE-2014-7817...do you have a glibc update planned for vivid soon for CVE-2014-7817?
[15:36] <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-2012-6656)
[15:36] <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-6040)
[15:36] <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-7817)
[15:36] <mdeslaur> ubottu: !pastebin
[15:36] <ubottu> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imgur.com/ !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
[15:37] <mdeslaur> ubottu: I'm talking to you, stupid bot
[15:37] <ubottu> mdeslaur: I am only a bot, please don't think I'm intelligent :)
[15:38] <infinity> mdeslaur: I'm not so good with CVEs without context.  Expand on that in #security for me?
[15:39] <mdeslaur> infinity: do you plan a vivid upload with the wordexp fix?
[15:39] <infinity> mdeslaur: Yeahp.
[15:39] <mdeslaur> infinity: cool, thanks
[15:40] <infinity> mdeslaur: I'll pull and test Carlos's final commit either today or over the weekend.
[15:40] <mdeslaur> infinity: that would be a39208bd7fb76c1b01c127b4c61f9bfd915bfe7c ?
[15:42] <infinity> mdeslaur: 33ceaf6187b31ea15284ac65131749e1cb68d2ae on the 2.20 branch.  Let me verify you're right on trunk. :
[15:42] <mdeslaur> yeah, that's the same
[15:42] <infinity> Looks like.
[15:42] <mdeslaur> ok, just wanted to make sure, thanks
[15:43] <infinity> mdeslaur: CVE-2014-6040 has a patch in the Debian/sid source you can snag.
[15:43] <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-6040)
[15:43] <infinity> mdeslaur: It's not in vivid because the 2.19 branch update supersedes it.
[15:43] <mdeslaur> yeah, I already snagged it
=== roadmr_afk is now known as roadmr
[15:47] <infinity> I really should see if we have any CVE backports locall and commit them to the upstream branch.
[15:47] <infinity> Weekend "fun" I guess.
[15:50] <ricotz> pitti, yeah, systemd 217 :)
[15:51] <ricotz> pitti, is there a reason why you didnt pick up the stable-patch queue?
[16:15] <tkamppeter> pitti, could you help me with aptdaemon?
[16:18] <infinity> tkamppeter: You probably want mvo, not pitti.
[16:19] <tkamppeter> infinity, I asked mvo already, but it seems that he is too busy and so I tried also pitti, as he also did some uploads of aptdaemon.
[16:20] <infinity> Ahh. :)
[16:20] <tkamppeter> infinity, do you know about glatzor? He seems to be the original author.
[16:22] <infinity> tkamppeter: https://launchpad.net/~glatzor/+karma implies he hasn't been around much since June.
[16:29] <tkamppeter> infinity, thanks, so he has perhaps quit free software development.
[16:31] <tkamppeter> infinity, pitti, mvo, bug 1397374
[16:31] <ubottu> bug 1397374 in aptdaemon (Ubuntu) "Adding repository via PackageKit D-Bus interface does not work" [High,New] https://launchpad.net/bugs/1397374
[16:47] <shadeslayer> mvo: poke
[16:48] <shadeslayer> mvo: who should I talk to if I have questions about /run and systemd and the init process
[17:14] <balloons> ping mvo
=== ddd is now known as Guest88731
[18:56] <Guest88731> catbus1: ping
[20:45] <mvo> balloons: pong
=== roadmr is now known as roadmr_afk
=== salem_ is now known as _salem
=== roadmr_afk is now known as roadmr