Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Pow is running 99% of my CPU usage #99

Closed
stephenson opened this Issue · 80 comments
@stephenson

... and the app dos not work.

Pow error

@derekprior

Saw this tonight as well. Pow was working fine. I ran a touch tmp/restart.txt, and noticed I could no longer resolve myapp.dev (it would sping for a bit before erroring out). Then my fans took off and I saw Pow eating up 99%

@mkyed

Me too :-/
Killing the pow process brought it back to normal, though.

@timriley

I've had the same thing happen to me a few times. Killing it works to bring it back to normal.

@jeanmartin

Just happened to me too :/

@apacala

Confirmed.

@davetheninja

On top of the above, if the process is still running when the machine goes in to sleep (Mac Air in my case) the system becomes unusable on returning from sleep and a hard reset is required.

@chrismccord

I have also been experiencing this. Twice this week an app has been hanging and pow at 100% CPU. Immediately after trying to kill the process via activity monitor my system locks up completely requiring a hard reboot.

@davetheninja

Any word on a solution for this yet?

@jamilbk

happening to me as well. Giving me wake from sleep issues. I have enough issues with sleep as it is... I don't need to pass these along to my Mac :-|

@zapnap

Same issue happening here. Have not dug in any deeper to see what the underlying issue is though.

@sethvargo

Same for me as well, except I was able to get it up to 99.9%.

Has anyone addressed this issue? I've looked through the source briefly, but I can't seem to find where the leak is coming from..

@jamilbk
@thetron

Also having this issue exactly as described above.

@JonasNielsen

I'm also experiencing this a lot.

@chrismccord

This still hits me 2-3 times per week with the latest version (0.3.1). As a workaround to my hard freezing issue when trying to terminate pow from activity monitor, kill -9 pid does the trick without locking my system up.

@codr

Force quitting seems to have fixed it.

pow immediately restarts after force quitting. I am running 0.3.1 and believe this is related to the sleeping when I open and close my macBook. I think jamillion my be on to something.

@sstephenson
Owner

Hey folks,

I use Pow every day and haven't run into this issue yet. I believe it's only a problem for a subset of Pow users, but I understand how frustrating it must be for those of you who are affected.

Yesterday I was able to see the issue firsthand on my coworker @trevorturk's computer. We opened Activity Monitor and sampled the running Pow process: https://gist.github.com/a61f3f001bac42987203 Then we killed the Pow process to bring things back to normal.

I believe the problem must lie in the Node.js event loop, and I'm afraid further debugging is out of my league at this point. Pow itself does not have any unbounded loops -- everything happens in response to IO events. (You can see the node::IOWatcher::Callback and ev_invoke_pending calls in the trace above.)

So the best thing we can do for now is to collect as much data as possible when the problem occurs. What exactly are you doing when the issue arises? Does Pow have any child processes? What other applications are you running? Etc.

A few people have reported that this seems to be related to sleep/wake, but I suspect it's a red herring, as Trevor's computer had been running for several hours without sleeping.

Thanks for your patience and help.

@indexzero

Attempting to summon people who would be interested: @ry @felixge

@sstephenson, et al. My first thoughts here would be: what version of node.js is everyone running? Considering you haven't run into the issue yet, maybe we'll get lucky: i.e. it's already fixed in 0.4.8 and everyone is just running < 0.4.8.

@sstephenson
Owner

@indexzero Thanks. Pow 0.3.0 and 0.3.1 ship with a Node v0.4.7 x64 binary:

~% file Library/Application\ Support/Pow/Current/bin/node
Library/Application Support/Pow/Current/bin/node: Mach-O 64-bit executable x86_64
~% Library/Application\ Support/Pow/Current/bin/node -v  
v0.4.7

Direct link to the package: http://get.pow.cx/versions/0.3.1.tar.gz

@indexzero

@sstephenson Thanks. Is there anyway to force pow to use another version of node.js? As a first step for people on this thread, upgrading is prudent since v0.4.8 is out (and stable).

Obviously need more data here, but upgrading will reduce the surface area of bugs and potentially fix the issue. Also in v0.4.8 node "No longer compile out asserts and debug statements in normal build." so debugging will be a little easier.

If my memory serves me you can see that output from debug=true node myprogram.js. This will help us find where in the javascript boundaries we are entering this state.

@sstephenson
Owner

@indexzero I can't seem to find any documentation for the debug=true environment variable. Got a link?

I'll push out a Pow 0.3.2 release with Node 0.4.8 soon.

@indexzero

@sstephenson It is not well documented, but if you look at this code: https://github.com/joyent/node/blob/master/lib/http.js#L32

if (process.env.NODE_DEBUG && /http/.test(process.env.NODE_DEBUG)) {
  debug = function(x) { console.error('HTTP: %s', x); };
} else {
  debug = function() { };
}

So it looks like I was wrong. It's NODE_DEBUG=true node myapp.js

@josh

@indexzero You need to specify the module in the ENV var so. NODE_DEBUG=http,nack would output debug lines for the node's http module and nack.

@indexzero

@josh Thanks!

@sstephenson would be really helpful as we dive into this issue to enable this node debugging from pow.

@ry
ry commented

It sounds like its sitting in a busy loop caused by level-triggered actions for an IOWatcher. i.e. the kernel keeps waking it up saying "that fd is writable!" but Pow is not disabling it somehow. My impression for the above discussion that this is a rare event? Understanding where in javascript it's looping would help.

If the process enters this state you can kill it with SIGUSR1 and connect to it on port 5858 with the debugger - which will allow you to get a javascript stacktrace.

@johnpaulashenfelter

This bit me a lot this morning -- node 0.4.8. Force-quit worked fine

@indexzero

@johnpaulashenfelter Thanks. Did you try hooking up the debugger?

@semaperepelitsa

I also had this issue on sleep-disabled Mac.

@chrismccord

Upgrading to node v0.4.8 has not alleviated this issue for me. I have been hit with it twice today. Once when firing off a new page request and a second time spontaneously.

@sstephenson
Owner

Alright, this issue just bit me. I killed Pow with USR1 and was able to connect via ndb:

ndb> bt  

  #00 dn_find(src=#<Buffer>, domain=0, msg=#<Buffer>, dnptrs=#<Array>, ndnptr=0, lastdnptr=2) /Users/sam/Dropbox/Projects/pow/node_modules/ndns/lib/ndns.js line 1109 column 4 (position 25451)
  #01 ns_name_pack(src=#<Buffer>, srcn=0, dst=#<Buffer>, dstn=22, dstsiz=65513, dnptrs=#<Array>, lastdnptr=25) /Users/sam/Dropbox/Projects/pow/node_modules/ndns/lib/ndns.js line 832 column 8 (position 20331)
  #02 ns_newmsg_rr(handle=#<ns_newmsg>, sect=1, name=#<Buffer>, type=1, rr_class=1, ttl=600, rdlen=4, rdata=#<Buffer>) /Users/sam/Dropbox/Projects/pow/node_modules/ndns/lib/ndns.js line 1663 column 6 (position 37214)
  #03 #<ServerResponse>.writeOnce(buf=#<Buffer>, bufsiz=65535) /Users/sam/Dropbox/Projects/pow/node_modules/ndns/lib/ndns.js line 2526 column 9 (position 56344)
  #04 #<ServerResponse>.sendTo(socket=#<DnsServer>, port=65466, host=127.0.0.1) /Users/sam/Dropbox/Projects/pow/node_modules/ndns/lib/ndns.js line 2540 column 16 (position 56645)
  #05 #<ServerResponse>.send() /Users/sam/Dropbox/Projects/pow/node_modules/ndns/lib/ndns.js line 2605 column 7 (position 58099)
  #06 #<DnsServer>.handleRequest(req=#<ServerRequest>, res=#<ServerResponse>) /Users/sam/Dropbox/Projects/pow/lib/dns_server.js line 37 column 18 (position 1657)
  #07 #<DnsServer>.handleRequest(#<ServerRequest>, #<ServerResponse>) /Users/sam/Dropbox/Projects/pow/lib/dns_server.js line 3 column 63 (position 162)
  #08 #<DnsServer>.emit(type=request, #<ServerRequest>, #<ServerResponse>) events.js line 67 column 17 (position 2560)
  #09 #<DnsServer>.messageListener(msg=#<Buffer>, rinfo=#<Object>) /Users/sam/Dropbox/Projects/pow/node_modules/ndns/lib/ndns.js line 2640 column 8 (position 58906)

So it looks like this might be an issue with the bundled ndns library. I'll take a closer look soon.

@abachman

Any updates on this issue?

@bradhaydon

I am also having this issue. Any resolution yet?

@sethvargo

I've been using my gem, powify to manage the server... When I notice that Pow is using a bunch of CPU, I just restart the server (powify server restart) and it's back to normal in about 15 seconds. This is, of course, not a long-term fix and doesn't address the root of the problem... It is, however, easier than opening up activity monitor and/or killing the process manually.

@bradhaydon
@sethvargo

No problem!

@sstephenson sstephenson referenced this issue from a commit
@sstephenson sstephenson Check for falsiness rather than != 0 in dn_find and ns_name_pack to a…
…void potential infinite loops. References #99.
bb15da3
@jwarchol

Had this happen again after upgrading to 0.3.2. Killed pow and the next launch of it seems happy. Thanks for continuing to try and solve this.

@sstephenson
Owner

If you see this happen again, please try to connect with the debugger and get a backtrace.

$ npm install -g ndb
$ kill -USR1 $insert_pow_pid_here
$ ndb
ndb> bt
@jwarchol

Absolutely, will do!

@abachman

I just upgraded about 30 minutes ago and got it again, this is the result of the bt command:

#00 dn_find(src=#<Buffer>, domain=0, msg=#<Buffer>, dnptrs=#<Array>, ndnptr=0, lastdnptr=2) /Users/adam/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 1109 column 4 (position 25436)
#01 ns_name_pack(src=#<Buffer>, srcn=0, dst=#<Buffer>, dstn=26, dstsiz=65509, dnptrs=#<Array>, lastdnptr=25) /Users/adam/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 832 column 8 (position 20326)
#02 ns_newmsg_rr(handle=#<ns_newmsg>, sect=1, name=#<Buffer>, type=1, rr_class=1, ttl=600, rdlen=4, rdata=#<Buffer>) /Users/adam/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 1663 column 6 (position 37192)
#03 #<ServerResponse>.writeOnce(buf=#<Buffer>, bufsiz=65535) /Users/adam/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 2526 column 9 (position 56322)
#04 #<ServerResponse>.sendTo(socket=#<DnsServer>, port=64943, host=127.0.0.1) /Users/adam/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 2540 column 16 (position 56623)
#05 #<ServerResponse>.send() /Users/adam/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 2605 column 7 (position 58077)
#06 #<DnsServer>.handleRequest(req=#<ServerRequest>, res=#<ServerResponse>) /Users/adam/Library/Application Support/Pow/Versions/0.3.2/lib/dns_server.js line 37 column 18 (position 1656)
#07 #<DnsServer>.handleRequest(#<ServerRequest>, #<ServerResponse>) /Users/adam/Library/Application Support/Pow/Versions/0.3.2/lib/dns_server.js line 3 column 63 (position 162)
#08 #<DnsServer>.emit(type=request, #<ServerRequest>, #<ServerResponse>) events.js line 67 column 17 (position 2560)
#09 #<DnsServer>.messageListener(msg=#<Buffer>, rinfo=#<Object>) /Users/adam/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 2640 column 8 (position 58884)
@sstephenson
Owner

@abachman, much appreciated. Back to the drawing board.

@chrismccord

I upgraded a couple days ago and just got hit with this again.

#00 dn_find(src=#<Buffer>, domain=0, msg=#<Buffer>, dnptrs=#<Array>, ndnptr=0, lastdnptr=2) /Users/chris/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 1109 column 4 (position 25436)
#01 ns_name_pack(src=#<Buffer>, srcn=0, dst=#<Buffer>, dstn=28, dstsiz=65507, dnptrs=#<Array>, lastdnptr=25) /Users/chris/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 832 column 8 (position 20326)
#02 ns_newmsg_rr(handle=#<ns_newmsg>, sect=1, name=#<Buffer>, type=1, rr_class=1, ttl=600, rdlen=4, rdata=#<Buffer>) /Users/chris/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 1663 column 6 (position 37192)
#03 #<ServerResponse>.writeOnce(buf=#<Buffer>, bufsiz=65535) /Users/chris/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 2526 column 9 (position 56322)
#04 #<ServerResponse>.sendTo(socket=#<DnsServer>, port=58657, host=127.0.0.1) /Users/chris/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 2540 column 16 (position 56623)
#05 #<ServerResponse>.send() /Users/chris/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 2605 column 7 (position 58077)
#06 #<DnsServer>.handleRequest(req=#<ServerRequest>, res=#<ServerResponse>) /Users/chris/Library/Application Support/Pow/Versions/0.3.2/lib/dns_server.js line 37 column 18 (position 1656)
#07 #<DnsServer>.handleRequest(#<ServerRequest>, #<ServerResponse>) /Users/chris/Library/Application Support/Pow/Versions/0.3.2/lib/dns_server.js line 3 column 63 (position 162)
#08 #<DnsServer>.emit(type=request, #<ServerRequest>, #<ServerResponse>) events.js line 67 column 17 (position 2560)
#09 #<DnsServer>.messageListener(msg=#<Buffer>, rinfo=#<Object>) /Users/chris/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 2640 column 8 (position 58884)
@rubiety

I'm having this issue as well; glad we're getting close to solving it.

@chrismccord

Hit with this again today. This backtrack may be redundant with yesterday's but here goes:

#00 dn_find(src=#<Buffer>, domain=0, msg=#<Buffer>, dnptrs=#<Array>, ndnptr=0, lastdnptr=2) /Users/chris/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 1109 column 4 (position 25436)
#01 ns_name_pack(src=#<Buffer>, srcn=0, dst=#<Buffer>, dstn=22, dstsiz=65513, dnptrs=#<Array>, lastdnptr=25) /Users/chris/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 832 column 8 (position 20326)
#02 ns_newmsg_rr(handle=#<ns_newmsg>, sect=1, name=#<Buffer>, type=1, rr_class=1, ttl=600, rdlen=4, rdata=#<Buffer>) /Users/chris/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 1663 column 6 (position 37192)
#03 #<ServerResponse>.writeOnce(buf=#<Buffer>, bufsiz=65535) /Users/chris/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 2526 column 9 (position 56322)
#04 #<ServerResponse>.sendTo(socket=#<DnsServer>, port=56835, host=127.0.0.1) /Users/chris/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 2540 column 16 (position 56623)
#05 #<ServerResponse>.send() /Users/chris/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 2605 column 7 (position 58077)
#06 #<DnsServer>.handleRequest(req=#<ServerRequest>, res=#<ServerResponse>) /Users/chris/Library/Application Support/Pow/Versions/0.3.2/lib/dns_server.js line 37 column 18 (position 1656)
#07 #<DnsServer>.handleRequest(#<ServerRequest>, #<ServerResponse>) /Users/chris/Library/Application Support/Pow/Versions/0.3.2/lib/dns_server.js line 3 column 63 (position 162)
#08 #<DnsServer>.emit(type=request, #<ServerRequest>, #<ServerResponse>) events.js line 67 column 17 (position 2560)
#09 #<DnsServer>.messageListener(msg=#<Buffer>, rinfo=#<Object>) /Users/chris/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 2640 column 8 (position 58884)
@chrismccord

Third time this week:

#00 dn_find(src=#<Buffer>, domain=0, msg=#<Buffer>, dnptrs=#<Array>, ndnptr=0, lastdnptr=2) /Users/chris/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 1109 column 4 (position 25436)
#01 ns_name_pack(src=#<Buffer>, srcn=0, dst=#<Buffer>, dstn=22, dstsiz=65513, dnptrs=#<Array>, lastdnptr=25) /Users/chris/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 832 column 8 (position 20326)
#02 ns_newmsg_rr(handle=#<ns_newmsg>, sect=1, name=#<Buffer>, type=1, rr_class=1, ttl=600, rdlen=4, rdata=#<Buffer>) /Users/chris/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 1663 column 6 (position 37192)
#03 #<ServerResponse>.writeOnce(buf=#<Buffer>, bufsiz=65535) /Users/chris/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 2526 column 9 (position 56322)
#04 #<ServerResponse>.sendTo(socket=#<DnsServer>, port=57066, host=127.0.0.1) /Users/chris/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 2540 column 16 (position 56623)
#05 #<ServerResponse>.send() /Users/chris/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 2605 column 7 (position 58077)
#06 #<DnsServer>.handleRequest(req=#<ServerRequest>, res=#<ServerResponse>) /Users/chris/Library/Application Support/Pow/Versions/0.3.2/lib/dns_server.js line 37 column 18 (position 1656)
#07 #<DnsServer>.handleRequest(#<ServerRequest>, #<ServerResponse>) /Users/chris/Library/Application Support/Pow/Versions/0.3.2/lib/dns_server.js line 3 column 63 (position 162)
#08 #<DnsServer>.emit(type=request, #<ServerRequest>, #<ServerResponse>) events.js line 67 column 17 (position 2560)
#09 #<DnsServer>.messageListener(msg=#<Buffer>, rinfo=#<Object>) /Users/chris/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 2640 column 8 (position 58884)
@chris

I see this too. I'm unable to kill the process successfully with USR1 though, and haven't been able to get a backtrace. Will continue to try. I've seen this with 0.3.1 and 0.3.2, am on MacOS X Lion, on latest MacBook Air, using Pow with a Rails 3.0.4 app.

@jimfmunro

This occurred for me this morning. Using firefox primarily for a single test site. Killing the process didn't seem to resolve it though. It restarted back at 99% and stayed there. I did not notice any network or power-related trigger, it just started on its own. :/

#00 dn_find(src=#, domain=0, msg=#, dnptrs=#, ndnptr=0, lastdnptr=2) /Users/Jim/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 1109 column 4 (position 25436)
#1 ns_name_pack(src=#, srcn=0, dst=#, dstn=28, dstsiz=65507, dnptrs=#, lastdnptr=25) /Users/Jim/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 832 column 8 (position 20326)
#2 ns_newmsg_rr(handle=#, sect=1, name=#, type=1, rr_class=1, ttl=600, rdlen=4, rdata=#) /Users/Jim/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 1663 column 6 (position 37192)
#3 #.writeOnce(buf=#, bufsiz=65535) /Users/Jim/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 2526 column 9 (position 56322)
#4 #.sendTo(socket=#, port=57944, host=127.0.0.1) /Users/Jim/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 2540 column 16 (position 56623)
#5 #.send() /Users/Jim/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 2605 column 7 (position 58077)
#6 #.handleRequest(req=#, res=#) /Users/Jim/Library/Application Support/Pow/Versions/0.3.2/lib/dns_server.js line 37 column 18 (position 1656)
#7 #.handleRequest(#, #) /Users/Jim/Library/Application Support/Pow/Versions/0.3.2/lib/dns_server.js line 3 column 63 (position 162)
#8 #.emit(type=request, #, #) events.js line 67 column 17 (position 2560)
#9 #.messageListener(msg=#, rinfo=#) /Users/Jim/Library/Application Support/Pow/Versions/0.3.2/node_modules/ndns/lib/ndns.js line 2640 column 8 (position 58884)

@flippyhead

This happens 2 - 5 times a day for me now. Almost to the point of switching back to webrick or passenger.

@jimryan

This is happening to me often as well, maybe 1-2 times per day, I'm on 0.3.1. I'll update to 0.3.2 and get a trace if/when it happens again.

@thibaudgg

Yeah, same for me it's happens almost once a day... painful :( (OS X 10.7.1, Ruby 1.9.2 (rvm), Pow 0.3.2)

@sstephenson
Owner

I've pushed out a special prerelease build of Pow for those who continue to be plagued by this issue. In this build, ndns has been swapped out with the much simpler dnsserver.js library, which will hopefully solve the problem once and for all.

To install, run this command:

curl get.pow.cx | VERSION=0.4.0-pre sh

and report back here if you continue to have trouble. We'll roll this into the final 0.4.0 release if all goes well.

@eddorre

I run into at least twice a day and sometimes back to back (after killing and restarting the pow process). Looking forward to testing this out.

@abachman

Thanks for staying on this @sstephenson, I've been digging pow and recommending it to other devs.

I'll post a backtrace if anything comes up.

@morganick

@sstephenson Just made it through my second day without this problem after updating to 0.4.0-pre. I'm hearing similar results from others in the office.

Thanks for all of your hard work.

@jimryan

Yes @sstephenson same here, second day without this problem. Thank you so much for resolving this!

@kylemathews

0.4.0-pre is working great for me so far too. Nice job! It's great to be using pow again.

@davetheninja

Just installed the 0.4.0-pre.

Fingers crossed!

@jimryan
@semaperepelitsa

I haven't installed 0.4 since this happens rarely to me. Here is my backtrace for 0.3.2:

#00 dn_find(src=#<Buffer>, domain=0, msg=#<Buffer>, dnptrs=#<Array>, ndnptr=0, lastdnptr=2) /usr/local/Cellar/pow/0.3.2/pow/node_modules/ndns/lib/ndns.js line 1109 column 4 (position 25436)
#01 ns_name_pack(src=#<Buffer>, srcn=0, dst=#<Buffer>, dstn=23, dstsiz=65512, dnptrs=#<Array>, lastdnptr=25) /usr/local/Cellar/pow/0.3.2/pow/node_modules/ndns/lib/ndns.js line 832 column 8 (position 20326)
#02 ns_newmsg_rr(handle=#<ns_newmsg>, sect=1, name=#<Buffer>, type=1, rr_class=1, ttl=600, rdlen=4, rdata=#<Buffer>) /usr/local/Cellar/pow/0.3.2/pow/node_modules/ndns/lib/ndns.js line 1663 column 6 (position 37192)
#03 #<ServerResponse>.writeOnce(buf=#<Buffer>, bufsiz=65535) /usr/local/Cellar/pow/0.3.2/pow/node_modules/ndns/lib/ndns.js line 2526 column 9 (position 56322)
#04 #<ServerResponse>.sendTo(socket=#<DnsServer>, port=50233, host=127.0.0.1) /usr/local/Cellar/pow/0.3.2/pow/node_modules/ndns/lib/ndns.js line 2540 column 16 (position 56623)
#05 #<ServerResponse>.send() /usr/local/Cellar/pow/0.3.2/pow/node_modules/ndns/lib/ndns.js line 2605 column 7 (position 58077)
#06 #<DnsServer>.handleRequest(req=#<ServerRequest>, res=#<ServerResponse>) /usr/local/Cellar/pow/0.3.2/pow/lib/dns_server.js line 37 column 18 (position 1656)
#07 #<DnsServer>.handleRequest(#<ServerRequest>, #<ServerResponse>) /usr/local/Cellar/pow/0.3.2/pow/lib/dns_server.js line 3 column 63 (position 162)
#08 #<DnsServer>.emit(type=request, #<ServerRequest>, #<ServerResponse>) events.js line 67 column 17 (position 2560)
#09 #<DnsServer>.messageListener(msg=#<Buffer>, rinfo=#<Object>) /usr/local/Cellar/pow/0.3.2/pow/node_modules/ndns/lib/ndns.js line 2640 column 8 (position 58884)
@alexlod

I've been using Pow in total for just 3 days. I upgraded to 0.4.0-pre a minute ago. It's running flawlessly. Thanks!

@thegrubbsian

I am having this CPU issue intermittently. I'm running on Node 0.4.12 and it's happened off and on since 0.4.0. Has pow been tested with 0.6.0? Any chance an upgrade would fix this issue?

@rbazinet

I have been plagued by this issue for a while now, updated to 0.4.0-pre a couple weeks ago and it is running flawlessly. I have not had to kill pow manually since.

I just figured I would give that feedback.

@nifl

I had this issue affecting a POW install on my previous laptop. One afternoon I stepped away from my machine for several hours and returned to a fried logic board. I can't be certain POW caused the issue but considering I was having frequent issues with it going nutso, it's suspect. If it is the cause, then this issue is serious and the name "pow" is perfect.

@roadhead

Happened to me with 0.3.2 (cpu pegged at 100%) but not so far with 0.4.0-pre.

@cabgfx

I've had this issue for a while, on seemingly random occassions.
Sometimes, pow is just slow (not just when the process is idle), but doesn't always ramp up the CPU usage.
Activity Monitor > Force Quit pow always fixes it, I've never experienced issues where the computer locked up.

I use the powder gem, as well as:

  • OS X 10.7.3 - latest Air
  • RVM 1.10.2
  • MRI 1.9.2-p290 (it also happened on 1.8)
  • RubyGems 1.8.16
  • Rails 3.2.1
  • Pow 0.3.2 (and latest powder as well, currently 0.1.7)

I'm a bit unsure about how to provide a stack-trace or similar debugging aids?

Thanks for an awesome piece of software, btw! :thumbsup:

@eddorre

@cabgfx,

Use the 0.4.0-pre release.

curl get.pow.cx | VERSION=0.4.0-pre sh

@eddorre

@sstephenson I think it might be time to release the 0.4.0-pre release as the main release.

The 0.3.2 release is clearly broken yet the documentation on the site still refers to this version. It seems to be confusing people that are new to the project.

The 0.4.0-pre release has been tested by working developers for 5 months.

Judging from the lack of comments about the 0.4.0-pre release in here, I would say that it's pretty stable.

What's the chance of cutting a 0.4.0 release and making that the official version soon?

@semaperepelitsa

0.4.0-pre works fine for me, +1 for releasing it.

@hmans

:+1: for releasing 0.4.0!

@tanordheim

Been running 0.4.0-pre for several months now to get around these issues, haven't had any problems what so ever. +1 for releasing 0.4.0.

@cabgfx

@eddorre - thanks, I'll be sure to post back with how it works out.

@jimryan

+1 Been running solid for months as well. Much more stable than current release.

@cabgfx

Running on 0.4.0-pre for the past 4 days seems to have killed all issues mentioned earlier in thread! Thanks :heart:

@bashcoder

So glad I discovered this thread and upgraded to 0.4.0-pre. I had been having a lot of what @cabgfx describes, and the runway processes described elsewhere here.

I was back to webrick and wearing out ctrl-c. Now I can resume using https://github.com/guard/guard-pow

I echo recommendations to release this as the current release version. This is issue #99 on this project and it used 99% of my CPU. So I guess I could say that I had "99 problems, but this glitch ain't one." (yes, that just happened.)

@chapati23

+1 for 0.4.0

@JeanMertz

I wonder why this hasn't been released as 0.4.0 as well. I'd like to install pow through homebrew, but it only supports the latest 0.3.2.

@robert-stuttaford

"Pow is a zero-config Rack server for Mac OS X. Have it serving your apps locally in under a minute."

suuuuuure it will. you weren't clear that this 'minute' was on the arse-end of an hour's worth of hunt-the-bugfix!

+1 billionty billion: release 0.4 as final.

@DouweM

Another +1 for releasing 0.4.0 as final. The 99% issue had been occurring multiple times a day for me, and since installing 0.4.0-pre everything's been fine.

@derek-watson

+1 Eleventy Billion

@onetruth

Ah, thnx for the 0.4.0-pre. POW was running fine until recently, which led me here. Thanks!

@sstephenson sstephenson closed this
@supermarin

Updated POW, still have the problem after the system wakes up from sleep.
Reproduced it 2 times yesterday/today

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.