Mosh: Mac OS X sleeps (!) while running mosh

Created on 7 Mar 2012 · 13Comments · Source: mobile-shell/mosh

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".

OS X bug

Source

keithw

Most helpful comment

any updates?

vodrazka on 20 Jul 2020

👍2

All 13 comments

Appears intractable for now. WONTFIX

keithw on 31 Mar 2012

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.)

saurik on 17 Apr 2012

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

keithw on 17 Apr 2012

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.)

saurik on 17 Apr 2012

It's powerd:

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

keithw on 17 Apr 2012

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

saurik on 17 Apr 2012

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

Kernel Assertion ID = 500
Created At = 12/31/69 7:03:13 PM EST
Modified At = 12/31/69 7:08:57 PM EST
Owner ID = 0xffffff800b96c000
Level = 255
Assertions Set = None (4)
Kernel Assertion ID = 501
Created At = 12/31/69 7:03:33 PM EST
Modified At = 12/31/69 7:00:00 PM EST
Owner ID = 0xffffff800b991000
Level = 0
Assertions Set = None (4)
Kernel Assertion ID = 502
Created At = 12/31/69 7:05:14 PM EST
Modified At = 4/2/12 8:45:28 AM EDT
Owner ID = 0xffffff806af7d000
Level = 0
Assertions Set = None (4)
Kernel Assertion ID = 503
Created At = 12/31/69 7:05:19 PM EST
Modified At = 12/31/69 7:00:00 PM EST
Owner ID = 0xffffff806af80000
Level = 0
Assertions Set = None (4)
Kernel Assertion ID = 504
Created At = 12/31/69 7:05:24 PM EST
Modified At = 12/31/69 7:00:00 PM EST
Owner ID = 0xffffff806afca000
Level = 0
Assertions Set = None (4)
Kernel Assertion ID = 505
Created At = 12/31/69 7:05:29 PM EST
Modified At = 12/31/69 7:00:00 PM EST
Owner ID = 0xffffff806af83000
Level = 0
Assertions Set = None (4)
Kernel Assertion ID = 506
Created At = 12/31/69 7:05:34 PM EST
Modified At = 12/31/69 7:00:00 PM EST
Owner ID = 0xffffff806af86000
Level = 0
Assertions Set = None (4)

keithw on 17 Apr 2012

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.

saurik on 17 Apr 2012

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.