Is there official way to restart nesessionmanger on macOS instead of killing it?

Thanks @eskimo, I see the main issue(my extension can not be relaunched on both macOS 12 and 13 automatically after multiple activations without reboot, reboot can solve the issue as well) in both production(activate system extension again during the upgrade product) and developer machines(can reproduce by multiple activations). And both log of sysextd and nesessionmanager to show the system extension should be launched, but not.

Btw, I noticed that if I activate system extension multiple times, the old ones would be terminated by sysextd, so looks no need to do deactivation before activate it?

I noticed that if I activate system extension multiple times, the old ones would be terminated by sysextd, so looks no need to do deactivation before activate it?

Right. My go-to reference for this stuff is the doc comments for -activationRequestForExtension:queue: in ＜SystemExtensions／SystemExtensions.h＞, which specifically addresses this case.

I see the main issue … in both production … and developer machines

So how reproducible is in in production? Do you see it every time you upgrade your sysex? Or only on specific machines? Or only for some fraction of upgrade attempts?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks @eskimo.

"If the extension is already active, the request succeeds in short order, without significant delay or user interaction. If you request activation of a new version of an already-active extension, the system prompts the user to resolve the conflict before proceeding."

I also did not see any system prompts for this case.

In production: My main app can accept a external parameter to do activationRequestForExtension of the system extension. During the whole App upgrade, in the script of installer would call my main app with "activate" parameter to activate the new system extension. The log of sysextd and nesessionmanager said the system extension has been activated, but it was not running unless I restarted the nesessionmanager or reboot or deactivated it first and activated it again.

default    23:36:25.429287+0800    sysextd    setting +x bit on executable in bundle file:///Library/SystemExtensions/0B50E56F-108F-4F48-B9D0-26788FBB7817/com.android2test.sysext.systemextension/
default    23:36:25.429610+0800    sysextd    notifying categories that extension com.android2test.sysext will start
default    23:36:25.429687+0800    sysextd    returning cdhash for local arch x86_64 of extension com.android2test.sysext
default    23:36:25.430012+0800    sysextd    starting extension com.android2test.sysext via owning category com.apple.system_extension.network_extension
default    23:36:25.430049+0800    sysextd    returning cdhash for local arch x86_64 of extension com.android2test.sysext
default    23:36:25.431545+0800    sysextd    extension point confirmed that extension com.android2test.sysext is runnable
default    23:36:25.431587+0800    sysextd    changing state of extension com.android2test.sysext to activated_enabled
default    23:36:25.431615+0800    sysextd    extension *** com.android2test.sysext (1.1.0/1.1.0) advancing state from activated_enabling to activated_enabled
default    23:36:25.445482+0800    sysextd    observer for 'com.android2test.app' reached success: activated_enabled

Not every time, it's not 100% can be reproducible.

Btw, if I set the system extension developer on(SIP disabled), then I can do multiple system extension activation with the same version. In this way, I can see the similar issue more easier.

During the whole App upgrade, in the script of installer would call my main app with "activate" parameter to activate the new system extension.

This isn’t something we support. See this post.

I’m not sure if this fact is causing the current problem you’re seeing but I generally decline to dig into problems that start from an unsupported position )-:

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks @eskimo.

"The SystemExtensions framework is intended to be used by a GUI app to load and unload system extensions in response to user actions. It’s not meant to be called from a command-line tool, regardless of how that command-line tool is packaged. Calling it from a command-line tool is unsupported and may yield weird results."

Actually, the "activate/deactivate" commands are supported in my GUI app itself, it's not another command-line tool. What I did in the upgrade is to use install script to call my GUI app with parameter, may I know that is not supported?

To reiterate, the framework was designed to be used by a GUI app in response to user actions. It doesn’t really matter how you try and get around that design. The end goal is unsupported.

There is a way to automate the installation and upgrade of system extension, namely by MDM. That only works in a managed environment.

These limitations are not accidental. In an unmanaged environment, we expect the user to be in charge of this stuff.

If you’d like to see this design change, feel free to file an enhancement request explaining your requirements and why the current behaviour doesn’t work for your product.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"