So your base unit has Type=notify – but an override.conf changes it to Type=forking, which changes what systemd expects from the daemon. But it seems the ExecStart command line hasn't been changed to match and still runs asterisk with the "-f" option telling it to start without forking 'into background', so systemd will wait forever for something that's never happening.
Do other hosts have the same override.conf (and the same "systemctl cat" output in general)?
I found in the manual page that asterisk can have -F specified to undo -f, and that it also supports equivalent nofork/alwaysfork settings in its .conf file (although it doesn't say which one takes priority). Do the other systems use "alwaysfork" in asterisk.conf?
On Tue, Dec 17, 2024, 18:21 Raul Jimeno <raul.jimeno@xxxxxxxxxx> wrote:
Your status output shows the unit file being in /etc --> yes, that is correct.
Does `systemctl cat asterisk` show the same contents on all systems? Yes, it does.
---------------------------
grep -E "^User|^Group" /etc/systemd/system/asterisk.service
User=invade
Group=invade
---------------------------
# /etc/systemd/system/asterisk.service
[Unit]
Description=Asterisk PBX and telephony daemon.
After=network.target
#include these if asterisk need to bind to a specific IP (other than 0.0.0.0)
#Wants=network-online.target
#After=network-online.target network.target
[Service]
Type=notify
Environment=HOME=/var/lib/asterisk
#if systemd do not provide hostname and you need to use ${ENV(HOSTNAME)}
#Environment=HOSTNAME=%H
WorkingDirectory=/var/lib/asterisk
User=invade
Group=invade
ExecStartPre=+/usr/bin/mkdir -p /var/run/asterisk
ExecStartPre=+/usr/bin/chown invade:invade /var/run/asterisk
ExecStartPre=+/usr/bin/chmod 0755 /var/run/asterisk
ExecStart=/usr/sbin/asterisk -mqf -C /etc/asterisk/asterisk.conf
ExecReload=/usr/sbin/asterisk -rx 'core reload'
#if /var/run is a tmpfs, this will create /var/run/asterisk on start
#RuntimeDirectory=asterisk
#Nice=0
#UMask=0002
LimitCORE=infinity
#LimitNOFILE=
Restart=always
RestartSec=4
# Prevent duplication of logs with color codes to /var/log/messages
StandardOutput=null
PrivateTmp=true
[Install]
WantedBy=multi-user.target
# /etc/systemd/system/asterisk.service.d/override.conf
[Service]
Type=forking
PIDFile=/var/run/asterisk/asterisk.pid
TimeoutStartSec=300
Restart=on-failureCompany Registration Number: 3660482Kind regards,
Raúl Jimeno
IT Support Engineer
INVADE International Ltd
+44 33 3344 0784 (Office)
+44 117 3251309 (Direct)Invade International Ltd
Unit 6, Badminton Court, Station Road, Bristol
BS37 5HZ, United Kingdom------------------------------------------------------
Registered in England and Wales
this email, and any attachment, is intended only for the attention of the addressee. Its unauthorised use, disclosure, storage or copying is not permitted. If you are not the intended recipient, please destroy all copies and inform the sender by return email. If you have received this email in error, please return it to the sender and highlight the error. We accept no legal liability for the content of the message. Any opinions or views presented are solely the responsibility of the author and do not necessarily represent those of InVADE. We cannot guarantee that this message has not been modified in transit, and this message should not be viewed as contractually binding. Although we have taken reasonable steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.
On Tue, 17 Dec 2024 at 17:08, Mantas Mikulėnas <grawity@xxxxxxxxx> wrote:Your status output shows the unit file being in /etc; does it differ much from the original packaged unit (if there was one)? Does `systemctl cat asterisk` show the same contents on all systems? The most common cause of a timeout is probably the unit and the daemon disagreeing on whether to report 'started' (e.g. if the unit is Type=forking but the service's own config file tells it to not fork/daemonize at all).On Tue, Dec 17, 2024, 16:58 Raul Jimeno <raul.jimeno@xxxxxxxxxx> wrote:Hi all,Sorry, I am new on this list and this is my first post requesting some help troubleshooting an issue with systemd.I’m experiencing an issue where the Asterisk service fails to start and times out consistently. This happens across multiple versions of Asterisk, so we suspect it might be a systemd-related issue.
The OS is Rocky Linux release 8.9 and running in a VM.
No issue in other sites with same OS and same Asterisk versionsIssue Details:
When starting Asterisk with
systemctl, it fails due to a timeout:sudo systemctl start asteriskJob for asterisk.service failed because a timeout was exceeded. See "systemctl status asterisk.service" and "journalctl -xe" for details.
systemctl status asteriskshows the service in an "activating" state for a while before timing out:asterisk.service - Asterisk PBX and telephony daemonLoaded: loaded (/etc/systemd/system/asterisk.service; enabled; vendor preset: disabled) Active: activating (start) since Tue 2024-12-17 16:22:36 EET; 21s agoAfter a minute or so, the service fails with the following:
Dec 17 16:37:47 localhost systemd[1]: Failed to start Asterisk PBX and telephony daemon.The unit asterisk.service has entered the 'failed' state with result 'timeout'.What Has Been Tried:
- Different versions of Asterisk have been tested — the issue persists.
- Asterisk was run manually, and it starts fine outside of systemd.
- Timeouts (
TimeoutStartSec) were increased in the systemd unit file, but the service still doesn’t reach an "active (running)" state.
Any help would be really appreciate.Company Registration Number: 3660482Kind regards,
Raúl Jimeno
IT Support Engineer
INVADE International Ltd
+44 33 3344 0784 (Office)
+44 117 3251309 (Direct)Invade International Ltd
Unit 6, Badminton Court, Station Road, Bristol
BS37 5HZ, United Kingdom------------------------------------------------------
Registered in England and Wales
this email, and any attachment, is intended only for the attention of the addressee. Its unauthorised use, disclosure, storage or copying is not permitted. If you are not the intended recipient, please destroy all copies and inform the sender by return email. If you have received this email in error, please return it to the sender and highlight the error. We accept no legal liability for the content of the message. Any opinions or views presented are solely the responsibility of the author and do not necessarily represent those of InVADE. We cannot guarantee that this message has not been modified in transit, and this message should not be viewed as contractually binding. Although we have taken reasonable steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.
Invade International Limited, Unit 6, Badminton Court, Station Road, Bristol, BS37 5HZ. Registered in England & Wales - Company number: 3660482This email, and any attachment, is intended only for the attention of the addressee. Its unauthorised use, disclosure, storage or copying is not permitted. If you are not the intended recipient, please destroy all copies and inform the sender by return email. If you have received this email in error, please return it to the sender and highlight the error. We accept no legal liability for the content of the message. Any opinions or views presented are solely the responsibility of the author and do not necessarily represent those of INVADE. We cannot guarantee that this message has not been modified in transit, and this message should not be viewed as contractually binding. Although we have taken reasonable steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.
Invade International Limited, Unit 6, Badminton Court, Station Road, Bristol, BS37 5HZ. Registered in England & Wales - Company number: 3660482This email, and any attachment, is intended only for the attention of the addressee. Its unauthorised use, disclosure, storage or copying is not permitted. If you are not the intended recipient, please destroy all copies and inform the sender by return email. If you have received this email in error, please return it to the sender and highlight the error. We accept no legal liability for the content of the message. Any opinions or views presented are solely the responsibility of the author and do not necessarily represent those of INVADE. We cannot guarantee that this message has not been modified in transit, and this message should not be viewed as contractually binding. Although we have taken reasonable steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.
