Salt minion stops processing jobs after modem reset (AT+CFUN=1,1) but never getting back working.

[adesgagne]

Summary

I am experiencing an issue where a Salt minion becomes partially unresponsive after a cellular modem reset using AT+CFUN=1,1. The salt-minion.service needs to be restarted.

Setup

• Salt version: 3006.23
• OS: Raspberry Pi OS (64-bit) - Debian 13
• Network: Cellular modem (USB)
• Modem reset command used: AT+CFUN=1,1

Test Method

On the master, I continuously send jobs using:

i=1; while true; do echo "Attempt #$i" sudo salt gw-relynkz-004 test.ping ((i++)) sleep 1 done

Observed Behavior

Before modem reset

• test.ping works reliably
• Minion responds with True
• No errors in logs

After running AT+CFUN=1,1

• Cellular interface resets (expected)
• Network connectivity is restored

However:

The master shows timeouts and no responses forever.

Additional Observations

• The issue occurs consistently after AT+CFUN=1,1
• This command fully resets the modem (drops interface and reconnects)
• The minion process itself does not crash
• Restarting the minion fixes the issue immediately:
• systemctl restart salt-minion

Questions

1. Is this a known limitation of Salt with abrupt network interface resets?
2. Is there a recommended way to force the minion to fully reinitialize its transport without restarting the service?
3. Are there configuration options (timeouts, reconnect settings, TCP keepalive, etc.) that can improve recovery?

salt-minion-debug.log
salt-minion-debug.log

[dafyddj]

There is a config setting for the minion master_alive_interval intended for this scenario, however I'm trying it out myself at the moment and am finding problems with it.

[adesgagne]

I forgot to mention the configuration I'm using.

I tried to set master_alive_interval without succeed.

minion.txt

[claudiawalsh491-ai]

Thanks for the detailed explanation! It seems like master_alive_interval might be the right setting to handle this, though I’ve also encountered some issues with it. It might help to tweak the master_timeout or look into using TCP transport, as it may offer better resilience for network resets like this. Would love to hear if you find a better solution with your tests!

…

On Fri, Mar 27, 2026, 8:33 AM Alexandre Desgagné ***@***.***> wrote: I forgot to mention the configuration I'm using. I tried to set master_alive_interval without succeed. minion.txt <https://github.com/user-attachments/files/26306054/minion.txt> — Reply to this email directly, view it on GitHub <#68852?email_source=notifications&email_token=B72HDPLDRQZGTHLAEGMIBET4SZ7MFA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRTGQ2DIMZUUZZGKYLTN5XKU43VMJZWG4TJMJSWJJLFOZSW45FMMZXW65DFOJPWG3DJMNVQ#discussioncomment-16344434>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B72HDPNBIMRGDHUKO7W7KTL4SZ7MFAVCNFSM6AAAAACXB3WBHGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMZUGQ2DGNA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[adesgagne]

Thanks for your answer, what kind of issues do you have with master_alive_interval?

I'll have a look at TCP transport too.

[claudiawalsh491-ai]

Nothing in particular.

…

On Fri, Mar 27, 2026, 12:35 PM Alexandre Desgagné ***@***.***> wrote: Thanks for your answer, what kind of issues do you have with master_alive_interval? I'll have a look at TCP transport too. — Reply to this email directly, view it on GitHub <#68852?email_source=notifications&email_token=B72HDPJ6TEW4KGTKZAKOGTT4S23XPA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRTGQ3TSNJTUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-16347953>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B72HDPNFZCIKNYWERFFNYLT4S23XPAVCNFSM6AAAAACXB3WBHGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMZUG44TKMY> . You are receiving this because you commented.Message ID: ***@***.***>