search

mobile-shell / mosh

Mobile Shell
https://mosh.org
GNU General Public License v3.0
12.67k stars 738 forks source link

Mac OS X sleeps (!) while running mosh #47

Open keithw opened 12 years ago

keithw commented 12 years ago

When logged in remotely with mosh to a Macintosh, OS X seems to go to sleep (and we start getting the "Last contact" countup). It doesn't even respond to pings.

SSHing to the machine seems to wake it up.

It looks like this is a feature -- "pmset -g" shows a sleep time of "10" when not logged in with SSH, and a sleep of "0" (disabled) when logged in with SSH. (I think "ttyskeepawake" is what makes SSH inhibit sleeping.)

Is it possible to have mosh-server also set the sleep time to be 0 when there is a user logged in? Unfortunately pmset requires root... Starting a screen did update utmp but didn't disable "sleep".

keithw commented 12 years ago

Appears intractable for now. WONTFIX

saurik commented 12 years ago

I cannot replicate that logging in with ssh causes "sleep" to be set to 0: logging in with ssh seems to leave sleep set to whatever it previously had been set to, but the computer likely does not go to sleep because there is an active terminal (based on description of ttyskeepawake).

ttyskeepawake - prevent idle system sleep when any tty (e.g. remote login session) is 'active'. A tty is 'inactive' only when its idle time exceeds the system sleep timer. (value = 0/1)

Are you certain you weren't accidentally looking at the report under two different power situations, such as on battery and when charging? I don't see any special code in Apple's fork of OpenSSH that would cause it to be messing directly with the power management subsystem.

Put differently: when you were in that screen session, did the computer actually go to sleep, or did it simply report that the sleep timer was set to 10? (As far as I can tell, that is just the current settings that you have set in Preferences, and would not update that dynamically.)

keithw commented 12 years ago

Yes, if I log in with ssh and run pmset -g, I get:

Active Profiles: AC Power 2* Currently in use: autorestart 0 powerbutton 1 halfdim 1 panicrestart 157680000 hibernatefile /var/vm/sleepimage networkoversleep 0 disksleep 10 sleep 0 (imposed by 21) hibernatemode 0 ttyskeepawake 1 displaysleep 10 womp 1

If I mosh in and run the same command:

Active Profiles: AC Power 2* Currently in use: autorestart 0 powerbutton 1 halfdim 1 panicrestart 157680000 hibernatefile /var/vm/sleepimage networkoversleep 0 disksleep 10 sleep 10 hibernatemode 0 ttyskeepawake 1 displaysleep 10 womp 1

I believe the machine is a desktop iMac, Darwin hostname.mit.edu 11.3.0 Darwin Kernel Version 11.3.0: Thu Jan 12 18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64

saurik commented 12 years ago

Yeah: that's Mac OS X 10.7.3. For reference, I am using 10.6.8 (but am also currently cheating with regards to how I am testing this; I'll get a second computer soon and look more carefully).

When it says that, with "(imposed by #)", taken as a pid what process is that #? (I ask because 21 seems like a "fishy"ly low process number to be the sshd daemon that launchd spawned for you, so I'd love to verify. Using it as a pid, btw, is based on the documentation for the imposing mechanism on Wikipedia.)

keithw commented 12 years ago

It's powerd:

root 21 0.0 0.0 2462964 1696 ?? Ss 28Feb12 0:37.72 /System/Library/CoreServices/powerd.bundle/powerd

saurik commented 12 years ago

FTR, I went ahead and did the "correct test": remotely SSH'ing into my 10.6.8 laptop from an SSH client, and I got the following. On 10.6.8 powerd doesn't even exist, so that would help explain the differences in understanding I have of how these pieces can be put together. ;P

I'll see if I can learn anything more, or find someone to ask, about what is causing powerd to start that imposing feature for sshd. (Mind giving me the output of pmset -g assertions while connected in via SSH?)

Active Profiles:
Battery Power       -1*
AC Power        -1
Currently in use:
 standby    1
 lidwake    1
 halfdim    0
 hibernatefile  /var/vm/sleepimage
 disksleep  10
 sleep      15
 hibernatemode  3
 ttyskeepawake  1
 displaysleep   10
 acwake     0
 standbydelay   4200
keithw commented 12 years ago

Here you go:

$ pmset -g assertions

4/16/12 11:08:27 PM EDT Assertion status system-wide: ChargeInhibit 0 PreventUserIdleDisplaySleep 0 PreventUserIdleSystemSleep 1 NoRealPowerSources_debug 0 CPUBoundAssertion 0 EnableIdleSleep 1 PreventSystemSleep 0 DisableInflow 0 DisableLowPowerBatteryWarnings 0 ExternalMedia 0

Listed by owning process: pid 21: [0x0000012c00000015] PreventUserIdleSystemSleep named: "com.apple.powermanagement.ttyassertion" Details: /dev/ttys002 Localized=A remote user is connected. That prevents system sleep.

Kernel Assertions: 0x0004

saurik commented 12 years ago

Ok, awesome: that pmset -g assertions output actually helped a lot!

From PowerManagement-271.1/pmconfigd/TTYKeepAwake.c:

        /* Track the ttys that have a string for "ut_host" - presence of
         * that field implies they're remote connected ttys.
         * (We're not interested in tracking local Terminal windows, 
         * just remote sessions.)
         */
        if (0 < strlen(ent->ut_host))
        {
            addtty(ent->ut_line);            
        }

So yeah, it seems like fixing #61 (Mac OS X not having working utmp due to libutempter not supporting that platform) will solve this issue: mosh just needs to get a utmp entry with a hostname added for that TTY. The reason screen wasn't enough is that Apple was explicitly filtering those entries out, as they could be local sessions.

DominikTo commented 7 years ago

Just noticed this behavior on macOS 10.12 Sierra running as a mosh host. The initial login correctly wakes the machine up via the Bonjour Sleep Proxy, but then it goes back to sleep after a few seconds.

ineghi commented 5 years ago

Still the same issue as of 2019. Can we do something about it in a host level ?

vodrazka commented 4 years ago

any updates?

marchank0 commented 3 years ago

@vodrazka As I understood thru a very long discussion in the comments there are 2 possibilities to fix this issue:

  1. Reimplement login functionality entirely
  2. Add to mosh root privileges

Nobody has time/interest to do the 1st 2nd violates the design concepts that are lies under the mosh

So, I assume that it's not be fixed any time soon.

vodrazka commented 3 years ago

i understand, because of this i will choose good old ssh instead mosh in all macOS cases... maybe some day...

jay-ouellette commented 1 year ago

I can run caffinate via mosh without root and without an admin account on my M2 Mac Mini (MacOS 13.2.1) so this should be possible without root.

https://opensource.apple.com/source/PowerManagement/PowerManagement-703.71.1/caffeinate/caffeinate.c.auto.html

Note that you can disable sleep entirely on Ventura with: System Settings -> Displays -> Advanced -> "Prevent automatic sleeping when the display is off"