Skip to content
This repository

Pow is running 99% of my CPU usage #99

Closed
stephenson opened this Issue April 13, 2011 · 80 comments
Niklas Stephenson

... and the app dos not work.

Pow error

Derek Prior

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%

Michael Kyed
mkyed commented April 14, 2011

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

Tim Riley

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

Jan Schwenzien

Just happened to me too :/

Adrian Pacała

Confirmed.

Dave the Ninja

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.

Chris McCord

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.

Dave the Ninja

Any word on a solution for this yet?

Jamil
jamilbk commented May 03, 2011

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 :-|

Nick Plante
zapnap commented May 04, 2011

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

Seth Vargo

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..

Jamil
jamilbk commented May 06, 2011
Nicholas Bruning
thetron commented May 17, 2011

Also having this issue exactly as described above.

Jonas Bruun Nielsen

I'm also experiencing this a lot.

Chris McCord

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.

Cody Coljee-Gray
codr commented June 02, 2011

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.

Sam Stephenson
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.

Charlie Robbins

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.

Sam Stephenson
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

Charlie Robbins

@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.

Sam Stephenson
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.

Charlie Robbins

@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

Joshua Peek
Owner
josh commented June 02, 2011

@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.

Charlie Robbins

@josh Thanks!

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

ry
ry commented June 02, 2011

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.

John Paul Ashenfelter

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

Charlie Robbins

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

Semyon Perepelitsa

I also had this issue on sleep-disabled Mac.

Chris McCord

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.

Sam Stephenson
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.

Adam Bachman

Any updates on this issue?

Brad Haydon

I am also having this issue. Any resolution yet?

Seth Vargo

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.

Brad Haydon
Seth Vargo

No problem!

Sam Stephenson sstephenson referenced this issue from a commit August 13, 2011
Sam Stephenson Check for falsiness rather than != 0 in dn_find and ns_name_pack to a…
…void potential infinite loops. References #99.
bb15da3
Joshua Warchol

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.

Sam Stephenson
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
Joshua Warchol

Absolutely, will do!

Adam Bachman

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)
Sam Stephenson
Owner

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

Chris McCord

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)
Ben Hughes

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

Chris McCord

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)
Chris McCord

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 Bailey

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.

Jim Munro

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)

Peter T. Brown

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

Jim Ryan

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.

Thibaud Guillaume-Gentil

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)

Sam Stephenson

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.

Carlos Rodriguez

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.

Adam Bachman

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.

Nick Morgan

@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.

Jim Ryan

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

Kyle Mathews

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

Dave the Ninja

Just installed the 0.4.0-pre.

Fingers crossed!

Jim Ryan
Semyon Perepelitsa

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)
Alex L

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!

JC Grubbs

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?

Rob Bazinet

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.

Jörg Bartels

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.

Rohit Sankaran

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

Casper Klenz-Kitenge

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:

Carlos Rodriguez

@cabgfx,

Use the 0.4.0-pre release.

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

Carlos Rodriguez

@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?

Semyon Perepelitsa

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

Hendrik Mans

:+1: for releasing 0.4.0!

Trond Arve Nordheim

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.

Casper Klenz-Kitenge

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

Jim Ryan

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

Casper Klenz-Kitenge

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.)

pshizzle

+1 for 0.4.0

Jean Mertz

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.

Douwe Maan

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!

Sam Stephenson sstephenson closed this June 04, 2012
Marin Usalj

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.