Mac OS X sleeps (!) while running mosh

[keithw]

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]

Appears intractable for now. WONTFIX

[saurik]

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]

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]

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]

It's powerd:

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

[saurik]

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]

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)

[saurik]

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]

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.