| Mirv | could a core-dev ack the following packaging changes (the debian/ parts, others are just FYI)? https://ci-train.ubuntu.com/job/ubuntu-landing-004-1-build/129/artifact/ubuntu-ui-toolkit_packaging_changes.diff | 05:48 |
|---|---|---|
| Mirv | removing of python2 support from tests (and dependencies), plus switching to QT_SELECT=qt5 and therefore removing cruft from the dependencies | 05:49 |
| Mirv | oh, as a remark, it's not going at this moment to vivid archives, but targets w. but we treat the current overlay PPA as archive. | 05:50 |
| === ara is now known as Guest22932 | ||
| RAOF | Mirv: Looks sensible. | 06:36 |
| Mirv | thanks! | 06:37 |
| dholbach | good morning | 07:08 |
| pitti | Good morning | 08:07 |
| infinity | jamespage: Should nova-serialproxy be explicitly seeded, or dropped to universe? | 08:49 |
| didrocks | mvo: hey, stupid snappy question for you. So, if you have apps A depending on framework B, how can app A knows the path from the libs (or helpers) included in framework B? | 08:56 |
| pitti | didrocks: you don't really | 08:57 |
| davmor2 | seb128: so we still have the issue in vivid where you put something into the waste bin and then right click the icon in the launcher and empty the waste bin that is randomly opens a nautilus window | 08:58 |
| seb128 | davmor2, correct | 08:58 |
| didrocks | pitti: I guess we have misconceptions about frameworks, we read about the fact that it shouldn't contain libs | 08:58 |
| pitti | didrocks: right now frameworks can export binaries, but not libs | 08:58 |
| didrocks | so | 08:58 |
| didrocks | if I have a mir framework | 08:58 |
| pitti | didrocks: it should contain libs, but not export them | 08:58 |
| didrocks | how to run apps? | 08:58 |
| davmor2 | seb128: fair enough :) | 08:58 |
| pitti | didrocks: (and yes, I think that's wrong, but that's how it is right now) | 08:58 |
| didrocks | pitti: I guess all this was discussed in a desktop context, right? | 08:58 |
| pitti | didrocks: bundle everything | 08:58 |
| didrocks | so every apps contains Mir libs? | 08:59 |
| mvo | didrocks: you need to hardcode that right now, I think we will include a better mechanism for this but we are not there yet, sorry | 08:59 |
| pitti | yes, duplication is the future! | 08:59 |
| didrocks | mvo: seems like we have some requirements on the very short term to have a snappy desktop | 09:00 |
| didrocks | mvo: so, we are experimenting (and will have a list of requirements from you) | 09:00 |
| didrocks | mvo: is it better to send a long email with all our questions on the ML? | 09:00 |
| mvo | didrocks: eh, we release in 2 days, there is nothing new coming | 09:00 |
| didrocks | mvo: well, I guess this is for the incoming cycle :p | 09:01 |
| mvo | didrocks: i.e. if you need anything new it won't be based on 15.04, maybe 15.04.1 or something | 09:01 |
| didrocks | I hope at least | 09:01 |
| mvo | didrocks: aha, ok | 09:01 |
| mvo | didrocks: thats different :) | 09:01 |
| mvo | didrocks: I was shocked for a minute | 09:01 |
| mvo | didrocks: either way is fine, irc or mail | 09:01 |
| didrocks | mvo: no heart attack (yet) | 09:01 |
| didrocks | we will be able to panic tomorrow :p | 09:01 |
| didrocks | mvo: shouldn't we have a quick hangout (robert ancell, I and you) to unfog the first questions? | 09:02 |
| didrocks | not sure how much you thought about snappy in a dekstop context | 09:02 |
| didrocks | (we are sprinting this week) | 09:03 |
| didrocks | I guess we can draft an email, better for async thinking | 09:04 |
| mvo | didrocks: maybe send mail and then hangout? this way I get some to think about the questions and more people can jump in if needed? | 09:05 |
| didrocks | mvo: sounds good, robert and I will draft our thoughts | 09:07 |
| mvo | ta | 09:07 |
| addiks | hi, i am getting a segfault when running test for unity which prevents me from building unity packages. This happenes on the version i get from "apt-get source unity", and also the one from "bzr branch lp:unity". I am currently running a bisection, but i dont know if the information from that are usable because i neither have very much experience with bazaar nor with bisecting. I have a backtrace from GDB, it just does not make much se | 09:18 |
| addiks | nse to me. What should i do next? | 09:18 |
| infinity | jamespage: Also, please subscribe the server team to dns-root-data bugs, per bug #1426460 | 09:25 |
| ubottu | bug 1426460 in dns-root-data (Ubuntu) "[MIR] dns-root-data" [Undecided,New] https://launchpad.net/bugs/1426460 | 09:25 |
| jamespage | infinity, looking now | 09:25 |
| infinity | jamespage: To the bug sub, or the nova-thingee seed? :) | 09:26 |
| jamespage | both | 09:26 |
| infinity | jamespage: (But thanks in advance for both) | 09:26 |
| jamespage | bug sub done | 09:26 |
| jamespage | infinity, as nova-serialproxy is completely untested by my team, I'd prefer we demoted to universe for this cycle please | 09:29 |
| infinity | jamespage: Fair enough. | 09:30 |
| infinity | jamespage: Sounds kinda awesome, though, would be nice to test and support it in the future. | 09:31 |
| infinity | jamespage: Hint, hint. :) | 09:31 |
| jamespage | infinity, I agree | 09:31 |
| jamespage | on the list for +1 | 09:31 |
| infinity | jamespage: Also, a bug sub on ndg-httpsclient (a new dep of python-urllib3, which is already the server team's) would be swell. | 10:09 |
| jamespage | infinity, ok - doing so now | 10:09 |
| infinity | jamespage: \o/ | 10:09 |
| jamespage | infinity, done | 10:09 |
| tkamppeter | mterry, hi | 10:22 |
| === MacSlow is now known as MacSlow|lunch | ||
| rbasak | How should we package an upstream that requires -march=core2? | 11:44 |
| rbasak | They're using sse3.5-specific intrinsics. | 11:45 |
| strikov | rbasak: i found this for example: http://packages.ubuntu.com/trusty/radiance-sse3 | 11:46 |
| strikov | rbasak: the difference is that it's something like a plugin | 11:47 |
| larsu | tyhicks: hey! we're working on that gsettings confinemnet dameon. Where do we get the list of keys an app is allowed | 11:56 |
| larsu | to access? | 11:56 |
| === MacSlow|lunch is now known as MacSlow | ||
| === chrisccoulson_ is now known as chrisccoulson | ||
| === greyback__ is now known as greyback | ||
| === _salem is now known as salem_ | ||
| shadeslayer | cjwatson: what was the link where I could view cdimage logs? | 12:07 |
| shadeslayer | it was somewhere on this team https://launchpad.net/~ubuntu-cdimage/ | 12:07 |
| cjwatson | No it wasn't :-) | 12:08 |
| cjwatson | shadeslayer: http://people.canonical.com/~ubuntu-archive/cd-build-logs/ | 12:08 |
| shadeslayer | hm ok, I recall there being a launchpad page with the logs too | 12:08 |
| shadeslayer | cjwatson: on that note, is there a archive of ubuntu touch images somewhere | 12:09 |
| cjwatson | shadeslayer: Live filesystem build logs are stored on Launchpad, but right now it's easiest to find them from the above link. | 12:09 |
| shadeslayer | ok | 12:09 |
| cjwatson | shadeslayer: If an image isn't on cdimage.u.c or releases.u.c or old-releases.u.c any more, then in general it's gone. | 12:09 |
| shadeslayer | cjwatson: aw drat | 12:13 |
| shadeslayer | Riddell: ^^ | 12:13 |
| mterry | tkamppeter, hello! I left IRC on all night, wasn't around | 12:40 |
| hallyn_ | infinity: so we ran into a little bug in vivid in that ulimit for root on vivid says it can hav 64k files, but libc's __FD_SETSIZE is 1024 | 13:05 |
| hallyn_ | so when lxd opens an fd > 1024 and then tries to select on it, it gets a crash and 'buffer overflow' msg from FD_SET | 13:05 |
| hallyn_ | ok to push a glibc which bumps __FD_SETSIZE? | 13:06 |
| hallyn_ | doko_: ^ | 13:06 |
| hallyn_ | (sorry, biab) | 13:06 |
| rbasak | hallyn_: this reminds me of https://lists.ubuntu.com/archives/ubuntu-devel/2010-September/031446.html | 13:07 |
| rbasak | I get the impression it's non-trivial to change that. | 13:07 |
| doko_ | hallyn_, that would be better an infinity question | 13:08 |
| === doko_ is now known as doko | ||
| rbasak | hallyn_: the kernel defines __FD_SETSIZE so I don't think you can change it easily. | 13:15 |
| * rbasak wonders how the default nofile got bumped. | 13:16 | |
| rbasak | systemd switch perhaps? | 13:16 |
| infinity | hallyn_: No. | 13:35 |
| hallyn_ | infinity: ok, that's quite a problem. any daemon that takes a lot of connections is gonna end up crashing | 13:36 |
| hallyn_ | rbasak: heh, yup, looks like kees was on the ball there | 13:37 |
| rbasak | hallyn_: I wonder if we have an indavertent issue here though. From my brief look systemd is just passing on the kernel default. Is there something upstart was doing before to set the fd limit to 1024? | 13:38 |
| infinity | hallyn_: That statement is provably false. Perhaps you're after epoll? | 13:38 |
| rbasak | In which case, should we be doing the same, if we haven't rebuilt all packages against the new fortification stuff? | 13:38 |
| hallyn_ | infinity: what statement is provably false? | 13:38 |
| infinity | hallyn_: The daemons crashing. Oh, unless you mean ulimit has changed, and is now a lie... | 13:39 |
| hallyn_ | infinity: rharper is running large parallel tess against lxd, which golang (threaded) so all the threads share fdtable; so they pretty quickly get past 1024 fds. | 13:39 |
| hallyn_ | every crash i've seen was it opening a unix fd, trying to FD_SET it to select, and hitting the check in libc | 13:39 |
| rbasak | hallyn_: the right thing to do is to not use select in that case I think. | 13:40 |
| hallyn_ | "in that case" | 13:40 |
| hallyn_ | ^ that basically means, never use select | 13:40 |
| rbasak | If you want >1024 fds. | 13:40 |
| hallyn_ | no, i don't | 13:40 |
| hallyn_ | i'm liblxc, i just want to open a unix fd and select on it | 13:40 |
| infinity | hallyn_: Hrm, ulimit -n is indeed different on vivid than on trusty. That's irksome. | 13:40 |
| hallyn_ | rbasak: and i only have a single fd i care about. it happens to be > 1024. | 13:40 |
| rbasak | infinity: yeah, just verified that it's gone from 1024 to 65536 between Uoptic and Vivid. | 13:41 |
| rharper | I'm running on vivid | 13:41 |
| rbasak | infinity: looks like /etc/systemd/system.conf can configure the default, and that systemd uses the kernel default by default. | 13:41 |
| hallyn_ | now i agree part of the problem is golang's use of threads :) | 13:41 |
| rbasak | infinity: so is this an inadvertent change that we need to fix? | 13:42 |
| hallyn_ | bc if we drop the ulimit then we'll just get a different failure | 13:42 |
| rharper | hallyn_: that's a feature not a bug =) | 13:42 |
| rbasak | hallyn_: if you're selecting on just one fd, then surely you only need an fd_set size of 1? | 13:42 |
| infinity | rbasak: pitti and I are talking about it here. | 13:42 |
| hallyn_ | rharper: https://lists.ubuntu.com/archives/ubuntu-devel/2010-September/031446.html says no :) | 13:42 |
| rbasak | Oh, no that's stupid. | 13:42 |
| rbasak | If the fd could be greater than 1024, then you can't use select. | 13:42 |
| rharper | hallyn_: eww | 13:42 |
| rbasak | Use poll instead maybe? | 13:42 |
| hallyn_ | rbasak: every library in the archive would need to not use select | 13:42 |
| hallyn_ | ever | 13:43 |
| rbasak | hallyn_: correct. Which is why the file descriptor limit is (was) set to 1024 by default. | 13:43 |
| infinity | rbasak: epoll, even. | 13:43 |
| rbasak | select is fundamentally flawed for large number of file descriptors. | 13:43 |
| rbasak | A bit field passed through a system call is not going to scale. | 13:43 |
| hallyn_ | rbasak: but so https://lists.ubuntu.com/archives/ubuntu-devel/2010-September/031446.html doesn't tell me what bad things happen when we bump FD_SETSIZE in glibc | 13:44 |
| rharper | hallyn_: does that mean that on trusty we should be "ok" due to the upper limit ? it still seems strange; does go limit the number of threads it can create by FD limits ? | 13:44 |
| hallyn_ | and fwiw rharper and i are runnign with that now | 13:44 |
| infinity | hallyn_: So, yeah. There are two bugs here. (A) the ulimit defaulting to over 1024 is obviously wrong. But (B) if that's not working for your use case, this is 2015, epoll isn't exactly new and shiny. | 13:44 |
| hallyn_ | rharper: good q. maybe | 13:44 |
| hallyn_ | that would be almost smart | 13:44 |
| rharper | well, I don't think they should, a single thread could do lots of work on many FDs | 13:44 |
| hallyn_ | infinity: that liblxc code has been around since bfeore 2008 :) | 13:44 |
| hallyn_ | rharper: yeah, but i guess a "couldn't open fd' error would be better than "BUFFER OVERFLOW OMG" | 13:45 |
| infinity | hallyn_: epoll has been around since Linux 2.5.44 and glibc 2.3.2, I suspect it's older. :P | 13:45 |
| rbasak | infinity: for simple programs I have just used poll. Is that wrong? Is poll deprecated somehow? If I'm testing just a handful of fds, why should I use epoll instead? | 13:45 |
| hallyn_ | infinity: good point, and liblxc does use epoll | 13:45 |
| hallyn_ | but noone has ever declared select deprecated | 13:45 |
| hallyn_ | and more to th epoint, i'm pretty sure if we change all seleects in liblxc, we'll run into other libraries doing the same thing | 13:46 |
| rharper | dont we really want eventfd though ? | 13:46 |
| hallyn_ | well, that's more detailed than we need to be right now, | 13:46 |
| rharper | in any case, the discussion of what else to use is secondary to the bugs if there is agreement that going back to 1024 won't "fix" liblxc/lxd | 13:46 |
| hallyn_ | the q is, do we fix glibc or do we change al lsoftware saying it is too old otherwise | 13:46 |
| rharper | yeah | 13:46 |
| infinity | rbasak: epoll is significantly fancier, but it all depends on the level of fancy you need. | 13:47 |
| rharper | hallyn_: the thing I still don't understand is if we "fix" glibc , does that fix lxd/liblxc ? | 13:47 |
| hallyn_ | we use epoll for use with signalfd etc irc | 13:47 |
| rbasak | infinity: minimal fancy. So I think select is fine if you know an fd won't be greater than FD_SETSIZE, and poll otherwise. | 13:47 |
| hallyn_ | rharper: you were doing the testing :) | 13:47 |
| rharper | I can re-run it on trusty | 13:47 |
| rharper | where the limit is still at 1024 | 13:47 |
| hallyn_ | rbasak: that sounds like nonsense though | 13:47 |
| hallyn_ | rbasak: you cannot know a priori what the fd will be, so you'd have to check and have both codepaths anyway | 13:48 |
| hallyn_ | so just use epoll | 13:48 |
| rbasak | hallyn_: for a library, yes. | 13:48 |
| hallyn_ | so it comes down to - do we have to switch over the whole archive | 13:48 |
| hallyn_ | yes | 13:48 |
| infinity | hallyn_: We're not "fixing" glibc, that's not happening. But the default ulimit is clearly wrong. | 13:48 |
| cjwatson | We obviously don't have to switch the whole archive; lots of programs reliably never get anywhere near fd 1024. | 13:48 |
| hallyn_ | libraries | 13:48 |
| cjwatson | Libraries that couldn't guarantee not to hit 1024 were likely always buggy. | 13:49 |
| hallyn_ | infinity: is there something that will break with the glibc change? | 13:49 |
| * rbasak wonders how select(2) is implemented inside glibc. | 13:49 | |
| rbasak | I see select(2) calls in strace output. So does FD_SETSIZE need to be tuned inside the kernel as well for this to work? | 13:50 |
| hallyn_ | cjwatson: you may feel that was always the case, but the manpage doesn 'tmention that, and to me it feels like glibc breaking the contract. | 13:50 |
| rbasak | Or does the kernel just understand a larger nfds? | 13:50 |
| hallyn_ | rbasak: it's not select, it's FD_SET | 13:50 |
| hallyn_ | (FD_ENT) | 13:50 |
| hallyn_ | ok, well i'll personally hold this against libc and pretend someone cares :) but i guess i'll update lxc to not use select in any library part | 13:51 |
| rbasak | hallyn_: glibc's contract is defined by FD_SETSIZE though. Not a broken contract, just a hole where open(2) returns an fd greater than FD_SETSIZE so prevents you from using select(2) with it. | 13:51 |
| cjwatson | hallyn_: Changing FD_SETSIZE would be a pretty disastrous ABI change. Lots of programs declare fd_sets (there's no allocator function) and pass them to select. | 13:51 |
| hallyn_ | rbasak: FD_SETSIZE is internal to libc | 13:51 |
| cjwatson | No it's not. It's exposed by the size of struct fd_set. | 13:52 |
| hallyn_ | oh, i guess so | 13:52 |
| rbasak | Perhaps userspace should deprecate select, even if the kernel doesn't. Then non-deprecated stacks can have LimitNOFILE set higher or to unlimited. | 13:53 |
| rbasak | Otherwise we're forever stuck leaving it for users who want >1024 fds to guess and tune, which sucks. | 13:54 |
| hallyn_ | seems clear to me that it should | 13:54 |
| cjwatson | And the man page does have a bit in NOTES about fd_sets being fixed size. | 13:55 |
| cjwatson | Though the difficulty of raising it is left to the reader to infer ... | 13:55 |
| hallyn_ | and it also doesn't make clear that the limit is actually pretty low by default | 13:55 |
| hallyn_ | that note doesn't seem to raise the appropriate level of alarm | 13:56 |
| hallyn_ | but maybe that's just me | 13:56 |
| hallyn_ | anyway i guess i've got some lxc patches to write | 13:56 |
| hallyn_ | and some glibc effigees to burn | 13:56 |
| cjwatson | I think it depends what you're doing. I've never run into this in libpipeline, for instance, which uses select. | 13:56 |
| cjwatson | Although I should likely update that to use poll. | 13:56 |
| * rharper hands hallyn_ a torch | 13:56 | |
| cjwatson | I'd totally regard it as my bug if one of my users ran into it there though :-) | 13:57 |
| rbasak | What if we made glibc abort() if select() is called with SELECT_IS_BANNED is defined in the environment. | 13:58 |
| flexiondotorg | dholbach, Do you have a sec? I'd like to file a sync request for mate-tweak from Debian unstable. If fixes and bug and add translations. The package has not previously been synced from Debian so that changelog and history are different from the Ubuntu package. | 13:58 |
| hallyn_ | most liblxc users wouldn't run into it either. It's just golang which fires off a slew of threads using the lxc api all sharing hte same fdtable | 13:58 |
| flexiondotorg | dholbach, Is there anything "special" I need to do? | 13:58 |
| rbasak | Then anything that ups the file descriptor limit could also set that environment variable and bump it safely. | 13:58 |
| hallyn_ | i suppose that could give a clearer error msg (than having to look at objdmp output for libc), but otherwise it doesn't seem any better | 13:59 |
| dholbach | flexiondotorg, no, I'm afraid I don't have time - sorry | 13:59 |
| dholbach | can you maybe subscribe the release team?= | 13:59 |
| cjwatson | I'm sure there are easier ways to improve select's error message ... | 13:59 |
| dholbach | or ping somebody on the release team? | 14:00 |
| flexiondotorg | dholbach, OK. Thanks. | 14:00 |
| dholbach | thanks flexiondotorg! | 14:00 |
| hallyn_ | cjwatson: hah, yes, and maybe i'll send a patch for that after i "fix" lxc (i can put tha tin quotes too :) | 14:01 |
| hallyn_ | all right, thanks all. at least know where stand. | 14:02 |
| smoser | is there a tool to rename network devices ? | 14:35 |
| smoser | i'm aware of how to configure udev to do it for me | 14:36 |
| smoser | but if i want to manually do it | 14:36 |
| smoser | ie: net-rename eth1 eth2 | 14:36 |
| cyphermox | smoser: possibly ip link set dev $oldname name $newname | 14:37 |
| cyphermox | can't really try it out to see how well it does right now :) | 14:38 |
| smoser | right. yeah, i just saw that. thanks. | 14:38 |
| smoser | trying that. | 14:38 |
| === pgraner is now known as pgraner-afk | ||
| pitti | rbasak, hallyn_: FTR, if I boot with init=/sbin/upstart I still get ulimit -n == 65536 | 15:09 |
| rbasak | Interesting. I wonder what set it before? | 15:10 |
| pitti | where does that default come from? kernel? libc? | 15:10 |
| pitti | Riddell: is bug 1362599 still RC? it sounded like you added a workaroud some months ago | 15:19 |
| ubottu | bug 1362599 in Kubuntu PPA "ubiquity-dm does not transition to sddm to plasma5 desktop" [Undecided,Confirmed] https://launchpad.net/bugs/1362599 | 15:19 |
| pitti | or bug 1431332? | 15:19 |
| ubottu | bug 1431332 in sddm (Ubuntu) "sddm not starting after upgrade" [High,Incomplete] https://launchpad.net/bugs/1431332 | 15:19 |
| Riddell | pitti: worse, now if you click "Try Kubuntu" it just goes to a blank screen and I've no idea why :( | 15:31 |
| pitti | Riddell: that was my fault, ubiquity .24 fixes that | 15:38 |
| Riddell | pitti: oh really? | 15:39 |
| pitti | Riddell: if you pick live or istall in the gfxboot menu it should owrk | 15:39 |
| pitti | and FTR, typing is hard | 15:39 |
| Riddell | ok I'll rebuild the cd images and see what's still broken | 15:40 |
| pitti | Riddell: we got a new casper, you might watn to wait for that | 15:42 |
| infinity | Riddell: I'll do your images for you. | 15:54 |
| Riddell | infinity: ok, I clicked rebuild but feel free to stop if you think it needs to wait | 15:55 |
| infinity | Riddell: I can't stop it, but I can re-do it. | 15:55 |
| gQuigs | Is there a recent discussion on making btrfs the default file system? I'm curious if Ubuntu has plans to switch for 15.10/16.04 | 16:45 |
| strikov | pitti: rbasak: hallyn_ : this fileno limit (to my understanding) comes from kernel because /proc/1/limits contains this 65536 value; pam_limits comes into play later and basically uses /proc/1/limits as defaults; I have no idea why kernel sets 65536 though because it has 1024/4096 in the source code; Looks like a bug | 16:45 |
| gQuigs | so far I've only found it last discussed for 12.10 - http://www.phoronix.com/scan.php?page=news_item&px=MTEwMDE | 16:48 |
| dobey | gQuigs: afaik, there are no plans to deviate from ext as the default | 16:52 |
| hallyn_ | apw: ^ did we consciously up the fd ulimit? | 17:07 |
| rbasak | hallyn_, infinity: who's taking charge of this question? We probably should resolve it before release. | 17:08 |
| rbasak | Dropping the limit down in an SRU will not be pleasant. | 17:09 |
| rbasak | Failing that, we could configure systemd to set it to 1024 before release. | 17:09 |
| rbasak | Then at least we can raise it in an SRU later if safe. | 17:09 |
| hallyn_ | rbasak: i'm somehwat in favor of leaving it as is | 17:11 |
| rbasak | hallyn_: I'm concerned that this could introduce issues in things like server daemons that use select(). | 17:11 |
| rbasak | Perhaps security issues, given Kees' email. | 17:12 |
| rbasak | As we're not sure that everything is rebuilt with the new fortification. | 17:12 |
| hallyn_ | rbasak: glibc checks for the fd > 1024 and stops the program | 17:12 |
| rbasak | hallyn_: not unless stuff is rebuilt though, right? I haven't looked at the patch but have been assuming that. | 17:13 |
| hallyn_ | no that went into glibc in like 2011 didn't it? | 17:14 |
| hallyn_ | see the libc buglink at the bottom of kees link you pasted earlier today | 17:14 |
| rbasak | Even then, is everything correctly being built with the correct fortification setting? | 17:20 |
| rbasak | I'm concerned because this change is one that we deliberately did not make in the past, and now it's happening "by accident". | 17:21 |
| strikov | rbasak, hallyn_: i just looked at my vivid machine with trusty kernel and it still has 65536; so it's somehow vivid related | 17:24 |
| hallyn_ | rbasak: see misc/bits/select2.h in the glibc source | 17:28 |
| hallyn_ | I don't think userspace can opt out of those checks | 17:28 |
| rbasak | #if __USE_FORTIFY_LEVEL > 0 && defined __GNUC__ | 17:33 |
| rbasak | # include <bits/select2.h> | 17:33 |
| rbasak | #endif | 17:33 |
| rbasak | hallyn_: ^^ | 17:33 |
| hallyn_ | rbasak: yes, but that's at build time, and i'm telling you it is getting checked :) | 17:34 |
| rbasak | <hallyn_> I don't think userspace can opt out of those checks | 17:35 |
| rbasak | #undef __USE_FORTIFY_LEVEL and you can, no? | 17:35 |
| pitti | rbasak, hallyn_: sorry, seems I botched my init=/sbin/upstart test, my VM didn't have upstart installed; it's indeed 1024 under upstart | 17:36 |
| rbasak | dpkg-buildflags says CPPFLAGS=-D_FORTIFY_SOURCE=2 but a build that fails to use that wouldn't do it. | 17:36 |
| pitti | hm, grepping systemd for "ulimit" yields nothing except a manpage; where else does that get set? | 17:37 |
| pitti | and neither does upstart | 17:37 |
| pitti | ah, setrlimit() | 17:38 |
| strikov | pitti: http://bazaar.launchpad.net/~registry/systemd/master/view/head:/src/core/main.c#L1043 | 17:38 |
| strikov | pitti: looks suspicious because it bumps to 65536 exactly | 17:38 |
| strikov | pitti: it looks like it doesn't revert it back | 17:38 |
| pitti | * PID 1 will now increase its RLIMIT_NOFILE to 64K by default | 17:39 |
| pitti | (but not for its children which will stay at the kernel | 17:39 |
| pitti | default). This should allow setups with a lot more listening | 17:39 |
| pitti | sockets. | 17:39 |
| pitti | so apparently that "but not.." doesn't work | 17:39 |
| strikov | pitti: i don't understand this code then: http://bazaar.launchpad.net/~ubuntu-core-dev/pam/ubuntu/view/head:/modules/pam_limits/pam_limits.c#L369 | 17:40 |
| strikov | pitti: pam relies on /proc/1/limits | 17:40 |
| pitti | strikov: oh, so it copies pid1's limits -- pid1 has intentionally 64K | 17:41 |
| rbasak | pitti: as a workaround we could set DefaultLimitNOFILE in /etc/systemd/system.conf, although conffile prompt. | 17:42 |
| pitti | indeed, e. g. crond has 1024 | 17:42 |
| strikov | pitti: yeah, it gets defaults from /proc/1 and then overwrites it with /etc/security/limits.conf; at least that's my understanding | 17:42 |
| pitti | so its children do have 1024, but pam sets it to pid1's instaed of the default for sessions? | 17:42 |
| rbasak | Ah | 17:42 |
| rbasak | Good job figuring that one out! | 17:42 |
| pitti | so we need to set it in /etc/security/limits.conf? | 17:42 |
| pitti | (sorry for delay, juggling more installer/plymouth bugs here than I'd ever wanted to look at) | 17:43 |
| rbasak | /usr/sbin/lightdm and /usr/bin/X are 1024 on my system. | 17:44 |
| rbasak | And lightdm --session-child is 65536. | 17:44 |
| rbasak | So that would be consistent with PAM. | 17:44 |
| pitti | I'd rather drop a file into /etc/security/limits.d/ instad of changing the conffile | 17:44 |
| pitti | right | 17:45 |
| rbasak | /etc/security/limits.d/ sounds like it would work and be reasonable to me. | 17:45 |
| pitti | so we either drop a conffile snippet there, or we change PAM to not read it from pid 1 but from itself? | 17:45 |
| rbasak | If from itself, what about an su-type case? | 17:46 |
| rbasak | I have some very limited user but su to root. Should I expect my limit to go up? | 17:46 |
| pitti | my gut feeling is that compiled-in default >> conffile, but at this point of the release cycle we might need to make compromises indeed | 17:47 |
| infinity | I think the right fix is to switch PAM from using the PID1 defaults to using the defaults of its own process. | 17:47 |
| rbasak | Maybe change PAM to read from pid 1, but cap at 1024? | 17:47 |
| pitti | rbasak: good point | 17:47 |
| strikov | yeah, i don't like removing all defaults, just nofiles=1024 is much better | 17:47 |
| pitti | rbasak: trying that here | 17:48 |
| rbasak | Even cleaner, cap to FD_SETSIZE. | 17:48 |
| * sbeattie hrms, pondering su with an fd limit of 1... | 17:48 | |
| pitti | yes, it does get inherited :/ | 17:49 |
| rbasak | What did you try exactly? Limited nofile on user gets inherited on su to root? | 17:49 |
| pitti | ulimit -n 50 | 17:49 |
| pitti | su - joe | 17:50 |
| pitti | but in fact that's happening on current vivid | 17:50 |
| pitti | i. e. su/pam already inherit from the parent | 17:50 |
| pitti | it's just getting the 64K from the initial lightdm session or so? | 17:50 |
| hallyn_ | rbasak: when I say "userspace can't opt out" I mean for instance liblxc. obviously you can rebuild and opt out. | 17:53 |
| rbasak | pitti: su to root doesn't reset it. But after I've su'd to root, "login -f root" does. | 17:53 |
| kees | I was pretty sure pam uses init's values for the defaults, not the parent. that was the whole reason /proc/$pid/limits was added, IIRC | 17:54 |
| rbasak | /etc/pam.d/login uses pam_limits.so. /etc/pam.d/su does not. | 17:54 |
| rbasak | What does lightdm use? /etc/pam.d/login as well? | 17:55 |
| pitti | yes, should all be pam | 17:55 |
| pitti | we just checked getty | 17:55 |
| rbasak | So I think pam_limits.so reset me back to 65536. | 17:55 |
| pitti | getty itself has 1024 as it sohld | 17:55 |
| pitti | once you login, the "login" process gets 64K | 17:55 |
| rbasak | So I think the fix should be to cap it to FD_SETSIZE in pam_limits.so when reading limits from pid 1. | 17:55 |
| infinity | That would work too, sure. | 17:56 |
| pitti | rbasak: WFM; this is easier to change in an SRU than conffiles | 17:56 |
| infinity | Someone whip up a patch and pass it by slangasek, please. | 17:56 |
| infinity | Anything but changing conffiles to work around it. | 17:56 |
| rbasak | The pam package is version 1, uses dh --with-quilt, sets export QUILT_PATCH_DIR = debian/patches-applied in debian/rules and if I try to use quilt patches apply with fuzz. WTF? | 18:17 |
| rbasak | Well, one patch applies with fuzz. | 18:17 |
| mdeslaur | rbasak: yeah, fuzz only fails with src format 3.0 | 18:19 |
| mdeslaur | it used to be ok, unfortunately | 18:19 |
| rbasak | Oh, OK. Thanks. | 18:21 |
| Unit193 | Howdy. Two things, 1: Is https://bugs.launchpad.net/bugs/1404783 going to be fixed for trusty? Would be very useful. 2. Pretty sure no name for 15.10 yet, so no point in poking. :P | 18:22 |
| ubottu | Launchpad bug 1404783 in compiz (Ubuntu) "warnings from apt: W: Unknown Multi-Arch type 'no' for package 'compiz-core'" [Undecided,Confirmed] | 18:22 |
| rbasak | hallyn_, pitti, infinity: previously the hard limit was 4096, and only the soft limit was FD_SETSIZE at 1024. If I cap just the soft limit now, the hard limit will have increased to 65536. I presume this is OK? | 19:05 |
| rbasak | kees: ^^ | 19:05 |
| hallyn_ | rbasak: i think that's ok, | 19:06 |
| hallyn_ | that way lxd can bump its soft limit higher if it wants to. | 19:06 |
| hallyn_ | (which it probably will) | 19:06 |
| hallyn_ | while unsuspecting sw is still protected | 19:07 |
| rbasak | Yeah that was my logic. I presume that was the previous logic in having a hard limit of 4096 before. | 19:08 |
| rbasak | slangasek: could you review http://paste.ubuntu.com/10863087/ please? I'm also not sure how to go about upstreaming this as pam_limits seems to be heavily patched already. | 19:54 |
| rbasak | infinity, pitti, hallyn_: ^^ | 19:54 |
| rbasak | infinity: do you want an upload or a 0-day SRU? | 19:55 |
| slangasek | those are the same thing ;) | 19:56 |
| slangasek | rbasak: it'll be late afternoon before I can review it fwiw | 19:56 |
| rbasak | OK, thanks. | 19:56 |
| === salem_ is now known as _salem | ||
| boax | hello | 22:21 |
| boax | i found a critical bug in 15.04! | 22:21 |
| boax | it makes the complete system unusable for many cases!! | 22:22 |
| boax | can a dev here help me to get able to debug that? The bug was there in 15.04 beta2 and is still there in 15.04 daily build from 21.04.2015! | 22:23 |
| boax | the whole X-Server is crashing | 22:24 |
| boax | in Xorg i get the message "Cought signal 11" and the server goes down! | 22:25 |
| tarpman | boax: https://wiki.ubuntu.com/X/Reporting | 22:25 |
| boax | tarpman: yes, i have already reported a bug the one or other time. But i cant find out what could be the problem that causes this bug | 22:26 |
| boax | tarpman: are you a dev? | 22:26 |
| tarpman | boax: reporting a bug is still the best place to start; apport (ubuntu-bug) will include information that could contain clues, and the bug report is a better place to discuss it | 22:27 |
| tarpman | boax: no, just a user | 22:27 |
| boax | there are just two days till release. thats critical. i dont think that the normal way would help fix that till release | 22:27 |
| boax | http://pastebin.com/9K0W1NwU | 22:42 |
| boax | an xorg dev say: <alanc> looks like it crashed in call from libglamoregl.so to libfb.so | 22:43 |
| tarpman | boax: bug 1280527 and bug 1443456 look similar | 22:48 |
| ubottu | bug 1280527 in xserver-xorg-video-ati (Ubuntu) "Xorg crashed with SIGABRT in fbBltOne()" [Medium,New] https://launchpad.net/bugs/1280527 | 22:48 |
| ubottu | bug 1443456 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT in fbBltOne()" [Medium,New] https://launchpad.net/bugs/1443456 | 22:48 |
| boax | here someone with the same error: https://bbs.archlinux.org/viewtopic.php?id=195666 | 22:49 |
| boax | what gnome version would be into ubuntu 15.04? | 23:15 |
| Unit193 | !info gnome3 vivid | 23:15 |
| ubottu | Package gnome3 does not exist in vivid | 23:16 |
| Unit193 | !info gnome-shell vivid | 23:16 |
| ubottu | gnome-shell (source: gnome-shell): graphical shell for the GNOME desktop. In component universe, is optional. Version 3.14.4-0ubuntu1 (vivid), package size 623 kB, installed size 6923 kB | 23:16 |
| Unit193 | boax: 3.14 | 23:16 |
| boax | Unit193: people report that after updating gnome from 3.14 to recent version the reported bug is gone | 23:17 |
| boax | https://bbs.archlinux.org/viewtopic.php?id=194819 | 23:19 |
| boax | could you please bump the gnome version? the one inside 15.04 is causing such xorg crashes | 23:21 |
| boax | tarpman: you was right with bug number 1443456. RAOF have checked the crash log and told that i have exactly this error | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!