Implement logout functionality

[natewalck]

Would it be worth adding logout functionality ala https://github.com/aysiu/offset ?

[bartreardon]

Seams reasonable.

Detecting the state is...something

[natewalck]

There has to be a more macOS native way to do this. Hrmmm.

[bartreardon]

not in launchd by the looks.

I have some ideas though - there are some implementations like logout watcher ( 1 2 ) but I think we can do something without needing anything external.

rough thoughts: 1 extra mode for outset that runs it as a daemon. it's sole purpose in life is to ~die~ wait for a SIGINT or SIGTERM event or whatever and touch a trigger file or simply exit 2 extra launchd items, one to launch the daemon process as a user agent and the other to trigger at logout

this could get messy. launchd has a property OtherJobEnabled which checks if another job is loaded or not and when $otherjob quits it triggers its program arguments. You could use this to detect when the user agent stops running, which would happen on logout, and start processing. This might work in combo with LimitLoadToSessionType

potentially we can also have the daemon process write a trigger file. this would only get written if the daemon is instructed to exit. A SIGKILL just ends everything.

The last step is to identify a logout vs a reboot. Whatever you want to run at the login window context should not occur if the logout is the first step in a reboot event. Anything that was triggered would be nuked by the OS in short order.

Probably worth looking at how something like munki handles it in order to trigger events that require logout.

[natewalck]

Looking at Munki, it uses:

    <key>LimitLoadToSessionType</key>
    <array>
        <string>LoginWindow</string>
    </array>

Which is the obvious way to do it at the login window. I'd argue a reboot is also a logout, so we don't need to care about that (bur document it clearly)

System startup on the other hand is not a logout, so we'd need some method to figure that out.

This lead me to finding this:

https://stackoverflow.com/a/63372640

So perhaps you could have a LaunchD that does nothing but run code to detect these events, then touch a file on disk that the LoginWindow LaunchAgent looks for (also similar to munki: https://github.com/munki/munki/blob/main/launchd/LaunchAgents/com.googlecode.munki.managedsoftwareupdate-loginwindow.plist#L9)

This of course circles right back around to what is the use case for this? Is it worth the time and effort? (I could see computer labs perhaps wanting something like this).

[bartreardon]

it was worth it enough for someone to write offset. The computer lab scenario of "run scripts that perform cleanup tasks" is one I can see people using. For that I don't think it's required to detect a logout event per-se, you just have a launchd that loads in the login window context.

Properly documented the workflow would be left to the admin, e,g,

loginwindow tasks always run at the login window. if you want an even to take place after a logout then use something like this:

• create your login window script to require presence of a trigger file
• create a login-every script to create the trigger file
• when the user logs out and you are back at the login window, your task should trigger, and then clean up after itself
• optionally add a boot script that performs initial cleanup before the loginwindow is presented (e.g. your script trigger is still present)

I don't think it needs to be complicated. At a reboot event, the login window isn't displayed so these events won't trigger in that scenario.

In short I think we don't implement "logout" functionality. We implement "login-window" and the logic for a "logout" scenario can be an exercise for the admin - maybe document some basic scenario as an example but not build that into outset.

WDYT?

[bartreardon]

this is also a core justification for Ouset IMO - creation of launchd logic for admin tasks that can be managed under a single banner and save admins from creating their own seperate ones and individually managing the login items settings.

[natewalck]

I like this method better. Less complicated and allows for as much flexibility as the admin might desire.

it was worth it enough for someone to write offset. The computer lab scenario of "run scripts that perform cleanup tasks" is one I can see people using. For that I don't think it's required to detect a logout event per-se, you just have a launchd that loads in the login window context.

Properly documented the workflow would be left to the admin, e,g,

loginwindow tasks always run at the login window. if you want an even to take place after a logout then use something like this:

• create your login window script to require presence of a trigger file
• create a login-every script to create the trigger file
• when the user logs out and you are back at the login window, your task should trigger, and then clean up after itself
• optionally add a boot script that performs initial cleanup before the loginwindow is presented (e.g. your script trigger is still present)

I don't think it needs to be complicated. At a reboot event, the login window isn't displayed so these events won't trigger in that scenario.

In short I think we don't implement "logout" functionality. We implement "login-window" and the logic for a "logout" scenario can be an exercise for the admin - maybe document some basic scenario as an example but not build that into outset.

WDYT?

[bartreardon]

@natewalck interested to see what you think of Beta 2

In my testing, login-window scripts are executed before boot scripts. Could be an interesting challenge for working out reliable "logout" processing.

Potential idea - login-every script that touches a marker file on user login. login-window script that only continues processing when said marker file is present.

Issues with that idea - creating the marker file on login and the user reboots instead of logging out. This may still be desired (script runs at the login window either way) but if you want to capture only a logout, not a reboot, this may be difficult if login window scripts execute before boot scripts, preventing any boot process cleanup. One could also check for a reboot event or something. A good opportunity for some boilerplate scripts to get people started perhaps.

[bartreardon]

Closing this one - while there's no direct "logout" function as such, this can be achieved with a login-window script and some flags set on user login to trigger the login window script to run at user logout (either as a logout, or reboot event)