Bug 1119818

Summary:	radicale needs network-online.target instead of network.target
Product:	[Fedora] Fedora	Reporter:	Corinna Vinschen <vinschen>
Component:	radicale	Assignee:	Juan Orti <jorti>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	high
Version:	20	CC:	jorti, opensource, psimerda
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	radicale-0.8-10.fc20	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-08-07 15:26:37 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:
Bug Depends On:
Bug Blocks:	1119787

Description Corinna Vinschen 2014-07-15 15:10:50 UTC

Description of problem: radicale starts before network initialization is complete

Version-Release number of selected component (if applicable): 
radicale-0.8-7.fc20.noarch

How reproducible: Configure radicale to listen on explicit static interface address.

Steps to Reproduce:
1. reboot system

Actual results: radicale silently fails to start.

Expected results: radicale starts

Additional info: This is a generic problem with all services binding to explicit interface addresses and depending on network.target only.  network.target does not make sure that all statically configured interfaces are up.  Onle network-online.target does that.  Therefore the solution for all configurable services not supporting IP_FREEBIND is to change the dependency
from network.target to a depedency on network-online.target:

  Requires=network-online.target
  After=network-online.target

Other network services are affected as well so this bug  report is only one in a row.

Comment 1 Juan Orti 2014-07-16 08:30:17 UTC

I'm not sure if it's a good idea to add those dependencies. Many systems will be configured binding to 0.0.0.0, and if an administrator wants to bind to an explicit IP, he should also add those dependencies to /etc/systemd/system/radicale.service

Maybe it will be better to add a readme explaining this problem.

Comment 2 Corinna Vinschen 2014-07-16 11:42:13 UTC

The problem is that the service settings are not safe.

You have the choice between fast and safe.  The default settings should opt
for being safe.  The behaviour that the service is started before the network is up and then fails is surprising, to say the least.

Alternatively the server should use the IP_FREEBIND setsockopt option, in which
case defaulting to network.target is safe again.

Comment 3 Pavel Šimerda (pavlix) 2014-07-17 08:03:56 UTC

(In reply to Juan Orti Alcaine from comment #1)
> I'm not sure if it's a good idea to add those dependencies. Many systems
> will be configured binding to 0.0.0.0, and if an administrator wants to bind
> to an explicit IP, he should also add those dependencies to
> /etc/systemd/system/radicale.service

IP_FREEBIND is a much better solution than forcing the user to reconfigure systemd whenever he wants the service to listen on a specific IP.

Comment 4 Fedora Update System 2014-07-17 16:41:29 UTC

radicale-0.8-10.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/radicale-0.8-10.fc20

Comment 5 Fedora Update System 2014-07-19 05:57:38 UTC

Package radicale-0.8-10.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing radicale-0.8-10.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-8483/radicale-0.8-10.fc20
then log in and leave karma (feedback).

Comment 6 Corinna Vinschen 2014-07-21 19:02:43 UTC

radicale-0.8-10.fc20 works for me.


Thanks,
Corinna

Comment 7 Fedora Update System 2014-08-07 15:26:37 UTC

radicale-0.8-10.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.