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.
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.
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.
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: http://raspberrypi.stackexchange.com/a/4518/4271
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.
I used simple steps and it perfectly worked for me:
Now issue should be solved.