Hacker News Reader

Comment by londons_explore | Hacker News Reader

Sleep/wake/hibernate isn't a feature servers, home routers, or a whole host of other Linux powered commercial devices use. That means it doesn't get much attention from Linux kernel developers.

In turn, the implementation is rather poor. For example, it is impossible to suspend any machine while any ssh directory is mounted. It's been a bug for 10+ years. The bug is architectural and pretty much impossible to fix (Any file or directory read hangs on the SSH connection, and a process can't be paused for hibernation while a non-restartable syscall is running.)

While this kind of architectural bug exists, Linux hibernation will never be good. Fixing that bug properly is probably $500k worth of developer resources. Nobody wants to pay.

View on HN

Are you sure this bug was not resolved long ago?

My laptop auto-mounts a sshfs directory at startup and hibernates with no problem. On resume, the sshfs mount still responds. Having an open shell on that directory is no problem, except that I can't manually unmount a FS being accessed. I remember configuring this when this Debian Testing laptop switched to systemd, years ago.

Not by a long shot.

Simply being mounted isn't a problem. A syscall needs to be hung on a network request.

I regularly hit this issue. Most recent one was last year on 4.19 kernel when using NFS mount. I found the bug report for that one and they said it was fixed in 5.1 or similar.

Beware they were talking about that particular bug. Because as the parent comment says it is architectural issue that can't just be "fixed". It's a whack-a-mole. Developers need to be careful on all the call sites to avoid it. FUSE, NFS, CIFS code is all susceptible to it (and to my horror I've bitten by every single one of them several times in the past).

Android phones, tablets and wearables use sleep quite a bit in addition to desktoo and laptop users. Servers at home too often use wake on lan.

Android is not sleeping in a PC sense, all processes still run.

The opposite is true, Android sleeps unless something explicitly keeps it awake - i.o.w. a process holds a wake lock. Where PC operating systems go to sleep when there is nothing to do for a while, Android sleeps until being woken by user interaction or scheduled timer events. It then performs the task(s) after which it goes to sleep again. A music player on a PC would keep the machine awake, a similarly built player would stop playing after a few seconds on Android unless the developer made sure to schedule wakeups or used the big hammer of requesting a wake lock. Spurious wake locks used to be a common cause of drained batteries until Android started to put limits on background processes.

This is false. Android is famously narcoleptic, if you don't have a kernel wake lock, you sleep. Doze mode is orthogonal to CPU sleep.

This usef to be the case perhaps. Check out documentation on SystemSuspend and doze mode in current Android.

'Cloud-space' seem to be making use of hibernate to some acclaim (e.g. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Hibernat...)

Reply on news.ycombinator.com