I use "wheezy" latest release. The device provides some web service features and supposes to be active 24/7. However if the server wasn't requested for certain amount of time (it is hard to tell exact time), the device seems going to sleep (hopefully not crash). The device connected to net using wi-fi dongle. I found some answers here that a reason of device freezing can be that wi-fi card is going in economy mode, so I followed the instructions and can confirm that the dongle doesn't go in sleep but it starts blinking like getting not attended from computer. it means that device still goes in sleep although wi-fi is awake. The solution as buy another raspberry pi and make it all time pinging sleeping one doesn't work since only being a server getting requests prevent device going to sleep. Trying to poll something from the device doesn't prevent going in sleep mode. I can't actually confirm that device going to sleep. I do not have monitor or keyboard attached, and attempt to attach something issues rebooting of the device. So I am currently out of clues what can issue the behavior. And yes, I applied all remedies preventing OS crashes as no turbo and increased minimal VM memory size.

  • is there anything in /var/log files that shows something is happening, going to sleep, device powering down?
    – kolin
    Commented Jan 31, 2013 at 10:14
  • 3
    For posterity, please note that the pi hardware does not have a potential sleep, suspend, etc. mode. It is either running, or not. If it is plugged in, the power LED will be on either way.
    – goldilocks
    Commented Feb 13, 2013 at 14:54
  • Its not just your wi-fi dongle. I have mine connected through its Ethernet port to serve web requests and it "falls asleep" (or something close to this state) after some time and wont serve requests anymore. If I hit some keys to wake it up it starts working again. But its a pain because the only time I need it to serve requests is when I'm not there to wake it up.
    – user7335
    Commented May 10, 2013 at 2:44
  • I have had this problem of the Pi apparently going to sleep. I can happen every few minutes and can last for about 20 seconds. It is evident when I am trying to access a file via Samba share or when I am SSHing into the Pi - everything just stops. I thought that it might be the Pi that was under load so I ran 'top'. There was no evidence of heavy loading. However, I found that while running 'top', the Pi worked perfectly. Access to files was snappy and SSH connections experienced no outage. So, I can't say what causes this problem but it is not heavy demands on the CPU, on the contrary, the Pi
    – Brian
    Commented Feb 22, 2014 at 20:37

10 Answers 10


I know this is an old question, but it was the first result that came up in my search when I had essentially the same problem on my freshly installed Pi Zero.

I found the key to my answer on this other question, among other sources.

So basically, though the Pi itself apparently doesn't have a sleep mode, individual devices in Linux (including the network adapters) can. When I tried running the command iw wlan0 get power_save as mentioned above, I kept getting an error, at first. That was fixed by updating the OS:

sudo apt-get update && apt-get upgrade

Then I rebooted: sudo reboot now

After that, the iw command verified that power_save mode was indeed turned on. So, I turned it off:

sudo iw wlan0 set power_save off

Since then, everything is fine. My screen will go to sleep, but the network connection stays active, and I'm able to ssh into my Pi even after it's been idle for a while.

  • 1
    Heads up, I needed to use sudo iw dev wlan0 set power_save off (dev needed to be in there)
    – n0nag0n
    Commented Dec 8, 2016 at 20:04
  • This one does not work for me. Even though my wlan device is named wlan0 I get command failed: No such device (-19)
    – birgersp
    Commented May 3, 2017 at 17:46
  • @n0nag0n I can confirm that iw expects either dev or phy as a second argument, depending on how you refer to the wireless device. I'd also add that the command probably has to be run after every reboot. Commented Oct 2, 2018 at 12:34
  • the command to check if power_save is on or off for wlan0 is iw wlan0 get power_save
    – jeffmjack
    Commented Feb 20, 2021 at 16:24

Something is wrong. The pi does not have a "sleep mode".

I've only had my pi a few weeks and have not left it on the whole time, but I intend to eventually and I have left it on for some long stretches. I'm running raspbian, and I have a personal dislike for NetworkManager, lol, so that is disabled. To keep the wifi up, I run a script which pings the router every five seconds. If the ping fails, it kills the current dhcpcd and tries to set up the wifi again every 5 seconds until it succeeds. It logs attempts, and in fact has been up for over 24 hours now without needing to reconnect once, and when I go to ssh in, no problems.

You've already said,"Trying to poll something from the device doesn't prevent going in sleep mode," so my point here is just that mine obviously doesn't have this problem, so something is wrong.

You say it is going "to sleep" but it sounds like you are actually having to reboot. Why do you believe it is sleeping? AFAICT, the pi cannot go to sleep, it does not have any such capability. Googling around, there seems to be some confusion about this from people who are having problems like yours.

Keep in mind that there is a red LED that stays on whenever power is connected, whether the pi is running or not. But the pi is either booted and running or halted, it does not have a sleep, standby, hibernated, etc. mode.

So your pi has either crashed, halted, or is in some kind of erroneous frozen state. Feel to see if it is more than slightly warm, which would indicate the processor is in a perpetual busy loop (one reason it might be on but unresponsive).

I'm guessing that one reason you believe it is sleeping is that an "attempt to attach something issues rebooting of the device". That can happen when the device is completely halted (try it); it's because some devices will cause a brief voltage drop (but see NOTE) when first plugged in, which amounts to unplugging the pi then plugging it back in again -- which as you know, plugging it in causes it to boot. My nano size wifi dongle will do this.

NOTE: Actually our pi were probably made since last august, when the polyfuses were replaced with "shorts" -- I know very little about electronic components or electricity, but evidently the issue WRT to rebooting from usb devices remains the same.

  • Whats the difference between sleep and halted? As I know halted means that the clock is stopped from processor view Does sleep is not the same?
    – E_Blue
    Commented Jan 23, 2021 at 19:02
  • I'm perhaps abusing the term "halted" above because I did not want to use "powered off" (because it implies no power, which it isn't). Strictly speaking "halted" refers to the state of the operating system after it is stopped/turned off. This does not necessarily affect the state of the hardware power wise. However, it is normal to also "power off" the hardware at that point (see -p in man halt), and that's the state I'm referring to. WRT sleep, again, the Pi does not have a sleep state, so there is no comparision.
    – goldilocks
    Commented Jan 23, 2021 at 19:26
  • Of course these are just words and I suppose you can call a chair a table if you want, but sleep generally refers to a hardware state from which the system can be woken and resume operation from the point at which it was put to sleep. Again, there is no such scenario for the Pi. You turn it on, it runs, you shut it down, the end (until the power is cycled).
    – goldilocks
    Commented Jan 23, 2021 at 19:26
  • When you are debugging in a microcontroller you can halt the microcontroller without taking the power off. So, off is no power, halt is no clock to the CPU. Sleep means no power and no clock to the CPU but the peripherals are awake. Look at pheriperals specs page 36 raspberrypi.org/documentation/hardware/raspberrypi/bcm2835/… I don't know if Linux support it but is there.
    – E_Blue
    Commented Jan 25, 2021 at 1:20
  • 1
    I guess we've all been fools...
    – goldilocks
    Commented Jan 27, 2021 at 15:14

I used simple steps and it perfectly worked for me:

  1. Open a root terminal in raspberry Pi. Now you need to edit your script that's starting X. In the default build with lightdm.

  2. Open "lightdm.conf" file located in,


  3. Add below line in to SeatDefault (or Seat:* in newer LightDM versions) section.


    xserver-command=X -s 0 -dpms

  4. Restart your Raspberry Pi.

Now issue should be solved.

Source link: http://chamaras.blogspot.com/2013/03/how-to-deactivate-monitor-sleep-in.html

  • 1
    Welcome to Stack Exchange. Here we expect answers to stand on their own, instead of just being links to external sources. If you can add the relevant information into your answer then it will be much better.
    – Jivings
    Commented Mar 29, 2013 at 17:21
  • Please add the information that is on that site: links are not acceptable answers. Commented Mar 30, 2013 at 5:48
  • 1
    thank you for the best answer, works wonders even in 2017
    – Sverre
    Commented Mar 14, 2017 at 8:34

It sounds like your wifi dongle starts pulsing like a laptop in standby mode, but you haven't confirmed that the Pi itself is shutting down. I experience the same issue.

I've tried this, but haven't had it applied long enough to know if it solved my specific issue: https://raspberrypi.stackexchange.com/a/4518/4271


I'd check for power issues. Attaching devices causing RPI to reboot does not look related to any sort of sleeping mode.

As a quick test, I'd do this - write a small script (python/shall, whatever is handier) and make it send a simple "I am good" email and put it into your crontab to execute every 30 minutes or so and see how it goes.


For me it worked by editing /etc/X11/xinit/xserverrc and changing

exec /usr/bin/X -nolisten tcp "$@"


exec /usr/bin/X -s 0 dpms -nolisten tcp "$@"

I'm using Raspbian “wheezy” and I start my X session with startx.

Source: http://www.raspberrypi.org/forums/viewtopic.php?f=66&t=18200


I wonder if I am experiencing something similar. I would be interested in the chip set your dongle has and the driver you are using?

I have one based on RT3072 chip using the rt2800usb / cfg80211 driver. If I run this in either Master Mode ie an Access Point, or as a normal client to an Access Point/router, it appears as if it goes to sleep and takes a while to respond. I set up my laptop to ping the pi through the wifi adapter at roughly 1 second intervals. I confirmed that in both master and client mode, at times the ping would time out ~ 5-10 seconds in client mode and 5 - 25 seconds in Master mode. In master mode, the timeouts were made a lot worse if I ran the AP in 'n mode' with HT and WMM enabled in hostapd.conf. It was no where near as bad in 'g mode'.

I experimented with another wifi dongle using the RTL8188SU chip with r8712u staging driver. Unfortunately, I could not get this running in Master mode but as a client, it was much more stable than the RT3072 one.

With the 3072 in client mode there was no typical ping delay - they were random from 2ms - 320ms with an occasional timeout. With 8188SU, the typical ping delay was 2-3ms with an occasional delay 166-200ms delay - no observable timeouts. What was particularly strange was that if I opened an ssh session to the pi and set top running at 0.01 sec - so there was quite a lot of cpu load and a 'lot' of wifi traffic, the performance of the 3072 was greatly improved with ping times typically 2-3ms. The loading had a similar effect on the 3072 working in Master mode.

I don't know what is going on but I would be most interested if other users could take the time to do a similar ping test on their pi and report their findings along with their configuration and drivers. It would be interesting if others find poor and random response times are improved by loading the processor/ wifi traffic using top as I did, or say find anything that creates some work and tcp/ip traffic over the wifi.

  • This isn't really an answer, however it has sufficently detailed content that probably wouldn't fit in the comments section of the original question
    – kolin
    Commented Feb 13, 2013 at 9:30
  • Thanks for the hint kolin - I'm new to this forum and haven't figured everything out yet!
    – Ivo
    Commented Feb 13, 2013 at 19:46
  • I tried implementing Stefans answer - turning off power management (for cfg80211/mac80211 drivers you can use iw wlan0 set power_save off), and it made a very big difference in the client mode - random ping delays are now fairly steady at 2-3ms and no timeouts yet. This has not helped with the AP mode (power_save off is not an option with my device), but I don't think it is the source of the problem in AP mode as the ping times are generally stable anyway. Something else is causing the timeouts. It is not clear whether the configuration in the original question was for client or AP mode.
    – Ivo
    Commented Feb 14, 2013 at 4:42

Just for information, I had this issue so looked for a solution here and found this question.

However later on I found out it was just my Pi overheating by the looks of things. Once I took it out of its case. The problem appears to have dissapeared


While I do agree with @goldilocks about the pi device not having a sleep function, the kernel can still powerdown specific I/O while the device is running. It is through this reasoning that you may want to try the following edit in the KBD files and reboot the device:

Make the following edit in /etc/kbd/config: POWERDOWN_TIME=0


I am assuming you define sleeping as the screen turning off. This is what I found to work:

sudo setterm -powersave off
  • The question specifically states "I do not have monitor or keyboard attached". Commented Oct 2, 2018 at 12:23
  • If it is connected to the network, the poster could just ssh in. Why the down vote?
    – Allan Cao
    Commented Nov 29, 2018 at 20:46

Not the answer you're looking for? Browse other questions tagged or ask your own question.