| === darkxst_ is now known as darkxst | ||
| === Quintasan_ is now known as Quintasan | ||
| pitti | Good morning | 04:22 |
|---|---|---|
| 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:24 |
| 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:25 |
| 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:26 |
| stgraber | pitti: so what do you end up with when you hit that race condition? | 04:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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 | 04:32 |
| === Yufei_ is now known as Yufei | ||
| pitti | the "systemd" controller is alright, so I guess there's some hidden cleanup or other thing which I'm missing | 04:33 |
| 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:16 |
| dholbach | good morning | 07:35 |
| 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:24 |
| mvo | pitti: no problem, it seems like "Reqires=runlevel2.target" is sufficient, but I double check now | 08:28 |
| mvo | pitti: hm, no "After=" it seems, but lets talk when you have time :) | 08:31 |
| didrocks | mvo: we don't run runlevel targets in ubuntu IIRC | 08:32 |
| didrocks | mvo: maybe I can give you some hand, do you strictly want it to be started after all sysv scripts ran? | 08:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| didrocks | nice, that works ;) | 08:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| didrocks | speaking of which… /me looks at making a apparmor real unit then | 08:47 |
| tkamppeter | mvo, hi | 08:48 |
| 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:49 |
| tkamppeter | mvo, I have forwarded an e-mail to you now. | 08:50 |
| 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:51 |
| mvo | ok | 08:52 |
| mvo | tkamppeter: I will reply to the mail, ok? | 08:52 |
| tkamppeter | OK. | 08:53 |
| 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:57 |
| pitti | mvo: yeah, better avoid "runlevel2" or such, it's a legacy notion | 08:58 |
| === zsombi_ is now known as zsombi | ||
| * hyperair wonders if anyone else has unity-settings-daemon taking up ~1GB of memory | 09:06 | |
| === LeonBo is now known as LBo | ||
| 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:25 |
| hyperair | do you have any idea what's wrong? | 09:26 |
| 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:28 |
| 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:29 | |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| cking | i sure make enough coding errors, that's why I shove all my code through static analysers like cppcheck etc | 09:35 |
| === vrruiz_ is now known as rvr | ||
| 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:10 |
| didrocks | (xdiagnose only worked with lightdm and gdm btw in the upstart job) | 11:13 |
| jamespage | @pilot in | 11:25 |
| === 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 | ||
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| didrocks | yeah, maybe there can be a case for this, seems quite unlikely though | 11:39 |
| === _salem is now known as salem_ | ||
| 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:41 |
| didrocks | mlankhorst: you touched it last, so maybe you have an opinion as well? ^ | 11:44 |
| 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:47 |
| didrocks | + fix the script to be systemd and all dms more friendly | 11:48 |
| mlankhorst | didrocks: not really, just don't break it :P | 11:50 |
| didrocks | mlankhorst: well, TBH, it's already broken if you don't have gdm installed :) | 11:51 |
| didrocks | but nothing unfixable | 11:52 |
| === 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 | ||
| jamespage | @pilot out | 14:44 |
| === 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 | a somewhat disrupted piloting session I'm afraid... | 14:45 |
| === roadmr is now known as roadmr_afk | ||
| 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:36 |
| 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:37 |
| infinity | mdeslaur: I'm not so good with CVEs without context. Expand on that in #security for me? | 15:38 |
| mdeslaur | infinity: do you plan a vivid upload with the wordexp fix? | 15:39 |
| infinity | mdeslaur: Yeahp. | 15:39 |
| mdeslaur | infinity: cool, thanks | 15:39 |
| 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:40 |
| 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:42 |
| 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 | 15:43 |
| === roadmr_afk is now known as roadmr | ||
| 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:47 |
| ricotz | pitti, yeah, systemd 217 :) | 15:50 |
| ricotz | pitti, is there a reason why you didnt pick up the stable-patch queue? | 15:51 |
| tkamppeter | pitti, could you help me with aptdaemon? | 16:15 |
| infinity | tkamppeter: You probably want mvo, not pitti. | 16:18 |
| 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:19 |
| infinity | Ahh. :) | 16:20 |
| tkamppeter | infinity, do you know about glatzor? He seems to be the original author. | 16:20 |
| infinity | tkamppeter: https://launchpad.net/~glatzor/+karma implies he hasn't been around much since June. | 16:22 |
| tkamppeter | infinity, thanks, so he has perhaps quit free software development. | 16:29 |
| 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:31 |
| shadeslayer | mvo: poke | 16:47 |
| shadeslayer | mvo: who should I talk to if I have questions about /run and systemd and the init process | 16:48 |
| balloons | ping mvo | 17:14 |
| === ddd is now known as Guest88731 | ||
| Guest88731 | catbus1: ping | 18:56 |
| mvo | balloons: pong | 20:45 |
| === roadmr is now known as roadmr_afk | ||
| === salem_ is now known as _salem | ||
| === roadmr_afk is now known as roadmr | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!