I sent the description file through MDM in advance and configured the system extension and web content filter. When my code uses activationRequestForExtension:queue: to activate the system extension, other security app processes will be killed. I received the following message. May I ask why this may be?
2024-09-02 11:42:19.737229 (gui/501/killed_bundleid [679]) <Notice>: exited due to SIGPIPE | sent by killed_app[679], ran for 301372ms 2024-09-02 11:42:19.737239 (gui/501/killed_bundleid [679]) <Notice>: service state: exited 2024-09-02 11:42:19.737245 (gui/501/killed_bundleid [679]) <Notice>: internal event: EXITED, code = 0 2024-09-02 11:42:19.737247 (gui/501/killed_bundleid [679] ]) <Notice>: job state = exited 2024-09-02 11:42:19.737274 (gui/501 [100003]) <Notice>: service inactive: killed_bundleid 2024-09-02 11:42:19.737277 (gui/501/killed_bundleid [679]) <Notice>: service state: not running 2024-09-02 11:42:19.737282 (pid/679 [killed_app]) <Notice>: shutting down 2024-09-02 11:42:19.737310 (pid/679 [killed_app]) <Notice>: cleaning up
Which process is actually terminating here?
The entry in the system log suggests it’s exiting due a SIGPIPE
. That’s a common gotcha with BSD Sockets. If you write to a socket where the underlying connection has disconnected, the system sends your process a SIGPIPE
. The default disposition of that signal is to kill your process. So, in this scenario, starting your content filter is causing all connections to close, which is expected, and this process is not handling that properly.
If the process that’s dying unexpectedly is something that you control, I recommend that you modify your code to deal with SIGPIPE
correctly. In most cases that means setting the SO_NOSIGPIPE
socket option, so that the write system call returns an error rather than raising a SIGPIPE
in this case.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"