That makes sense; many services use libsystemd to implement support for Type=notify, and without it, asterisk won't send the "ready" notification that systemd expects, either.
On another note, have you considered using systemd-tmpfiles for the /run directory creation like most other services do? On Tue, Dec 17, 2024, 19:26 Raul Jimeno <raul.jim...@invade.net> wrote: > Ok, it was found that the override part is not from our standard build but > added latter trying to resolve the issue. > > That part has now been removed. > > And it was found the problem. It was that before installing asterisk we > realised that sistemd-devel package was missing. > > It has been installed the missing packet and reinstall asterisk and now > all works as it should. > > Thanks for the assistance with this matter. > > > Kind regards, > > > *Raúl Jimeno* > > IT Support Engineer > > INVADE International Ltd > +44 33 3344 0784 (Office) > +44 117 3251309 (Direct) > raul.jim...@invade.net > http://www.invade.net <http://support.invade.net/> > > Invade International Ltd > > Unit 6, Badminton Court, Station Road, Bristol > BS37 5HZ, United Kingdom > ------------------------------------------------------ > Company Registration Number: 3660482 > 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:31, Mantas Mikulėnas <graw...@gmail.com> wrote: > >> 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.jim...@invade.net> 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-failure >>> >>> Kind regards, >>> >>> >>> *Raúl Jimeno* >>> >>> IT Support Engineer >>> >>> INVADE International Ltd >>> +44 33 3344 0784 (Office) >>> +44 117 3251309 (Direct) >>> raul.jim...@invade.net >>> http://www.invade.net <http://support.invade.net/> >>> >>> Invade International Ltd >>> >>> Unit 6, Badminton Court, Station Road, Bristol >>> BS37 5HZ, United Kingdom >>> ------------------------------------------------------ >>> Company Registration Number: 3660482 >>> 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 <graw...@gmail.com> >>> 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.jim...@invade.net> 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 versions >>>>> Issue Details: >>>>> >>>>> - >>>>> >>>>> When starting Asterisk with systemctl, it fails due to a timeout: >>>>> >>>>> sudo systemctl start asterisk >>>>> Job for asterisk.service failed because a timeout was exceeded. >>>>> See "systemctl status asterisk.service" and "journalctl -xe" for >>>>> details. >>>>> >>>>> - >>>>> >>>>> systemctl status asterisk shows the service in an "activating" >>>>> state for a while before timing out: >>>>> >>>>> asterisk.service - Asterisk PBX and telephony daemon >>>>> Loaded: loaded (/etc/systemd/system/asterisk.service; enabled; vendor >>>>> preset: disabled) >>>>> Active: activating (start) since Tue 2024-12-17 16:22:36 EET; 21s ago >>>>> >>>>> - >>>>> >>>>> After 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: >>>>> >>>>> 1. Different versions of Asterisk have been tested — the issue >>>>> persists. >>>>> 2. Asterisk was run manually, and it starts fine outside of >>>>> systemd. >>>>> 3. 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. >>>>> >>>>> >>>>> Kind regards, >>>>> >>>>> >>>>> *Raúl Jimeno* >>>>> >>>>> IT Support Engineer >>>>> >>>>> INVADE International Ltd >>>>> +44 33 3344 0784 (Office) >>>>> +44 117 3251309 (Direct) >>>>> raul.jim...@invade.net >>>>> http://www.invade.net <http://support.invade.net/> >>>>> >>>>> Invade International Ltd >>>>> >>>>> Unit 6, Badminton Court, Station Road, Bristol >>>>> BS37 5HZ, United Kingdom >>>>> ------------------------------------------------------ >>>>> Company Registration Number: 3660482 >>>>> 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: >>>>> 3660482 >>>>> 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: >>> 3660482 >>> 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: 3660482 > 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. >
