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

Tue Dec 17 17:39:52 UTC 2024

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.jimeno at 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.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.
>
>
> On Tue, 17 Dec 2024 at 17:31, Mantas Mikulėnas <grawity at 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.jimeno at 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.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.
>>>
>>>
>>> On Tue, 17 Dec 2024 at 17:08, Mantas Mikulėnas <grawity at 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.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.
>>>>>
>>>>
>>>
>>>
>>> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20241217/adbbd182/attachment-0001.htm>