Why do 12.6.0 and 14.5.0 trigger other apps to receive SIGPIPE signals when starting the network filter, but 10.15, 11, 13, and 14.6.1 do not?

Hi,team: I am testing a product and found that my 12.6.0 and 14.5.0 computers will cause other app processes to exit when starting my network filter, but 10, 11, 13, and 14.6.1 will not. I can see the exit log of the app from launchd.log. Why is this? The log is as follows: 2024-09-12 19:34:36.783374 (gui/501/app_bundleid [546]) <Notice>: exited due to SIGPIPE | sent by App[546] 2024-09-12 19:34:36.783383 (gui/501/app_bundleid [546]) <Notice>: service state: exited 2024-09-12 19:34:36.783386 (gui/501/app_bundleid [546]) <Notice>: internal event: EXITED, code = 0 2024-09-12 19:34:36.783389 (gui/501/app_bundleid [546]) <Notice>: job state = exited 2024-09-12 19:34:36.783411 (gui/501 [100005]) <Notice>: service inactive: app_bundleid 2024-09-12 19:34:36.783414 (gui/501/app_bundleid [546]) <Notice>: service state: not running 2024-09-12 19:34:36.783582 (pid/546 [App]) <Notice>: shutting down

Answered by DTS Engineer in 803546022

I presume we’re talking macOS here.

In general, starting a filter provider is expected to tear existing network connections so that they’re not invisible to the filter. Once the app hears about the connection going down, it re-establishes the connection and the filter provider can then inspect the new connection.

Tearing a network connection may or may not generate a SIGPIPE depending on how the app is managing its connections. SIGPIPE is generated when:

  • The app is using BSD Sockets.

  • It hasn’t explicitly disable SIGPIPE via SO_NOSIGPIPE.

  • It isn’t actively monitoring the connection and ends up writing to the socket after the connection has been closed.

The default disposition of SIGPIPE is to terminate the process. If an app fails to handle this correctly, that’s clearly a bug in the app, because network connections can tear for a variety of reasons.


Regarding the base behaviour here — closing all flow when the filter comes up — you’re not the first developer to be inconvenienced by that. We already have an enhancement request on file for this (r. 99402484), but it hasn’t happened yet. If you’d like to be notified when this changes, file your own bug and ask that it be marked as a duplicate.

Share and Enjoy

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

In addition, 12.6.0 and 14.5.0 sometimes trigger SIGPIPE when starting the network filter, but not every time. How can I avoid triggering SIGPIPE?

I presume we’re talking macOS here.

In general, starting a filter provider is expected to tear existing network connections so that they’re not invisible to the filter. Once the app hears about the connection going down, it re-establishes the connection and the filter provider can then inspect the new connection.

Tearing a network connection may or may not generate a SIGPIPE depending on how the app is managing its connections. SIGPIPE is generated when:

  • The app is using BSD Sockets.

  • It hasn’t explicitly disable SIGPIPE via SO_NOSIGPIPE.

  • It isn’t actively monitoring the connection and ends up writing to the socket after the connection has been closed.

The default disposition of SIGPIPE is to terminate the process. If an app fails to handle this correctly, that’s clearly a bug in the app, because network connections can tear for a variety of reasons.


Regarding the base behaviour here — closing all flow when the filter comes up — you’re not the first developer to be inconvenienced by that. We already have an enhancement request on file for this (r. 99402484), but it hasn’t happened yet. If you’d like to be notified when this changes, file your own bug and ask that it be marked as a duplicate.

Share and Enjoy

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

Why do 12.6.0 and 14.5.0 trigger other apps to receive SIGPIPE signals when starting the network filter, but 10.15, 11, 13, and 14.6.1 do not?
 
 
Q