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

[Raul Jimeno]

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/4e7bc9d0/attachment-0001.htm>