[01:39] <penguin42> I wonder what the right thing to do with bug 671837 is
[01:39] <ubot2> Launchpad bug 671837 in xorg-server (Ubuntu) "Xorg crashes due to known bug in Xinerama code (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/671837
[01:40] <penguin42> it references an upstream mailing list (not a bug report though) and points to a patch
[01:45] <penguin42> hmm bed
[08:49] <cjae> may I describe a problem and someone tell me how to best describe it for a bug report
[08:50] <cjae> I have images of the issue as well
[15:12] <nemo> Trying to draw a little attention to my somewhat humerous yet rather damaging bug.
[15:12] <nemo> bug #661494
[15:12] <ubot2> Launchpad bug 661494 in x11-apps (Ubuntu) "Request to limit xinit writes to .xsession-errors to some reasonable value, such as 10 megs (affects: 1) (heat: 157)" [Undecided,New] https://launchpad.net/bugs/661494
[15:12] <nemo> wondering if I could get one of the good folk of this channel to look it over, maybe, dunno, say whether the idea has merit
[15:16]  * penguin42 looks
[15:16] <penguin42> hehe, 373G that might be a record
[15:17] <yofel> indeed, at least I haven't yet seen another report with a file >100GiB yet
[15:18] <penguin42> nemo: So I've seen the same thing happen many times - I used to admin a ~100 person network with peoples ~ on NFS, and filling up /home due to .xsession-errors was a common screw up
[15:19] <nemo> penguin42: but. yeah. why on earth isn't this piped to head or a rolling log appender?
[15:19] <nemo> seems like a trivial fix
[15:19] <nemo> penguin42: if the log really overshot, say, 10 megs, it probably shouldn't be growing more anyway
[15:19] <nemo> it isn't like the information in it is critical
[15:20] <nemo> or 20 megs or 40. whatever
[15:20] <nemo> ... or a percentage of the disc that $HOME is on...
[15:20] <nemo> or /home :)
[15:21] <kklimonda_> nemo: if it seems like a trivial fix and still it isn't fixed then it probably isn' trivial after all ;)
[15:22] <nemo> kklimonda_: quite possibly, but then it should be easy to shoot down the trivial fix :)
[15:22] <nemo> hm
[15:22] <nemo> I guess I could make some headway by, oh, trying head -c on my local system
[15:22] <kklimonda_> nemo: I do remember that at some point it was limited - after some time no new messages were logged. And it was terrible ;)
[15:22] <nemo> kklimonda_: depends on what it was limited to
[15:22] <nemo> in a normal session, it'll never get more than a few megs
[15:22] <nemo> but if the limit is set high, then if it hits it, you're probably glad it did
[15:23] <nemo> as I would have been
[15:23] <nemo> but. ok. lemme test my trivial solution w/ a ceiling of, oh, 50 megs
[15:30] <nemo> kklimonda_: a rolling log app would avoid the halting errors prob of course, since it could just keep .xsession-errors and .xession-errors.1.gz etc w/ a few copies
[15:30] <kklimonda_> nemo: sure but X would have to support it
[15:30] <nemo> why?
[15:30] <nemo> this is outside of X
[15:30] <kklimonda_> nemo: well, actually the application that does log it there
[15:30] <nemo> unless you mean as a dependancy in ubuntu
[15:30] <nemo> exec >"$ERRFILE" 2>&1
[15:30] <nemo> vs
[15:31] <nemo> exec 2>&1 | head -c 5000000 > "$ERRFILE"
[15:31] <nemo> or
[15:31] <nemo> exec 2>&1 | rollinglogfile "$ERRFILE"
[15:31] <yofel> Xsession is only run once right?
[15:31] <kklimonda_> $ rollinglogfile
[15:31] <kklimonda_> rollinglogfile: command not found
[15:31] <kklimonda_> :P
[15:31] <nemo> kklimonda_: smartass
[15:32] <nemo> kklimonda_: I'm sure they exist, and not just as generic logging mechanisms
[15:32] <nemo> worse to worse, could use one of those
[15:32] <kklimonda_> probably, someone should investigate :)
[15:32] <nemo> well. I'm trying head -c 50000000 right now :)
[15:33] <nemo> if *that* works it'd already be a lot less evil to users
[15:34] <nemo> kklimonda_: hm. there's some truncation code in there now, but looks like it is just called on starting a new exec
[15:34] <yofel> well, /etc/X11/Xsession has a DoS protection currently... but the way it's done it's pointless if it gets run just once (line 77ff in maverick)
[15:34] <nemo> doesn't limit the existing session
[15:34] <nemo> yofel: yeah. reading that
[15:35] <nemo> yofel: and is much more aggressive than me. limits to only 500000
[15:35] <yofel> right
[15:35] <nemo> so clearly 5 megs or 50 megs is a generous sanity
[15:35] <nemo> limit
[15:37] <penguin42> nemo: doing a log rotate type of thing might work
[15:38] <nemo> head -c 5000000 seems to be working fine too :)
[15:38] <nemo> I'll put it on all my systems
[15:38] <nemo> but
[15:38] <nemo> it'd be nice to not have to merge it
[15:39] <nemo> oh well. just trying to get some visibility. and yes, 373 gigs is extreme
[15:39] <nemo> what is alarming is how easily it happened
[15:40] <nemo> and the result basically shut down the system for that user
[15:40] <penguin42> nemo: Yeh it only takes one app to go nuts
[15:40] <nemo> penguin42: hell. someone could possibly do it w/ a web browser. plugins and such sometimes write to err
[15:40] <nemo> I could DOS an ubuntu user remotely
[15:40] <nemo> if I was clever
[15:41] <nemo> and I got them to hang out on my page long enough
[15:41] <penguin42> nemo: There are some related problems 1) It's difficult to tell what actually wrote into the log and 2) No one really takes care to clean apps up so they don't normally
[15:41] <nemo> I think webgl still does a bit of error spam in some situations, that would avoid even needing to load a plugin :)
[15:41] <kklimonda_> well, "a bit of error spam" isn't bad
[15:41] <nemo> penguin42: well. those are more usability. I'd just like to not have it kill my systems by accident ;)
[15:42] <kklimonda_> the Oracle Installer is an extreme case
[15:42] <penguin42> kklimonda_: I've seen lots of other things do similar
[15:42] <kklimonda_> penguin42: oh? that's the only app I've seen doing that :)
[15:42] <kklimonda_> some do spam a lot
[15:42] <kklimonda_> but not nearly enough
[15:43] <kklimonda_> for it to be a concern (enter fail) ;)
[15:43] <nemo> well
[15:43] <nemo> let me check what gets written in firefox on plugin / webgl activation
[15:43] <nemo> I bet I could whip up a page that is malicious
[15:43] <nemo> w/o it using too much CPU
[15:43] <yofel> nemo: can you give me the *exact* syntax of exec you want to use? (the one with head)
[15:43] <nemo> hell. noscript writes to stderr
[15:44] <nemo> yofel: can show you what I'm testing in my VM right now, sure
[15:44] <kklimonda_> nemo: but that would require you to have a malicious intent.
[15:44] <nemo> kklimonda_: yes. but remote malicious intent
[15:44] <nemo> just as bad as local accidental :)
[15:44] <nemo> and insidious since oomkill won't pick it up and it'd persist
[15:46] <nemo> yofel: exec 2>&1 | head -c 50000000 >>"$ERRFILE"
[15:46] <nemo> yofel: the other truncation code will still work fine on restart.
[15:47] <nemo> .xession-errors still seemed to be written to normally
[15:48] <nemo> yofel: cleverer code might do a fraction of disc, but 50 megs isn't that much in this day and age.  anyone really short on space might want to use /dev/null anyway :-p
[15:49] <yofel> hm, right, this does work, but with head the limit should be like 50MiB, some apps do put a lot of messages in there, and they rarely fail at the beginning
[15:49] <nemo> yofel: that *is* 50 megs
[15:49] <nemo> admittedly not 50MiB ;)
[15:49] <yofel> err, right, too many zeroes :P
[15:49] <nemo> but. yeah 2 orders of magnitude more than the truncation
[15:51] <yofel> the truncation code uses tail which is the right thing to use, but I agree that head with a sane limit would be ok to use. Won't protect against everything, but against most failures I guess
[15:52] <nemo> easier than hooking up a rolling appender :-p
[15:52] <nemo> could do that as a "later"
[22:05] <CarlFK> http://dpaste.de/mGIK/  *** buffer overflow detected ***: tftp terminated[22:06] <CarlFK> whats the shell command to post the bug report to lp?
[22:52] <yofel> CarlFK: run 'sudo service apport start force_start=1' - crash it again and file the crash report in /var/crash with ubuntu-bug (if it hopefully catches the crash)
[22:53] <CarlFK> got it already. but thanks
[22:53] <yofel> np, sorry for being late
[22:53] <CarlFK> while I got you, question bout https://wiki.ubuntu.com/DebuggingProgramCrash
[22:53] <CarlFK> echo "deb http://ddebs.ubuntu.com $(lsb_release -cs) main restricted universe multiverse" | sudo tee -a /etc/apt/sources.list.d/ddebs.list
[22:53] <CarlFK> why not use  apt-add-repository "deb http://ddebs.ubuntu.com $(lsb_release -cs) main restricted universe multiverse
[22:54] <yofel> backwards compatibility I think. As far as I know hardy doesn't have add-apt-repository
[22:54] <CarlFK> k
[22:55] <CarlFK> and is there a way to do that in a preseed file that doesn't hardcode "natty"?
[22:55] <CarlFK> d-i apt-setup/local0/repository string http://ddebs.ubuntu.com natty main restricted universe multiverse
[22:55] <yofel> CarlFK: it uses '$(lsb_release -cs)' which will insert natty only if you run it on natty
[22:55] <CarlFK> preseed file
[22:56] <CarlFK> really an installer question than a -debug
[22:56] <yofel> I don't know about preseed files I fear
[22:57] <CarlFK> no prob
[22:57] <yofel> maybe ask in #ubuntu-installer if it's d-i specific
[23:03] <drizzle> Can someone wishlist https://bugs.launchpad.net/ubuntu/+source/glade-3/+bug/672313 please
[23:03] <ubot2> Launchpad bug 672313 in glade-3 (Ubuntu) "Maximized window not remembered (affects: 1) (heat: 6)" [Undecided,Opinion]