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 Jan 31 '13 at 10:14
-
3For 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 Feb 13 '13 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. – May 10 '13 at 02: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 Feb 22 '14 at 20:37
10 Answers
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.
- 271
- 2
- 4
-
1Heads up, I needed to use `sudo iw dev wlan0 set power_save off` (dev needed to be in there) – n0nag0n Dec 08 '16 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 May 03 '17 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. – Dmitry Grigoryev Oct 02 '18 at 12:34
-
the command to check if power_save is on or off for wlan0 is `iw wlan0 get power_save` – jeffmjack Feb 20 '21 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.
- 56,430
- 17
- 109
- 217
-
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 Jan 23 '21 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 Jan 23 '21 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 Jan 23 '21 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 https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2835/README.md I don't know if Linux support it but is there. – E_Blue Jan 25 '21 at 01:20
-
The Pi SoC is not a microcontroller, and conventionally when discussing microprocessor systems "sleep" and "hibernate" refer to *power management* features, and the Pi does not have them in that sense; **there is no way to restart the SoC with software alone.** If you believe there is some obscure work-around that no one has bothered with over the past 8-9 years because those 10+ million users just weren't interested enough, then please find someone to implement it because having been a mod here for most of that time, I can tell you that a high percentage of them would be very interested. – goldilocks Jan 25 '21 at 15:20
-
As I see it if you stop the clock to the CPU that is possible, according to that PDF, and keep the RAM refreshed I don't see why not to be possible to resume by reactivating the clock to the CPU with an interrupt. I think I read that pins 24 and 25 can do that. – E_Blue Jan 26 '21 at 21:56
-
1
-
Yet, Raspberry Pi OS (née Raspbian) includes `/etc/systemd/sleep.conf` with all of its default settings that imply, "Yeah - there's a sleep mode in RPi". I feel a rant coming on LOL. *"Still crazy after all these years..."* :) – Seamus Jul 12 '21 at 19:29
-
That's just a stock part of systemd. It hasn't been modified for the Pi at all. All the options are commented out; I have the exact same file on my Fedora 33 deskop. And on various cloud purveyor server instances that can't possibly be put to sleep -- they're containers, virtual systems. – goldilocks Jul 13 '21 at 15:24
I used simple steps and it perfectly worked for me:
Open a root terminal in raspberry Pi. Now you need to edit your script that's starting X. In the default build with lightdm.
Open "lightdm.conf" file located in,
/etc/lightdm/lightdm.conf
Add below line in to
SeatDefault(orSeat:*in newer LightDM versions) section.[SeatDefaults]
xserver-command=X -s 0 -dpms
Restart your Raspberry Pi.
Now issue should be solved.
Source link: http://chamaras.blogspot.com/2013/03/how-to-deactivate-monitor-sleep-in.html
- 105
- 6
- 97
- 1
-
1Welcome 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 Mar 29 '13 at 17:21
-
Please add the information that is on that site: links are *not* acceptable answers. – xxmbabanexx Mar 30 '13 at 05:48
-
1
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
- 151
- 1
- 3
For me it worked by editing /etc/X11/xinit/xserverrc and changing
exec /usr/bin/X -nolisten tcp "$@"
by
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
- 505
- 2
- 5
- 17
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.
- 942
- 1
- 7
- 15
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
- 21
- 1
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 Feb 13 '13 at 09:30
-
Thanks for the hint kolin - I'm new to this forum and haven't figured everything out yet! – Ivo Feb 13 '13 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 Feb 14 '13 at 04:42
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
- 99
- 1
I am assuming you define sleeping as the screen turning off. This is what I found to work:
sudo setterm -powersave off
- 99
- 2
-
The question specifically states "I do not have monitor or keyboard attached". – Dmitry Grigoryev Oct 02 '18 at 12:23
-
If it is connected to the network, the poster could just ssh in. Why the down vote? – Allan Cao Nov 29 '18 at 20:46