send_nsca fails to connect when run via cron or LaunchAgent on macOS 15 (Tahoe), but works manually in Terminal

Question

send_nsca fails to connect when run via cron or LaunchAgent on macOS 15 (Tahoe), but works manually in Terminal

I’m running macOS 15 (“Tahoe”) and have an issue where a command-line program (send_nsca, part of Nagios) can successfully connect to a remote host when executed manually in Terminal, but fails with Connection refused or timed out when executed automatically (via cron or a LaunchAgent).

I’ve verified the following:

The same command, same user, and same configuration file work perfectly when run in Terminal.
Network access is available from the background context:
- ping, nc, and curl to the target host/port succeed when executed from the LaunchAgent script.
The macOS firewall (socketfilterfw) is configured to allow both /usr/sbin/cron and /usr/local/nagios/bin/send_nsca.
No relevant entries appear in the system logs for tccd, sandboxd, or send_nsca (no “deny network-client” or similar).

Yet, send_nsca consistently fails when executed in the background (both from cron and LaunchAgent), even though basic network tests in the same context succeed.

What I’ve tried:

Granting full disk access to cron, launchd, and send_nsca.
Disabling and re-enabling the macOS firewall.
Using an explicit PATH and DYLD_LIBRARY_PATH in the script and LaunchAgent plist.
Testing with both IPv4 and IPv6 (IPv4 works fine manually).

Symptoms in tcpdump:

When run manually: normal TCP handshake → data exchange → clean FIN/ACK close.
When run from cron or LaunchAgent: SYN packets are sent, but the connection immediately closes with FIN/RST.

Environment:

macOS 15 “Tahoe”
send_nsca (Nagios client binary, compiled locally)

Question:

Has anyone seen a case on macOS 14/15 where a background process (cron, launchd, LaunchAgent) loses permission or ability to open outbound TCP sockets, even though the same binary works interactively in Terminal ?

Could this be related to TCC, sandboxing, or some hidden network entitlement restriction in the new macOS versions ?

Mac Studio (M4 Max, 2025)

Posted on Nov 5, 2025 1:39 AM

Reply

Answer 1

etresoft

Level 9

56,326 points

Nov 5, 2025 1:52 PM in response to nicochouette78

nicochouette78 wrote:

• I’m running macOS 15 (“Tahoe”)

Please clarify, are you running macOS 15 "Sequoia" or macOS 26 "Tahoe"?

a command-line program (send_nsca, part of Nagios)

Never heard of it. What does it do?

can successfully connect to a remote host when executed manually in Terminal, but fails with Connection refused or timed out when executed automatically (via cron or a LaunchAgent).

Those are radically different environments compared to the Terminal. Have you confirmed that you can run some kind of simple "echo" script to a file via either cron or a launch agent? This is not trivial.

The same command, same user, and same configuration file work perfectly when run in Terminal.

Again, the Terminal is a radically different environment. As part of your simple test above, try running the "env" tool and sending the output to a file. Then you could try setting up a custom Terminal environment that is similar. Otherwise, without some knowledge of what this send_nsca tool does, there's no way to guess where the breakage might be.

Note that I'm using "environment" as a general term. This does include the shell environment variables as shown in "env", but it also includes a lot of more exotic macOS runtime contexts like sessions. Terminal runs in a gui session. Cron and launch agents run in a user session. Sometimes people have clever command line tools that try to bridge those sessions. That's gonna be painful.

Network access is available from the background context:

• ping, nc, and curl to the target host/port succeed when executed from the LaunchAgent script.

So what does send_nsca do that's different?

The macOS firewall (socketfilterfw) is configured to allow both /usr/sbin/cron and /usr/local/nagios/bin/send_nsca.

Disable the firewall completely. This is non-negotiable. The firewall isn't what you think it is.

No relevant entries appear in the system logs for tccd, sandboxd, or send_nsca (no “deny network-client” or similar).

You seem to have already established that other tools run fine. I'm sure it's a question of whatever "send_nsca" is doing.

Granting full disk access to cron, launchd, and send_nsca.

What version of macOS "Tahoe" are you really using? Because 26.1 just broke Full Disk Access. I've heard there's a workaround, but I haven't tried it. If this tool needs Full Disk Access, then that may complicate things.

Disabling and re-enabling the macOS firewall.

Just do the former.

Using an explicit PATH and DYLD_LIBRARY_PATH in the script and LaunchAgent plist.

DYLD_LIBRARY_PATH? That doesn't sound good. Maybe this would be a good time to ask what this "send_nsca" tool is actually doing.

Has anyone seen a case on macOS 14/15 where a background process (cron, launchd, LaunchAgent) loses permission or ability to open outbound TCP sockets, even though the same binary works interactively in Terminal ?

Virtually no one is able to successfully run cron or launchd tasks. That's real black magic.

Could this be related to TCC, sandboxing, or some hidden network entitlement restriction in the new macOS versions ?

Nope. I'm sure that tool is broken and/or incompatible with this type of use. Guaranteed.

Reply

Answer 2

Nov 12, 2025 6:11 AM in response to leroydouglas

Hello, and thank you for your replies.

Here are a few clarifications:

Our Mac is running macOS Tahoe 26.0.1.

Nagios is an infrastructure monitoring solution. It’s based on a central server that connects over SSH to remote machines to run local scripts and monitor CPU, memory, disks, etc.

We also use it for application-level monitoring in a mostly Linux and macOS environment.

The affected Mac is used to run scripts and applications such as After Effects and InDesign.

When the application finishes its work, we use another Nagios feature called passive checks.

In this mode, it’s not the Nagios server that connects to the machine being monitored — instead, the monitored machine sends a message to the Nagios server using the send_nsca binary over a dedicated port (5667) to report whether the task completed successfully or failed.

This last process stopped working after upgrading from Sequoia to Tahoe.

Following your suggestions, we tried several of the proposed solutions.

We disabled both the Application Firewall (socketfilterfw) and Packet Filter (pfctl), but that didn’t resolve the issue.

We then upgraded from Tahoe 26.0.1 to Tahoe 26.1, but the problem persisted.

To summarize: when we run send_nsca through cron or a LaunchAgent, the Nagios server and the Mac fail to communicate, as confirmed by tcpdump.

However, running the exact same command manually works perfectly — no connection errors.

The pfctl lead initially seemed promising, but it didn’t fix the issue.

We spent quite a bit of time trying to address this regression and have now decided to work around it by avoiding the send_nsca binary entirely.

Still, I’m curious to understand the underlying cause of this regression, and I’d be happy to run additional tests if any potential solutions are proposed.

Version française :

Bonjour et merci pour vos réponses.

Voici quelques éclarcissements :

Notre Mac est en Tahoe 26.0.1.

Nagios est une solution de supervision d’infrastructure. Elle est basée sur un serveur qui exécute des scripts locaux en utilisant ssh sur des machines, pour monitorer le CPU, la mémoire, les disques etc…

Nous l’utilisons aussi pour faire un suivi applicatif, sur un environnement essentiellement Linux et Mac.

Nous utilisons le Mac sur lequel nous avons noté le problème, pour exécuter des scripts et des applicatifs comme AfterEffectcs et InDesign.

Sur ce Mac, lorsque l’application a fini son travail, nous utilisons une autre fonctionnalité de Nagios que sont les déclenchements passifs. Dans ce cas, ce n’est pas le serveur Nagios qui appelle un script de monitoring sur la machine à surveiller, mais la machine à surveiller qui envoie un message en se connectant via le binaire send_nsca sur le serveur Nagios, sur un port dédié à cet effet (5667), pour lui signifier que la tâche s’est bien ou mal exécutée.

C’est ce dernier process qui a cessé de fonctionner avec le passage de Sequoia à Tahoe.

Depuis vos réponses, nous avons essayé d’avancer avec les solutions que vous suggériez.

Nous avons arrêté le Firewall d’application socketfilterfw et packet filter pfctl.

Mais ça n’a pas arrangé la situation.

Nous avons fini par essayer de passer de Tahoe 26.0.1 à Tahoe 26.1, mais ça n’a pas corrigé notre problème.

Pour rappel, lorsque nous lançons send_nsca via cron ou LaunchAgent, le serveur nagios et le Mac n’arrivent pas à communiquer comme l’indique tcpdump.

Par contre lorsque nous lançons la même commande à la main il n’y a pas d’échec. La piste pfctl semblait prometteuse. mais...

Nous avons passé pas mal de temps pour essayer de corriger cette régression et nous avons décidé de contourner le problème sans utiliser le binaire send_nsca.

Je suis quand même curieux de comprendre la raison de cette régression et je ferai des tests si des solutions sont proposées.

Reply

Answer 3

Nov 5, 2025 1:20 PM in response to nicochouette78

nicochouette78 wrote:

• I’m running macOS 15 (“Tahoe”) and have an issue where a command-line program (send_nsca, part of Nagios) can successfully connect to a remote host when executed manually in Terminal, but fails with Connection refused or timed out when executed automatically (via cron or a LaunchAgent).

Question:

Has anyone seen a case on macOS 14/15 where a background process (cron, launchd, LaunchAgent) loses permission or ability to open outbound TCP sockets, even though the same binary works interactively in Terminal ?

Could this be related to TCC, sandboxing, or some hidden network entitlement restriction in the new macOS versions ?

re: Tahoe

The current stable release of Tahoe including bug fixes, security updates is macOS 26.1

Keep your Mac up to date - Apple Support

see if there is anything related here:

Run bash (.sh) via launchd using a plist … - Apple Community

Reply

Answer 4

etresoft

Level 9

56,326 points

Nov 12, 2025 10:36 AM in response to nicochouette78

nicochouette78 wrote:

In this mode, it’s not the Nagios server that connects to the machine being monitored — instead, the monitored machine sends a message to the Nagios server using the send_nsca binary over a dedicated port (5667) to report whether the task completed successfully or failed.

Please clarify. "over" suggests this is a hard-coded sending port. Mais en français il semble que ce soit un port à écouter au serveur. I sure hope it's just the listening port on the server, but one can never tell with these enterprise tools.

We disabled both the Application Firewall (socketfilterfw) and Packet Filter (pfctl), but that didn’t resolve the issue.

Doesn't matter. Keep them off. If you do manage to get it running, then you can try turning them back on to satisfy the suits. But while there's a problem, keep them off to avoid complicating the issue.

We then upgraded from Tahoe 26.0.1 to Tahoe 26.1, but the problem persisted.

Tahoe 26.2 will be out soon. I can guarantee that won't fix it either.

To summarize: when we run send_nsca through cron or a LaunchAgent, the Nagios server and the Mac fail to communicate, as confirmed by tcpdump.

Does this send_nsca tool have any debugging facilities of its own? A more detailed log file option perhaps?

However, running the exact same command manually works perfectly

Which is what, pray tell?

The pfctl lead initially seemed promising, but it didn’t fix the issue.

It's not a lead, it's just basic debugging. There is always a chance that two different problems could manifest in exactly the same symptoms. So any complication that isn't absolutely necessary must be disabled. Otherwise, how would you know that you haven't fixed the problem 3 weeks ago?

Still, I’m curious to understand the underlying cause of this regression, and I’d be happy to run additional tests if any potential solutions are proposed.

Just tell us what command you're actually running. When I search for "send_nsca", I get a hit from the Nagios support forums with people running commands that look like this:

cat ./test | ./send_nsca -H $NSCAHOST -c /home/nagios/send_nsca.cfg

Trying to run that in cron or a launch agent is going to fail in so many different ways. There are ways to do it, but it's tricky. If your command looks anything like that, then it would be helpful to see the launch agent content as well.

If you wanted to run a test, a good one to try would be whatever send_nsca command you are trying to run, prefixed with "echo". It might not be what you expect. That's the first thing to try.

Version française :

Il y a une version française de la Communauté d’assistance Apple à https://communities.apple.com/fr/welcome. La plupart des gens dans cette communauté ne parle que l’anglais.

Reply