Bug 1471722

Summary:	systemd unit probably needs to have more requisites
Product:	[Fedora] Fedora EPEL	Reporter:	Brian J. Murrell <brian>
Component:	asterisk	Assignee:	EPEL Packagers SIG <epel-packagers-sig>
Status:	CLOSED EOL	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	epel7	CC:	davek, g.devel, jsmith.fedora, rbryant
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2024-07-09 02:07:36 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Brian J. Murrell 2017-07-17 10:42:48 UTC

Description of problem:
On system reboot, Asterisk does not start properly.  Typically SIP channels are unconnected.

Version-Release number of selected component (if applicable):
asterisk-13.11.1-1.el7

How reproducible:
100%

Steps to Reproduce:
1. Build from https://src.fedoraproject.org/cgit/rpms/asterisk.git/ on EL7
2. Configure, including a SIP channel, using hostname(s) for the target
3. Reboot system

Actual results:
Asterisk starts but doesn't connect to SIP provider.  Once booted, restarting Asterisk is successful.
Message such as:
[Jul 17 01:26:51] ERROR[4193] netsock2.c: getaddrinfo("sip.sip-provider.example.com", "(null)", ...): Name or service not known

Expected results:
Should restart and work without intervention.  Shouldn't be name resolution errors in the log.

Additional info:
I suspect that the system unit file for Asterisk probably needs to wait for more services to be up before allowing Asterisk to be started.  At minimum, I would think you want any name resolution services up.

Comment 1 Dave Koberstein 2018-03-05 04:04:45 UTC

I've found that changing "After=" in systemctl to be network-online.target resolves this issue.

Is this something that should be changed at the fedora level or upstream?

Work around for other users:
sudo systemctl edit asterisk

Add these lines:

[Unit]
After=
After=network-online.target

Save file
sudo systemctl daemon-reload

And then sip channel will come up correctly on a boot.

Comment 2 Brian J. Murrell 2018-03-05 13:21:01 UTC

(In reply to Dave Koberstein from comment #1)
> 
> Is this something that should be changed at the fedora level or upstream?

Fedora packaging is providing it's own asterisk.service file:

https://src.fedoraproject.org/cgit/rpms/asterisk.git/tree/asterisk.service?h=master

so this needs to be fixed there.

> Work around for other users:
> sudo systemctl edit asterisk
> 
> Add these lines:
> 
> [Unit]
> After=
> After=network-online.target

Nice.  I've created https://src.fedoraproject.org/rpms/asterisk/pull-request/3 to get this fixed in the Fedora/EPEL packaging.

Comment 3 Jared Smith 2018-03-06 10:22:23 UTC

I'm glad you were able to track down the issue.

I've merged the pull request, and pushed the changes to rawhide.  I'll try to get other branches built over the next day or two, but I'm traveling, and have limited internet access.

Comment 4 Brian J. Murrell 2018-03-14 12:01:40 UTC

After having run with this change for a bit, I don't think it's quite enough.  I don't think the network-online.target implies that name services are up and running yet.  So one can hit that target before DNS is actually available, Asterisk starts up but DNS has not started or at least completed starting.

Comment 5 Brian J. Murrell 2018-03-14 12:09:48 UTC

Do we actually want "nss-lookup.target" here rather than network-online.target?

Comment 6 Fedora Admin user for bugzilla script actions 2022-09-09 12:08:05 UTC

This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.

Comment 7 Troy Dawson 2024-07-09 02:07:36 UTC

EPEL 7 entered end-of-life (EOL) status on 2024-06-30.\n\nEPEL 7 is no longer maintained, which means that it\nwill not receive any further security or bug fix updates.\n As a result we are closing this bug.