[systemd-devel] The unit asterisk.service has entered the 'failed' state with result 'timeout'

[Mantas Mikulėnas]

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 at 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.jimeno at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20241217/2318cce7/attachment.htm>