How persistent is persistent?

AllStarLink
1

I've been running ASL (now ASL3) for many years under Proxmox as a VM (Debian 12) with few problems but I've noticed that, even though I have a startup macro defined, it doesn't work if the network isn't up and operational before ASL boots. I would have expected ASL to continue forever trying to establish the connection but it doesn't

My relevant rpt.conf entries

[1100](node-main)
duplex = 0
rxchannel = Local/pseudo

startup_macro = *8131101 *8131102 *8131103 *8131002 *81357387
propagate_dtmf = yes
controlstates = controlstates
events = events1234
2

Could probably just tweak asterisk.service to wait for network.

Edit: this is the default setup already and is not necessary.

sudo systemctl edit asterisk.service

Insert:

[Unit]
Wants=network-online.target
After=network-online.target

Then:

sudo systemctl daemon-reload
sudo systemctl restart asterisk
3

Thanks (and I will incorporate your edits) but doesn't that kinda reinforce the concept that persistent connections aren't. (or perhaps the state of a connection isn't written to a file to prevent this exact kind of issue?).

I guess persistent connections are only persistent as long as asterisk's OS doesn't go down.

4

Permanent connections are, by design, not intended to survive reboots.

5

Can you add the startup wait command?

startup_macro_delay=30

6

Seems to me there should be an option to make persistence survive over an OS reboot. Maybe it should be user selectable? I would argue that if a node op had a startup macro with persistent connections, shouldn't it actually be persistent?

7

The option is already there, in the form of the startup macro

8

You miss that I posted that I am using a startup macro in my OP?

9

No, I didn't miss that.

Startup macro is the function that should be used to make a permanent connection "survive" a reboot.

You're already using it, so I'm not really sure why you're asking for the functionality to be added.

10

So back to my original issue. Why doesn't the startup macro in my config continue to try to connect until the network comes back up and then connect to the other nodes?

11

I'd suggest you check the logs. It's usually the best place to start. You have to enable the startup logs in rpt.conf. Look for and uncomment:

archivedir = /var/spool/asterisk/monitor

Also add:

archiveaudio = no

To keep from filling up the log with WAV. Restart asterisk, and check the logs in the defined locatoin. There should be a sub directory for each node.

12

That seems to be the default these days anyway

andrew@allstar:~$ head /usr/lib/systemd/system/asterisk.service
[Unit]
Description=Asterisk PBX
Documentation=man:asterisk(8)
Wants=network-online.target
After=network-online.target

[Service]
Type=notify
ExecStart=/usr/sbin/asterisk -g -f -p -U asterisk
ExecReload=/usr/sbin/asterisk -rx 'core reload'
andrew@allstar:~$
14

You're saying two contradictory things here and both are vague. Impossible to give you guidance until you clarify.

You first state that you're running in as a VM but the "network isn't up and operational before ASL boots". Which network isn't up? The VM network or the underlying hypervisor network? The hypervisor shouldn't be starting the VM until its network itself is working and is a Proxmox problem if that's what you're describing. If Proxmox isn't ready to serve clients that boots upon it that's the problem. If you're saying it's the VM networking isn't up before asterisk starts, then something about your VM OS is broken because Asterisk will not start until network-online.target is reached. And how network-online.target is reached depends on how you configured Debian. Are you using the legacy /etc/network structure, NetworkManager, or netplan/cloud-init? You could use nss-lookup.target in conjunction with network-online.target if you want to wait until you can resolve some sort of off-site DNS name. But more info needed in this case.

If you're saying that the VM OS and asterisk has been up and functioning, you're having some sort of network problem (which you need to clarify what the problem is), and when the network is "again available" without restarting asterisk then a persistent link (specifically an ilink 13) will absolutely ride through the network issue. If it's not, the exact condition that's causing the problem needs to be investigated because that's possibly a bug in app_rpt.

However, is most cases, a persistent link will ride out a network issue just fine. I run into this al the time on our system and persistent links come right back once the network is available.

15

Scenario - Commercial power goes down (no backup) so everything - switch, router, Proxmox host, VMs, go bye bye. X amount of time passes and commercial power is restored. The Proxmox host (and its VMs) tend to fully boot up before switch and router do. Under these conditions, I have to manually reconnect the 4 nodes that are supposedly "persistently" connected to that VM's node, despite my startup macro telling the node to do so.