[00:09] <TheLordOfTime> OK
[00:17] <adam_g> zul, how are we meant to handle this? jsonpatch 1.0 (/usr/lib/python2.7/dist-packages), Requirement.parse('jsonpatch>=0.10,<=0.12'))
[00:18] <zul> adam_g:  run the tests locally with updated requirements.txt and then patch the requests
[00:18] <zul> which package is this?
[00:18] <adam_g> zul, this isn't the test suite, post-install service not working because VersionConflict
[00:19] <adam_g> zul, cinder, but nova is an issue as well
[00:19] <adam_g> zul, i was backporting to PPA to match UCA versions, and noticed in cinder as well as nova
[00:20] <adam_g> zul, i'm looking around for the reqiurements.txt that specifies the range, its not in requirements.txt according to github.com/openstack/requirements.git
[00:20] <adam_g> zul, im trying to get a good dep8 test going for this. stevedore catches these exceptions and lets the serices start up anyway, which is why our current dep8s are passing fine
[00:22] <zul> adam_g:  could it be one of the clients that is doing it?
[00:24] <adam_g> zul, agh, its python-warlock
[00:24] <zul> adam_g:  oh....bullocks
[00:25] <adam_g> zul, well, actually i've still got an older warlock in the repo
[00:25] <zul> adam_g:  ah that might be it then
[00:25] <adam_g> zul, im having trouble building the backport, tho
[00:26] <zul> adam_g:  buildlog?
[00:26] <adam_g> zul, http://paste.ubuntu.com/5902397/
[00:27] <zul> adam_g:  thats weird
[00:27] <adam_g> zul, i see it built fine in the havana PPA
[00:27] <adam_g> havana-staging, that is
[00:28] <zul> adam_g:  im not sure whats going there but line 476 is definently weird
[00:28] <adam_g> zul, oh, nvm. thats still outdated there too. 	1.0.0-1~cloud0, we want 	1.0.1-1ubuntu1
[00:28] <zul> right
[00:28] <adam_g> zul, how did you handle other python3 backports to precise?
[00:28] <adam_g> i know we were hitting this in the past with something else
[00:29] <adam_g> 1.0.1-1ubuntu1 added python3-warlock
[00:29] <zul> adam_g:  i think it might have been testtools i cant remember...or subunit...actually i think it was subunit
[00:38] <adam_g> zul, any idea what the solution was?
[00:38] <zul> adam_g:  it was not to build for python3
[00:41] <adam_g> zul, whatcu talkin about willis?
[00:41] <zul> adam_g:  not to build the python3 package if i remember correctly
[00:41] <adam_g> zul, we have both python3-subunit_0.0.12-0ubuntu1~cloud0_all.deb +  python3-testscenarios_0.3-0ubuntu2~cloud0_all.deb
[00:41] <adam_g> in havana-staging ATM
[01:04] <sarnold> jdstrand,hallyn: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1203211
[01:07] <adam_g> zul, FWIW subunit fails to rebuild there, as well, so maybe its something with the locla build env. and python3.
[01:07]  * adam_g EOD
[01:13] <jdstrand> sarnold: hah! that would do it :)
[01:13] <jdstrand> -5 fixes it fwiw
[01:15] <sarnold> jdstrand: woot :)
[01:53] <med_> adam_g, OpenStack question: any idea of status on LBAAS?
[02:32] <methods2> is there an upstart event that fires before normal daemons launch ?
[06:23] <vikashla> My httpd.conf file is blank how can I configure Apache(2.2)
[06:25] <vikashla> Can Anyone help
[06:27] <vikashla> ???
[06:28] <vikashla> ?????????????????????????????????
[06:50] <mrgate_> hey
[06:50] <mrgate_> im having a issue trying to run codeigniter on my ubuntu server
[06:50] <mrgate_> and i dont want to have to reinstall my entire os ):
[06:51] <mrgate_> apache error log http://pastebin.com/S5FeVd7p
[06:55] <mrgate_> anyone ):
[06:58] <rbasak> !patience | mrgate_
[07:02] <greppy> mrgate_: does the file it is looking for exist?
[07:02] <mrgate_> yes
[07:02] <greppy> do the permissions of all of the directories and the end file, allow your apache user to read it?
[07:03] <greppy> a common issue is that /home/user is set to 0700 permissions.
[07:03] <greppy> or that a directory in the path is.
[07:06] <mrgate_> how do you check
[07:07] <mrgate_> kinda new to ubuntu sorr
[07:07] <mrgate_> y
[07:07] <greppy> by default apache shouled be running as www-data
[07:07] <greppy> meh s/shouled/should/
[07:08] <greppy> so check the permissions of each directory in the path to make sure that it is set to 755 permissions, or rw rx rx.
[07:08] <greppy> ls -ld /home/mrgate should give the permissions of your home directory.
[07:08] <mrgate_> the issue is fixed since i chmod the entire thing with 0777
[07:10] <greppy> don't do that.
[07:10] <greppy> 777 == evil.
[07:10] <mrgate_> its just my web folder ?
[07:10] <greppy> any user on the system can edit or delete files that are 777
[07:11] <greppy> try 755
[07:11] <greppy> that gives the owner rwx but limits everyone else to rx
[07:12] <greppy> 777 on a folder exposed to the outside world has caused no end of issues.
[07:13] <mrgate_> fixed
[07:15] <greppy> mrgate_: a rule of thumb: use 755 for directories, use 644 for files if you need other users on the system to be able to read them.
[08:53] <StathisA> i've installed Deluge on my headless server...manually works ok, but how do i make the services start with the server?
[09:22] <hachre> StathisA: are you running it as root?
[09:22] <StathisA> yes but nvm, its not as easy at it looks...
[09:23] <StathisA> need to make some scritps as described on http://dev.deluge-torrent.org/wiki/UserGuide/InitScript/Ubuntu%2011.04%2B%20%28Upstart%20Job%29#StartingandstoppingUpstartScripts
[09:23] <hachre> StathisA: you gotta make a upstart job
[09:23] <StathisA> yeah thats what the link is about
[09:37] <StathisA> thanks for the answer thought :-)
[09:40] <hachre> np ;)
[10:11] <koolhead17> hi all
[11:09] <g105b> Can someone point me in the right direction? I want to have 3 staging servers and keep their installed packages and config files in sync - what tools are available?
[11:13] <ikonia> rsync ?
[11:14] <g105b> ikonia: I'm actually using scp at the moment, but the problem I'm facing is that when I install a package, say 'php', and I make a change in the php.ini, along with some timezone settings, then the other servers need to be set up like that too.
[11:14] <andol> g105b: puppet/chef/cfengine?
[11:15] <ikonia> g105b: is this a production config and 3 servers part of it, or is this just 3 stand alone servers and thats all you've got
[11:15] <g105b> only got 3 servers.
[11:15] <ikonia> ok, so puppet or something like that is probably overkill
[11:15] <ikonia> just setup rsync to push out config/content on regular basis from one server to the other 3
[11:16] <g105b> yeah I'm aware of puppet, and that's what I thought.
[11:16] <g105b> ikonia: Alright, thanks I'll look into rsync ... not used it before.
[11:16] <ikonia> g105b: should tick %99 of what you need and want out of the box
[11:16] <g105b> Thanks.
[11:17] <g105b> ikonia: but what about installed packages? When I install something on one server, how can I keep all servers on the same version?
[11:18] <jamespage> jdstrand: ping re mongodb MIR - I'd like to discuss what you need re libv8 and upstream management to address security concerns
[11:19] <ikonia> g105b: you can script that with ssh pretty easy
[11:28] <StathisA_> if i install dropbox by downloading it through WGET ("wget -O dropbox.tar.gz "http://www.dropbox.com/download/?plat=lnx.x86"" will it be updated when i run sudo apt-get update?
[11:28] <StathisA_> or any other software installed like this
[11:28] <ikonia> StathisA_: no
[11:29] <StathisA_> :-(
[11:32] <g105b> StathisA_: to use a package manager to manage packages, the packages need to first be installed by that said package manager.
[12:10] <jamespage> zul, these all build OK with the staging PPA - http://people.canonical.com/~jamespage/ca/havana/
[12:10] <jamespage> aside from warlock which has a python3/dh tantrum
[12:10] <jamespage> looking that that now
[12:12] <zul> jamespage:  +1
[12:17] <zul> jamespage:  we need to add heatclient as well (for horizon)
[12:18] <jamespage> zul, agreed
[12:20] <zul> jamespage:  heh good thing we are not rgb colorblind ;)
[12:20] <jamespage> zul, ?
[12:21] <zul> jamespage:  just thinking about the ca report
[12:21] <jamespage> yeah - right
[12:21] <jamespage> :-)
[12:22] <greppy> g105b: salt or ansible may be an option.
[12:23] <jamespage> zul, can you ack the python-*client packages I just uploaded to the same location please
[12:23] <jamespage> zul, scp sulked about them the first time
[12:24] <jamespage> all three build fine against staging
[12:24] <jamespage> ls
[12:24] <zul> jamespage:  +1 can you pick up ceilometerclient and heatclient as well
[12:24] <jamespage> zul, ack
[12:29] <zul> jamespage: ok they are backported locally i just have to do a build test, almost forgot about python-greenlet
[12:31] <zul> jamespage:  do we want iscsitarget in there as well (trawling saucy-changes for the past month)
[12:31] <jamespage> no
[12:31] <jamespage> zul, its not really worth the delta TBH
[12:32] <zul> jamespage:  ack
[12:39] <sudormrf> Hey guys. Does anyone here have experience with iredmail? I am hosting multiple virtual domains on a single 12.04 LTS server and the webhosting is fine, but I can only seem to get one domain working with the iredmail email. :-/
[12:40] <jamespage> zul, I did heat and ceilometer clients as well
[12:40] <zul> jamespage:  cool...ill do heat as well
[12:40] <jamespage> zul, heat itself?
[12:40] <jamespage> ok
[12:40] <zul> jamespage:  yeah
[12:41] <jamespage> we should get it into the CI then
[12:41] <jamespage> is the branch under ~ubuntu-server-dev yet?
[12:41] <jamespage> zul, ^^
[12:41] <zul> jamespage:  it is. i did it yesterday
[12:42] <jamespage> zul, its in the branch right?
[12:42] <jamespage> still needs creating in the lab then
[12:42] <zul> lp:~ubuntu-server-dev/heat/havana
[12:42] <jamespage> zul, right - understand now!
[12:43] <jamespage> zul, I'll get that CI'ed
[12:43] <zul> i didnt get heatclient its own branch i think
[12:49] <jamespage> zul, added
[12:49] <jamespage> ugh
[12:49] <jamespage> OK
[12:49] <jamespage> that will fail for the moment then
[12:49] <jamespage> lemme sort that out
[12:50] <jamespage> zul, nope - its there
[12:50] <zul> jamespage:  ok
[12:58] <StathisA_> hmmm i got a router which with "http://192.168.0.1/setup.cgi?todo=debug" in a browser enables its debug mode. is there a way to do this from a cli?
[13:04] <hallyn> jdstrand: still will be interesting to see if modprobe not accepting parameters becomes the reason for your host lockup when starting a kvm vm (bug 1203211)
[13:07] <jdstrand> hallyn: it isn't. that bug is fixed in -5 and I still have lockups with it
[13:07] <hallyn> drat
[13:07] <jdstrand> hallyn: apw filed bug #1204005 (he sees it too)
[13:08] <apw> no indeed, it is utterly broken and has been for all of the v3.10 kernels i have tested
[13:08] <apw> clearly noone is using that combination
[13:10] <jamespage> zul, meh
[13:10] <jamespage> python-warlock is not currently cleanly backportable
[13:16] <zul> jamespage:  python3?
[13:17] <jamespage> zul, yeah - the test rules are a bit sucky - gonna fix in saucy to make backporting easier
[13:17] <zul> jamespage:  ack
[13:33] <jdstrand> jamespage: pong re mongodb
[13:33] <jamespage> jdstrand, hey
[13:34] <hachre> StathisA: you just want to access that url? use curl
[13:34] <jdstrand> hey
[13:34] <jamespage> jdstrand, I was about to get in contact with MongoDB upstream about how they are managing their embedded version of libv8 re security issues etc..
[13:34] <StathisA> hachre: Yes, but oh well i thought i could use something already installed...
[13:34] <hachre> StathisA: I guess wget would also work
[13:35] <StathisA> it does, but ends up downloading it as well..:-S
[13:35] <jamespage> jdstrand,  but I wanted to checkin with you first on whether libv8 in mongodb was going to be acceptable for MIR in any form
[13:35] <jamespage> and if so what sort of thing you are looking for re active management of libv8 from mongodb upstream
[13:36] <jamespage> (try to avoiding security -> me -> upstream -> me -> security ping-pong)
[13:36] <jdstrand> jamespage: it would be acceptable if it didn't provide an attack surface, but I don't think the design and intent would allow for that
[13:36] <hachre> StathisA: wget url -O /dev/null
[13:36] <jdstrand> jamespage: which means someone has to update it
[13:37] <jdstrand> jamespage: how long has mongodb been around? will the MREs last through to the April 2019?
[13:37] <jamespage> jdstrand, I would suspect not
[13:37] <jdstrand> I'm very hesitant to allow it, even with upstream saying 'sure we'll do it'
[13:38] <jdstrand> nothing against them (I don't know them at all), but past experience tells me that upstreams quickly lose interest in old software and we are left holding the bag and our users lose
[13:39] <jdstrand> libv8 will literally be unmaintainable within a few months
[13:39] <jamespage> jdstrand, as in I would expect the LTS support period to exceed the active point release schedule from upstream by years
[13:39] <jdstrand> so unless someone is shoving in new upstream versions as security issues are fixed, we are in a bad spot
[13:39] <jamespage> jdstrand, there is another option instead of libv8 but I'm not sure its any better
[13:40] <jamespage> 2.2 series defaults to spidermonkey; the switch to libv8 was made 2.4  but the support is still their for spidermonkey
[13:40] <jamespage> but again I expect that will disappear in 2.6 of suchlike
[13:40] <jdstrand> libv8 changes so much that it would require significant effor to do it ourselves (we went through all this when reviewing the sdk)
[13:41] <jdstrand> spidermonkey is not any better-- we've actively tried to avoid it. iirc, it is less and less interesting to mozilla
[13:41] <jamespage> yeah - that was my guess :-)
[13:41] <jdstrand> of course, that means it doesn't change very much
[13:42] <jamespage> but I guess its not getting much active maintenance either...
[13:42] <jdstrand> (attempt at bad joke-- we would then have to write our own fixes)
[13:42] <jamespage> yeah
[13:42] <zul> jamespage:  http://people.canonical.com/~chucks/ca/
[13:43] <jdstrand> jamespage: an alternative would be to have the package that provides the attack surface in universe
[13:43] <jamespage> jdstrand, so only enabling the scripting engine if that is installed on the server component?
[13:44] <jdstrand> I'm not sure how feasible that is, but it would at least allow mongodb to move forward and give libv8 to users that want it who could control their environment
[13:44] <jdstrand> well, I don't know how the packaging is
[13:44] <jamespage> jdstrand, I'd need to look - I'm not sure that separation exists in the upstream codebase
[13:45] <jdstrand> but you said "libv8 is used to provide the scriptable shell in mongodb; access to the
[13:45] <jdstrand> shell is via the mongo client application"
[13:46] <jdstrand> I don't know where the script interpretation happens, but if it is in the client, you could put the client in universe, or have a client in main without it, and one in universe with it
[13:46] <jamespage> jdstrand, no - its in the server side
[13:46] <jdstrand> if that isn't supported by upstream, you could compile twice: once with scripting and once without
[13:46] <jdstrand> without -> main, with -> univers
[13:46] <jdstrand> e
[13:49] <jamespage> jdstrand, hmm - there is a '--noshell' build option
[13:49] <jamespage> lemme check that out
[13:55] <jamespage> jdstrand, my concern would be that mongodb without the shell for admin is pretty useless
[13:55] <jamespage> but lemme check
[13:59] <zul> jamespage:  ping http://people.canonical.com/~chucks/ca/
[13:59] <jamespage> zul, looking right now
[13:59] <zul> jamespage:  thanks
[14:00] <jamespage> zul, all done using cloud-archive-backport?
[14:00] <zul> jamespage:  except for heat
[14:01] <jamespage> zul, why not heat?
[14:01] <jamespage> oh - I expect you hit the same bug I did with heatclient...
[14:01] <zul> jamespage:  because i got a traceback when i ran it
[14:01] <jamespage> I have a fix for that
[14:01] <zul> jamespage:  cool
[14:05] <jamespage> zul, OK - they look fine
[14:05] <jamespage> zul, I already did eventlet btw
[14:08] <zul> jamespage:  oh
[14:08] <zul> ill get rid of that then
[14:08] <jamespage> zul, did you build test them all first?
[14:09] <zul> jamespage:  i couldnt build the openstack packages because of a newer clients
[14:09] <zul> but they all build
[14:09] <jamespage> zul, hmm
[14:09] <jamespage> ok
[14:28] <jamespage> zul, OK - python-warlock fixed up in saucy
[14:28] <zul> jamespage:  cool have you reviewed rest of the CA stuff prepped
[14:28] <jamespage> zul, yeah - all your stuff looked OK to me
[14:28] <jamespage> +1
[14:28] <zul> jamespage:  cool thanks
[14:29] <jamespage> (don't upload eventlet - I already did)
[14:29] <zul> now to make my internet connection cry
[14:29] <zul> jamespage: ack
[14:30] <jamespage> zul, we still have a kombu ftbfs in staging
[14:30] <jamespage> looking right now - might need an anyjson backport
[14:31] <zul> i have it queued up
[14:31] <zul> jamespage:  im missing something here http://pastebin.ubuntu.com/5904291/
[14:36] <micahg> jamespage: when you get a minute, can you forward the python-warlock fixes to Debian? debian 717469
[14:37] <jamespage> micahg, will do
[14:37] <micahg> thanks
[14:40] <jamespage> zul, urm
[14:41] <jamespage> zul, can you run with -d and --simulate please
[14:44] <zul> http://pastebin.ubuntu.com/5904340/
[14:47] <jamespage> zul, switch back to dput for the time being
[14:47] <jamespage> zul, I think dput-ng has a few problem right now (that I think I fixed locally but negelected to upload - my bad)
[14:48] <zul> jamespage:  ack
[14:51] <zul> jamespage:  btw the new python-warlock will have python3 support upstream (ie: we can drop the patch when a new version is cut)
[14:52] <jamespage> right
[14:52] <jamespage> ok
[15:10] <jamespage> micahg, done
[15:10] <jamespage> zul, http://people.canonical.com/~jamespage/ca/havana/ python-anyjson please
[15:11] <zul> jamespage:  +1
[15:17] <zul> ok uploading finished
[16:41] <adam_g> jamespage, is there a trick to getting python3 stuff backported to precise? i noticed they seem to build fine on buildds in the trunk and CA staging PPAs, but fail for various reasons when trying to do it locally using the backport-package job
[16:41] <jamespage> adam_g, anything specific causing you an issue?
[16:42] <adam_g> jamespage, http://paste.ubuntu.com/5902397/
[16:43] <jamespage> adam_g, oh - I fixed that already in saucy
[16:43] <jamespage> precise has 3.2, saucy has 3.3 so the targets don't work like that for the backport
[16:43] <jamespage> adam_g, the fix is in saucy - just needs a fresh backport
[16:43] <adam_g> jamespage, oh, i see the upload. was trying to get that built last night.
[16:44] <adam_g> awesome :)
[16:49] <zul> jamespage:  http://people.canonical.com/~chucks/ca/
[16:56] <jamespage> zul: +1
[17:17] <zul> adam_g: https://code.launchpad.net/~zulcss/nova/h3-patch-refresh/+merge/176440
[17:24] <jamespage> zul, obvious really but we missed neutron/neutronclient
[17:24]  * jamespage faceplants
[17:26] <zul> jamespage:  DOH!
[17:27] <jamespage> zul, sweeping up right now
[17:27] <zul> jamespage: ack...
[17:28] <adam_g> zul, can you please add some patch header info to that sqlalchemy patch? its still a mystery to me
[17:28] <zul> adam_g:  right
[17:28] <adam_g> https://code.launchpad.net/~gandelman-a/ubuntu/saucy/cinder/dependency_dep8_test/+merge/176441
[17:29] <adam_g> jamespage, yolanda: my first dep8 test, could use some feedback
[17:32] <jamespage> zul: http://people.canonical.com/~jamespage/ca/havana/
[17:33] <zul> jamespage:  why glance?
[17:34] <jamespage> zul, http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/havana_versions.html
[17:34] <jamespage> still out of date
[17:34] <jamespage> and not showing in the PPA either so its valid
[17:34] <zul> jamespage:  doh
[17:34] <zul> jamespage:  +1
[17:35] <zul> adam_g:  pushed
[17:44] <jamespage> zul, I think we need a backport of python-migrate as well for heat
[17:44] <zul> jamespage:  probably
[17:45] <jamespage> zul, ok that lot is all uploaded
[17:47] <zul> cool
[17:47]  * zul goes have lunch
[17:56] <zul> jamespage:  new rule we should upload to the cloud archive relevant stuff when we upload to the regular archive
[18:11] <zul> adam_g:  pushed again
[19:27] <Shogoot> hi people. im a linux newbie so be nice :) im installing u server 12.04. i want to make a upgrade. I f i fo apt-get upgrade, will it install u server 13.04?
[19:28] <cwillu_at_work> apt-get update applies 12.04 updates; it doesn't change the release
[19:28] <Shogoot> update im ok with, but upGrade?
[19:29] <cwillu_at_work> I meant upgrade
[19:29] <Shogoot> ah. ok so it safe then
[19:29] <cwillu_at_work> (update just gets an updated list of packages)
[19:29] <cwillu_at_work> do-release-upgrade will upgrade to the next full release (man do-release-upgrade for basic documentation)
[19:30] <Shogoot> how then do install 13.04 from 12.04? just to know... :)
 do-release-upgrade will upgrade to the next full release (man do-release-upgrade for basic documentation)
[19:30] <Shogoot> ah. sorry i didnt quite read
[19:30] <Shogoot> cwillu_at_work, THANKS!
[19:30] <sarnold> Shogoot: note the --mode setting especially
[19:31] <cwillu_at_work> and makes backups if this matters
[19:31] <Shogoot> rgr
[19:31] <cwillu_at_work> (you should of course already have backups if it matters :p)
[19:36] <Shogoot> its a fresh install
[19:43] <cwillu_at_work> Shogoot, if it's a fresh install, I'd tend towards just installing the new version fresh in the first place
[19:44] <skrite> hey all
[19:45] <sarnold> indeed
[22:16] <genii> Is there some reason the -n of dhclient doesn't work?
[22:55] <jsonperl_> Would you consider 15 servers writing a lot (more than 1k a second) to rsyslog a problem?
[22:57] <sarnold> jsonperl_: that's roughly 15 packets per second of network IO, and most disks can handle ~50MB/s or more.. it feels like a very slow trickle.
[22:57] <sarnold> jsonperl_: I had a firewall system logging at roughly that kind of level, not much, but the drive died after just two years or so. There were some nice grooves worn in the drive platters. :)
[22:58] <sarnold> but that was 12, 13 years back, I hope newer drives are less likely to act like farmers plowing fields.. hehe
[23:02] <jsonperl_> rsyslogd kinda handles file contention though right
[23:02] <jsonperl_> like they're not all writing to the file, their hitting rsyslog, and he takes care of business
[23:02] <thumper> hallyn: you around?
[23:02] <hallyn> thumper: I'm about to run off to dinner
[23:02] <thumper> hallyn: ok, I'll email
[23:02] <sarnold> jsonperl_: right, I'd expect messages to be properly interleaved without scrambling
[23:03] <hallyn> thumper: thanks
[23:05] <jsonperl_> Can anyone think of a situation which would kinda totally bork networking on a machine? I've been trying to figure out an issue on my servers where at some undetermined threshold the machine becomes VERY hard to connect to.
[23:07] <sarnold> jsonperl_: swapping itself to death? too much disk IO swamping usual traffic? unhappy drives? unhappy NICs?
[23:08] <jsonperl_> I've been pouring through sysstat data and I don't see anything of real note
[23:09] <jsonperl_> The only clues that I have so far are, the runq-sz gets much higher than norm, and the load average and cpu usage drops a lot (because people are unable to connect)
[23:12] <sarnold> jsonperl_: maybe look for the wait channel of sleeping processes? I'm not sure that'd lead to high run queue, but if everything is asleep on the same resource, you might have an idea what to work with
[23:12] <jsonperl_> hmm, wait channel?
[23:13] <jsonperl_> what tool would you use to inspect that
[23:13] <sarnold> top or ps, I think..
[23:14] <cwillu_at_work> what's the question?
[23:16] <jsonperl_> Who's question?
[23:18] <cwillu_at_work> to which "top or ps, I think.." was the answer
[23:19] <sarnold> cwillu_at_work: which programs will show the wchan of stalled processes
[23:19] <cwillu_at_work> alt-sysrq-w
[23:19] <sarnold> I know top can do it, but it's not very friendly when servers are slowly dying
[23:19] <cwillu_at_work> then check dmesg
[23:19] <sarnold> oh nice, better for when things are very nearly toast
[23:20] <cwillu_at_work> (note: other sysrq keys are dangerous)
[23:20] <sarnold> I think ps can dump wchan, but it's been ages since I've needed it..
[23:20] <cwillu_at_work> alt-sysrq-w will give you the whole kernel stack trace though
[23:21] <jsonperl_> dmesg will give me the wchan?
[23:21] <cwillu_at_work> alt-sysrq-w, followed by dmesg, will give you more than wchan
[23:21] <sarnold> after hitting that sysrq key, yes
[23:22] <sarnold> if you want to script it up, you can echo w > /proc/sysrq-trigger ; dmesg > /path/to/file
[23:22] <cwillu_at_work> a bit better to cat /dev/ksmg > /path/to/file & echo w > /proc/sysrq-trigger
[23:22] <cwillu_at_work> as that will capture the whole output even if it's bigger than the ring buffer that dmesg is stored in
[23:23] <sarnold> ooh? that'll work even with a running syslog?
[23:23] <cwillu_at_work> I _think_ so
[23:23] <cwillu_at_work> yep, works fine
[23:24] <cwillu_at_work> cat /dev/kmsg | nc cwillu.com 10101 is a trick I use for getting troubleshooting info in #btrfs all the time
[23:27] <sarnold> hahaha, that's clever. :)
[23:28] <cwillu_at_work> it's like netconsole, but not annoying to set up :)
[23:28] <sarnold> probably more reliable too
[23:29] <thumper> hmm...
[23:29] <jsonperl_> cwillu_at_work: so I want to look at "runnable tasks" and see what they're waiting on?
[23:29] <thumper> lets say I have a remote machine... say the precise server in my office
[23:29] <cwillu_at_work> jsonperl_, if you're looking for blocked tasks, you're looking at the ones that aren't runnable
[23:29] <cwillu_at_work> there's one big stack trace for each one
[23:29] <thumper> is there a way I can run something as root on that machine over ssh with one command?
[23:29] <cwillu_at_work> the wchan is the top function in that trace (I believe)
[23:30] <sarnold> thumper: ssh root@remote.machine "uname -a"   :)
[23:30] <cwillu_at_work> thumper, not really, unless you add an ssh key to /root/.ssh/authorized_keys
[23:30] <thumper> does that work with sudo stuff?
[23:30] <thumper> ok...
[23:30] <thumper> next question then
[23:31] <thumper> if I just use ssh as normal
[23:31] <jsonperl_> I'm a little confused on to analyze this: http://pastebin.com/5d83kp1b
[23:31] <thumper> but then execute a script that runs sudo
[23:31] <thumper> will I be prompted nicely?
[23:31] <jsonperl_> Not that i'm seeing my issue, but so I'm prepared when I do :)
[23:31] <thumper> I suppose I can test this pretty trivially
[23:31]  * thumper goes to test
[23:31] <cwillu_at_work> scripts shouldn't call sudo
[23:33] <jsonperl_> I see stats about wait_max, wait_time etc... but not WHAT they're waiting on
[23:33] <cwillu_at_work> jsonperl_, doesn't appear that there's anything blocked
[23:33] <jsonperl_> so I would see diff output if there were blocked processes?
[23:33] <jsonperl_> and what they are blocked from?
[23:35] <cwillu_at_work> yeah; do you know what a kernel oops looks like?
[23:35] <cwillu_at_work> (with the registers and the call trace?)
[23:35] <jsonperl_> nope
[23:36] <sarnold> lucky :)
[23:37] <cwillu_at_work> http://permalink.gmane.org/gmane.comp.file-systems.btrfs/20592 is what you'd see
[23:40] <jsonperl_> So it will show me a trace of every blocked process
[23:41] <cwillu_at_work> yes
[23:41] <cwillu_at_work> you can tell it to give you a trace for _every_ process, but that's mostly just noise
[23:43] <jsonperl_> yea i'm only interested in the ones making my machine unhappy
[23:43] <jsonperl_> and in turn myself (and my girlfriend)