Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 493070 - sys-apps/openrc-0.12.4 - "WARNING: dnsmasq is scheduled to start when net.wlp3s0 has started" is ambiguous
Summary: sys-apps/openrc-0.12.4 - "WARNING: dnsmasq is scheduled to start when net.wlp...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: OpenRC (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: OpenRC Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 481182
  Show dependency tree
 
Reported: 2013-12-01 21:15 UTC by Toralf Förster
Modified: 2013-12-19 13:03 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Toralf Förster gentoo-dev 2013-12-01 21:15:37 UTC
I got this during boot:

* WARNING: dnsmasq is scheduled to start when net.wlp3s0 has started

when the service dnsmasq is added to the runlevel. But what does the message says ? My understanding as a non-native (d)english speaker is :
"Heh - I do not need to add dnsmasq, it is already scheduled !" - but that's obviously wrong.

So the message should explain in more detail, why tp schedule dnsmasq in parallel to net.* might be the problem.
Comment 1 William Hubbs gentoo-dev 2013-12-03 16:52:12 UTC
(In reply to Toralf Förster from comment #0)
> I got this during boot:
> 
> * WARNING: dnsmasq is scheduled to start when net.wlp3s0 has started
> 
> when the service dnsmasq is added to the runlevel. But what does the message
> says ? My understanding as a non-native (d)english speaker is :
> "Heh - I do not need to add dnsmasq, it is already scheduled !" - but that's
> obviously wrong.
>
> So the message should explain in more detail, why tp schedule dnsmasq in
> parallel to net.* might be the problem.

Would this be more clear:

* WARNING: dnsmasq will not start until net.wlp3s0 has started

Thanks,

William
Comment 2 Toralf Förster gentoo-dev 2013-12-03 16:55:02 UTC
(In reply to William Hubbs from comment #1)
 Would this be more clear:
> 
> * WARNING: dnsmasq will not start until net.wlp3s0 has started
> 
> Thanks,
> 
> William

That I do understand ;)
Comment 3 William Hubbs gentoo-dev 2013-12-04 00:48:30 UTC
I thought of a possibly better option. In the original message, how
about "will start" instead of "is scheduled to start"?
Comment 4 Toralf Förster gentoo-dev 2013-12-04 15:45:10 UTC
(In reply to William Hubbs from comment #3)
> I thought of a possibly better option. In the original message, how
> about "will start" instead of "is scheduled to start"?

sth "... will be started after ... was started" - yes, why not
Comment 5 William Hubbs gentoo-dev 2013-12-13 18:14:33 UTC
A clarified wording of these messages is in commit 7a35dae and will be
part of OpenRC-0.13.
Comment 6 Toralf Förster gentoo-dev 2013-12-18 20:31:14 UTC
BTW, shouldn't ntpdate be delayed too ? Today it complained that network wasn't reachable...
Comment 7 Thomas Deutschmann (RETIRED) gentoo-dev 2013-12-19 13:03:04 UTC
It is not OpenRC which is delaying something (e.g. no special treatment for dnsmasq).

The runscript from net-dns/dnsmasq has set 'rc_need="net"' whereas net-misc/ntp which provides the runscript "ntp-client" which will call "ntpdate" per default has only set 'rc_after="net"'.

I don't understand why net-dns/dnsmasq needs net per default. I don't think it is really required because I think the daemon will start without net.
Yes, when configured as external resolver it won't be able to resolve anything until it has an external connection but if this is a requirement (e.g. you could use dnsmasq as internal dns only, e.g. providing all the zone data it should serve) you have to set it on your own in "/etc/conf.d/dnsmasq".
So dnsmasq is probably misusing "net", see bug 439092.

(If you bind a service to an interface you should always set 'rc_need="!net net.<interface_you_want_to_bind_to>"')


Now let's talk about net-misc/ntp which provides "ntp-client" which would use "ntpdate" per default:

If you think the defaults are wrong, e.g. it should depend on net, fill a bug against net-misc/ntp :)

But see bug 473222 first...