Hi,
First off, the two states here are potentially VERY different:
either reboot the machine prior to provide user credentials,
or by log out from current user.
Depending on the device, system version and exact configuration, in state #1, the device
-
ONLY has access to the contents of the Read Only System Volume (ROSV) and a very small amount of data that has been specifically made available to the ROSV. This data is primarily the data necessary to present a relevant login dialog and very little else.
-
The system may not even be running macOS.
Note that while the login behavior of those two states may look similar, that is simply because care has been taken to ensure that the interface experience is the same. What's actually occurring in those two states is very different. State #1 is basically outside of the systems "normal" operation and not something a developer component can really interact with or modify.
Focusing on #2:
So far I couldn't find any useful configuration in the plist file under /Library/LaunchDaemon.
First off, if you haven't already, I would strongly recommend that you study the classic, "TN2083:
Daemons and Agents" in detail, as it does a great job of outlining both the basic architecture underneath all of this and the many issues developers encounter trying to work with it.
In any case, one of the key take aways from that document is that your design needs to work with the systems architecture, not against it. Architecturally, daemon's don't "know" about login/logout because, by design, the global context is about "stuff that isn't tied to the user session". On the other hand, LaunchAgents already have a "login notification", as it's straightforward to make a LaunchAgent that will automatically launch "at login". That leads to here:
Perhaps there's a way to get notification programmatically for when
the system enter/exit pre-login mode ?
What are you actually trying to do/solve here? The reason daemon's don't really have any way to do this is that, in practice, the main reason developer are trying to detect this sort of transition is because they're ultimately trying to do "something" that's tied to the user session. Invariably, that means they either:
-
Waste a lot of time fighting with the system trying to find a way to make it work in their daemon.
-
Introduce an agent into their architecture, eliminating the need for a daemon level notification/API.
That's why the system doesn't provide any clear daemon API for this. It would only encourage apps down path #1, which is exactly what they shouldn't be doing.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware