**** BEGIN LOGGING AT Thu May 03 03:00:01 2012 May 03 03:24:23 karlp: so monit buying you time? May 03 08:45:22 Weedy_lappy: yeah, it's helping with the deliberately leaky program I've got now, but only after turning up the monit interval and how soon before it restarts. May 03 08:47:03 monit counts the resident set size, (VmHWM and VmRSS in /proc//status), which is more than an order of magnitude lower than VmSize and VmData May 03 08:47:27 you can write your own tests May 03 08:47:27 I'm still concerned that if it ever leaks faster than monit can kill it, that the OOM killer isn't kicking in in time, May 03 08:47:46 yeah, but that still needs monit to go fast enough. May 03 08:48:03 what is your interval? May 03 08:48:13 the oom killer should still kick in and kill it based on oom_adj and oom_score before the whole system crashes May 03 08:48:18 30 seconds at the moment. May 03 08:48:25 damn that's fast May 03 08:48:37 wtf is your app down to leak that much mem May 03 08:48:47 I know the app should never leak that fast, and this is more than sufficient for anything I can see realisitically May 03 08:48:54 my app is currently designed to leak memory May 03 08:49:00 oh May 03 08:49:05 your testing May 03 08:49:09 yes :) May 03 08:49:18 i thought that was the prod app May 03 08:49:21 i was like May 03 08:49:24 oh no, May 03 08:49:28 how the fuck is that in prod May 03 08:49:33 :v May 03 08:49:49 the prod app had a known leak when the central server was down, and someone managed to bring that down for 36 hours, May 03 08:50:07 > known leak May 03 08:50:10 > known May 03 08:50:15 which I still don't think should hve been enough to leak so much that it crashed, but something bad happened and a box didn't come back. May 03 08:50:17 i think i found your problem May 03 08:50:24 oh, the leak's fixed May 03 08:50:27 :V May 03 08:50:33 ran more cases through valgrind, May 03 08:50:53 I just want to make sure that we behave more predictably if anything else like this ever happens again May 03 08:53:43 so, monit seems to be sufficient for anything I can realistically consider, but I'd feel a lot more comfortable if I could see a) the oom killer waking up to kill tasks before the machine crashes and reboots, and b) the openwrt crashdump in /sys/kernel/debug. May 03 08:53:59 but, I don't always get to be comfortable :) May 03 08:54:14 needs more serial consol May 03 08:56:08 yeah, that was my thought yesterday afternoon :) May 03 08:56:26 I thought we'd gotten past that point some months back. May 03 08:56:35 need more uarts on this damn board May 03 08:56:44 i'm guessing remote syslog wasn't fast enough May 03 08:57:32 nope. May 03 08:57:38 sux May 03 08:57:46 yep :) May 03 08:57:49 oh well :) May 03 08:57:51 life goes on. May 03 08:58:05 thanks muchly for making me go back and lookat the monit docs again May 03 08:58:30 monit is pretty awesome May 03 08:58:59 the monit init.d script in backfire at least doesn't work for restart though :) May 03 08:59:23 before or after it got service wrappers? May 03 08:59:25 but yeah, I've been pretty happy with it. May 03 08:59:29 > using init scripts May 03 08:59:45 monit is the one process i never use the init script for May 03 08:59:48 if its the classical "killall foo" style init script I can believei t very well that restart fails May 03 09:00:06 stop is: [ -f $PID_F ] && kill $(cat $PID_F) May 03 09:00:10 and it's labelled as 2006 May 03 09:00:11 or that May 03 09:00:18 yeah, thats going fail May 03 09:00:38 stop; sleep 1; start works :) May 03 09:00:45 Weedy_lappy: do you run monit from inittab? or where? May 03 09:01:01 karlp: i leave openwrt to start it May 03 09:01:14 but i end up using monit reload like ALL the time May 03 09:01:31 i touch the init script like once a year May 03 09:01:58 oh, you let the init script start it, but then just use monit reload rather than restarting via init scripts May 03 09:02:26 pretty much May 03 09:39:08 juhosg * r31564 /trunk/package/ppp/ (4 files in 3 dirs): May 03 09:39:08 Add ppp-mod-pppol2tp subpackage to ppp May 03 09:39:08 Signed-off-by: David Woodhouse May 03 09:39:10 juhosg * r31565 /trunk/package/pptp/ (Makefile files/pptp.sh): (log message trimmed) May 03 09:39:10 Fix pptp handling of routes to server. May 03 09:39:10 The existing code is fairly broken. It assumes you're using Legacy IP, and May 03 09:39:10 it assumes that the server is reachable via your default route. Via the May 03 09:39:10 first default route in the 'route -n' output, in fact, regardless of metric. May 03 09:39:10 Fix all those problems by using 'ip route get' to really find the *current* May 03 09:39:10 route to the server, and install a host-specific route to match. May 03 09:43:11 juhosg * r31566 /trunk/ (10 files in 10 dirs): May 03 09:43:12 Fix iptables abuse of kernel header files. Use exported headers instead. May 03 09:43:12 [juhosg: export xt_layer7.h for all kernel versions] May 03 09:43:12 Signed-off-by: David Woodhouse May 03 09:47:11 build #7 of ppc40x is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ppc40x/builds/7 May 03 10:08:48 karlp: do you have swap setup? May 03 10:09:19 nope. May 03 10:23:14 karlp: do you have swappiness disabled? May 03 10:23:31 I hope so? where is that one? May 03 10:24:15 something like /proc/sys/vm/swappiness May 03 10:27:26 hmm, that's at the default of 60, May 03 10:27:33 but with no swap, shouldn't it have no effect? May 03 12:19:45 build #7 of uml is complete: Failure [failed shell compile_6] Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/7 May 03 13:04:43 nbd * r31567 /packages/libs/uclibc++/patches/010-gcc47x_support.patch: uclibc++: merge gcc 4.7.x fixes from freetz (fixes #11341) May 03 13:29:37 juhosg * r31568 /trunk/package/pptp/files/pptp.sh: package/pptp: remove a stray bracket May 03 15:32:15 Hello... is the lists/ directory still supported in ImageBuilder? May 03 15:37:07 build #7 of ppc44x is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/7 May 03 16:07:39 lists ? May 03 16:21:40 jow_laptop: can we add 'list dhcp_option' support to 'config host' sections? May 03 16:21:59 we probably can May 03 16:22:14 build #11 of s3c24xx is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/s3c24xx/builds/11 May 03 16:22:39 good. I have an MPEG4 PoE camera that I want to not have a default gateway... :-) May 03 16:23:17 plus a client's development machine here that needs a different domain name, etc. May 03 16:38:30 jow_laptop: what's involved? May 03 16:38:44 I can test a patch here locally... May 03 17:19:18 jow * r31569 /trunk/package/uhttpd/src/uhttpd-utils.c: (log message trimmed) May 03 17:19:19 uhttpd URL-codec bug fixes. May 03 17:19:19 * Fixed output-buffer-overflow bug in uh_urlencode() and uh_urldecode() [tested May 03 17:19:19 input-buffer index against output-buffer length]. In reality, this would not May 03 17:19:19 typically cause an overflow on decode, where the output string would be May 03 17:19:19 expected to be shorter than the input string; and uh_urlencode() seems to have May 03 17:19:19 been unreferenced in the source. May 03 17:19:22 jow * r31570 /trunk/package/uhttpd/src/ (uhttpd-lua.c uhttpd-utils.c uhttpd.c): (log message trimmed) May 03 17:19:22 Fixed: [PATCH 2/3] uhttpd URL-codec enhancements. May 03 17:19:22 My apologies, the 2nd of those patches had a syntax error -- that's what May 03 17:19:22 I get for making a last-minute edit, even to the comments, without May 03 17:19:22 testing! :-p May 03 17:19:23 Here is the corrected patch. May 03 17:19:23 -- David May 03 17:19:24 jow * r31571 /trunk/package/uhttpd/src/ (uhttpd-lua.c uhttpd-lua.h uhttpd.c uhttpd.h): (log message trimmed) May 03 17:20:15 when the handler-chunk is loaded but rather not until the handler is called, May 03 17:20:15 without any code savings. May 03 17:20:15 jow * r31572 /trunk/package/uhttpd/ (7 files in 3 dirs): [package] uhttpd: display errors in init script, code formatting changes, bump package version May 03 19:22:08 thepeople: how many of the buildbot targets are eglibc? May 03 19:22:52 I'd like to see x86/alix + eglibc be one of the buildbot targets. May 03 20:18:45 hauke * r31573 /trunk/target/linux/brcm47xx/ (22 files in 2 dirs): brcm47xx: add support for kernel 3.3 May 03 21:03:58 jogo * r31574 /trunk/target/linux/adm5120/files/drivers/mtd/maps/adm5120-flash.c: May 03 21:03:58 adm5120: add missing NULL terminator to partition parser list May 03 21:03:58 Fixes #11372. May 03 21:50:42 kaloz * r31575 /trunk/package/mac80211/Makefile: [mac80211]: switch to the new linux-firmware git tree, use the new wl12xx firmware files May 03 21:51:59 kaloz * r31576 /trunk/target/linux/omap4/ (5 files in 2 dirs): [omap4]: upgrade to 3.3, enable framebuffer May 03 22:19:03 swalker * r31577 /packages/lang/python/Makefile: [packages] python: update to 2.7.3 (#11329) May 03 22:19:20 swalker * r31578 /packages/net/obfsproxy/ (Makefile patches/001-no-werror.patch): [packages] obfsproxy: update to 0.1.4 May 03 22:19:37 swalker * r31579 /packages/net/tor-alpha/ (Makefile patches/001-torrc.patch): [packages] tor-alpha: update to 0.2.3.15-alpha, re-enable fixed UPnP support May 04 00:53:28 tripolar * r31580 /packages/net/openssh/files/sshd.init: [packages]: don't exit the sshd init script every time a key was created May 04 01:11:20 i got rt2800usb going, seems to work fine May 04 01:11:40 this vs the proprietary ralink driver, the proprietary let me compile out LED support May 04 01:11:57 so it was dark (good), since this is an alarm clock May 04 01:12:14 all the triggers say [none] and i set brightness to 0 May 04 01:12:23 but it is still blinking blue :~( May 04 01:16:08 oh boy this does not work right :( May 04 01:16:20 changing the trigger leads to dmesg full of errors May 04 01:16:28 * m4t switches back to proprietary May 04 01:18:53 i picked a crappy dongle **** ENDING LOGGING AT Fri May 04 02:59:59 2012