Created attachment 384240 [details] debugging output of dhcpcd-hooks/50-ntp.conf net-misc/dhcpcd-6.4.3 used as network manager instead of netifrc does not start/stop network dependant services like ntpd, sshd, fetchmail. See http://forums.gentoo.org/viewtopic-p-7612860.html#7612860
To aid the writing of such a hook, I've added this patch upstream: http://roy.marples.name/projects/dhcpcd/ci/1113488b81673c23b3b079e1fc5ea6df5ffc0ee5?sbs=0 This allows the hook to test for the variables if_oneup == true|false and if_ipwaited == true|false. The logic should be if $if_oneup && if_ipwaited then; mark_service_started dhcpcd else mark_service_inactive dhcpcd fi Although that's typed above without any testing and I've not even looked at that part of OpenRC in years so tweak accordingly. This should be the last hook run, so maybe call it 99-openrc.
Created attachment 384408 [details, diff] Add IN_BACKGROUND support to runscript service templates
Created attachment 384410 [details, diff] Mark the dhcpcd service as starting inactive
Created attachment 384414 [details] 99-openrc dhcpcd hook script
The patch to OpenRC, the dhcpcd init script and the OpenRC dhcpcd hook once all added allows dhcpcd to start and stop net dependent services based on the state of dhcpcd's interfaces.
(In reply to Roy Marples from comment #2) > Created attachment 384408 [details, diff] [details, diff] > Add IN_BACKGROUND support to runscript service templates This is bad sh, robustness/portability-wise: [ "$IN_BACKGROUND" = true ] Standard pattern is like this (for literals): [ true = "$IN_BACKGROUND" ] ..which won't break in a snafu. I know you likely just did that without thinking since you're busy with other stuff. Personally I don't like using: if $truvar; then.. at all. If it's project-internal, use a 0|1 value, which works fine with your yesno function, and allows for: [ 1 -eq "${foo:=0}" ] # to give an error message during development, but function correctly in production (where the error message is also ofc useful; after all, users are our developers, as well as our QA dept.) More efficient (in the general case, for any sh), which answers the snipes from "alternative-init wankers" ;) Not our fault they don't know sh and reinvent it with v8 js instead (of all things.. :roll:) Admins can evidently script using the yesno function, so that side is covered. It's not something they should set afaics, merely use as a data-point. Anyhow thanks for the lovely work on dhcpcd and openrc both.
(In reply to Steve L from comment #6) > (In reply to Roy Marples from comment #2) > > Created attachment 384408 [details, diff] [details, diff] [details, diff] > > Add IN_BACKGROUND support to runscript service templates > > This is bad sh, robustness/portability-wise: > [ "$IN_BACKGROUND" = true ] Why? The variable could be unset and the construct works across every POSIX shell I've used. > Standard pattern is like this (for literals): > [ true = "$IN_BACKGROUND" ] > ..which won't break in a snafu. I know you likely just did that without > thinking since you're busy with other stuff. You just swapped RHS with LHS which makes for very unreadable code especially as variable assignment in sh is very different from equality tests. IMHO :) > Personally I don't like using: if $truvar; then.. at all. If it's > project-internal, use a 0|1 value, which works fine with your yesno > function, and allows for: [ 1 -eq "${foo:=0}" ] # to give an error message > during development, but function correctly in production (where the error > message is also ofc useful; after all, users are our developers, as well as > our QA dept.) > > More efficient (in the general case, for any sh), which answers the snipes > from "alternative-init wankers" ;) Not our fault they don't know sh and > reinvent it with v8 js instead (of all things.. :roll:) Admins can evidently > script using the yesno function, so that side is covered. It's not something > they should set afaics, merely use as a data-point. > > Anyhow thanks for the lovely work on dhcpcd and openrc both. Not going to argue the above, but the variable and it's content actually pre-dates OpenRC by some way and is used in baselayout-1 scripts. Saying that, probably not much actually uses it. A quick scan of portage shows this: $ grep IN_BACKGROUND=true * -R net-misc/openvpn/files/down.sh: export IN_BACKGROUND=true net-misc/openvpn/files/up.sh: export IN_BACKGROUND=true net-wireless/wpa_supplicant/files/wpa_cli.sh:export IN_BACKGROUND=true sys-apps/ifplugd/files/ifplugd.action:export IN_BACKGROUND=true sys-apps/netplug/files/netplug-2:export IN_BACKGROUND=true sys-freebsd/freebsd-sbin/files/devd_queue:export IN_BACKGROUND=true $ Feel free to change it, but revbump the above if you do :)
New dhcpcd patch to pass SVCNAME from environment to hooks: http://roy.marples.name/projects/dhcpcd/ci/3c8ccc317ece2e585d93f66ae7b0045d0994a0e9?sbs=0
Created attachment 384442 [details] 99-openrc dhcpcd hook script Use $SVCNAME (default dhcpcd) instead of dhcpcd
Created attachment 384460 [details] Fails to stop ntpd For fetchmail it works perfectly, "terminated with signal 15", and correctly brings it up again. But ntpd would not be stopped, instead proceeds with another process id.
By default, ntpd uses net, it does not need net. As such it won't stop when net does. You could add this to /etc/rc.conf rc_ntpd_need="dhcpcd"
I would probably do this in /etc/conf.d/ntpd: rc_need="dhcpcd" Although this isn't really necessary, because ntpd is smart enough in its default mode to be able to sense when the network goes up and down. See bug #439392 for the issues with "need net" misuse.
That reference should have been to bug #439092.
(In reply to William Hubbs from comment #12) > I would probably do this in /etc/conf.d/ntpd: > > rc_need="dhcpcd" I prefer one config file vs many, but heh, each to their own. > Although this isn't really necessary, because ntpd is smart enough in > its default mode to be able to sense when the network goes up and down. > > See bug #439392 for the issues with "need net" misuse. Very true and the default script is fine. But that is not the behavior the OP wants.
O another subject, all of the patches etc should use $RC_SVCNAME instead of $SVCNAME. Thanks, William
(In reply to Roy Marples from comment #14) > (In reply to William Hubbs from comment #12) > > [...] > > Although this isn't really necessary, because ntpd is smart enough in > > its default mode to be able to sense when the network goes up and down. > > [...] > > Very true and the default script is fine. But that is not the behavior the > OP wants. The OP was not aware of ntpd's smartness. The main topic was stopping services when they are useless.
Created attachment 384626 [details] 99-openrc dhcpcd hook script Use RC_SVCNAME
Version 6.4.4 of net-misc/dhcpcd solves the problem and is in portage now. This bug may be closed.
(In reply to charles17 from comment #18) > Version 6.4.4 of net-misc/dhcpcd solves the problem and is in portage now. > This bug may be closed. Really? I don't see eg. Comment #2 committed
(In reply to Samuli Suominen from comment #19) > (In reply to charles17 from comment #18) > > Version 6.4.4 of net-misc/dhcpcd solves the problem and is in portage now. > > This bug may be closed. > > Really? I don't see eg. Comment #2 committed Oops, you're right. That one would need to go into openrc, correct? How to handle, open another bug for openrc or integrate it in bug 523000 ?
(In reply to charles17 from comment #20) > (In reply to Samuli Suominen from comment #19) > > (In reply to charles17 from comment #18) > > > Version 6.4.4 of net-misc/dhcpcd solves the problem and is in portage now. > > > This bug may be closed. > > > > Really? I don't see eg. Comment #2 committed > > Oops, you're right. > That one would need to go into openrc, correct? > > How to handle, open another bug for openrc or integrate it in bug 523000 ? this bug is assigned to the openrc maintainer, williamh, so you don't have to do anything, just wait for him to react
There are seven attachments on this bug, so I'm a little confused about which ones I need.
(In reply to William Hubbs from comment #22) > There are seven attachments on this bug, so I'm a little confused about > which ones I need. https://bugs.gentoo.org/attachment.cgi?id=384408 https://bugs.gentoo.org/attachment.cgi?id=384410 https://bugs.gentoo.org/attachment.cgi?id=384410 BUT in the ideal world we should add an --ifinactive flag to rc-service before applying and then adjust the patches accordingly I *could* do if ! /etc/init.d/dhcpcd status ; then instead, but that requires the full path and rc-service is much better Maybe grow an --ifnotstarted flag as well for completeness.
You listed one patch twice above, was that a typo, or is there a third patch?
https://522206.bugs.gentoo.org/attachment.cgi?id=384626
Is https://bugs.gentoo.org/attachment.cgi?id=384408 still valid for sys-apps/openrc-0.13.7 ?
(In reply to charles17 from comment #26) > Is https://bugs.gentoo.org/attachment.cgi?id=384408 still valid > for sys-apps/openrc-0.13.7 ? I don't think so because runscript.c handles it. Been a while since I looked at this though.
Created attachment 396740 [details] More detailed log twice stopping/restarting with RFKill button (In reply to Roy Marples from comment #27) > (In reply to charles17 from comment #26) > > Is https://bugs.gentoo.org/attachment.cgi?id=384408 still valid > > for sys-apps/openrc-0.13.7 ? > > I don't think so because runscript.c handles it. > Been a while since I looked at this though. It even works with sys-apps/openrc-0.13.9 but there is a problem with RFKill. Guess I simply didn't notice that before. On boot I get configuration of IPv4 and IPv6: $ dhcpcd-qt Connecting ... Status changed to opened Connected to dhcpcd-6.6.7 Status changed to connected wlp8s0: Associated with wlp8s0: Configured 192.168.178.23/24 wlp8s0: Configured fd00::9d84:f732:1cd9:6628/64 enp2s14: Link is down wlp8s0: Received scan results When stopping and restarting the AP both come back. stopping AP wlp8s0: Not associated Status changed to disconnected wlp8s0: Received scan results starting AP wlp8s0: Received scan results wlp8s0: Received scan results wlp8s0: Received scan results wlp8s0: Associated with Status changed to connecting wlp8s0: Configured fd00::9d84:f732:1cd9:6628/64 Status changed to connected wlp8s0: Configured 192.168.178.23/24 wlp8s0: Configured fd00::9d84:f732:1cd9:6628/64 wlp8s0: Configured fd00::9d84:f732:1cd9:6628/64 wlp8s0: Configured fd00::9d84:f732:1cd9:6628/64 After stopping and restarting by RFKill button only IPv4 comes back, no IPv6 stopping wlp8s0: Not associated Status changed to disconnected restarting wlp8s0: Received scan results wlp8s0: Associated with Status changed to connecting wlp8s0: Configured 192.168.178.23/24 Status changed to connected wlp8s0: Received scan results
Can you post `ip a` output when recovering from rfkill? I suspect the link-local address is missing.
Created attachment 396782 [details] ip a (In reply to Roy Marples from comment #29) > Can you post `ip a` output when recovering from rfkill? > I suspect the link-local address is missing. See attachment.
> inet6 fe80::b7ef:4566:e492:4625/64 scope link > valid_lft forever preferred_lft forever That address is missing when recovering from RF kill and is stopping IPv6 from completing. dhcpcd should re-add it though, I wonder why it doesn't. Can you do this please in an xterm, with the it all working. dhcpcd -x dhcpcd -dB6 Then kill and restore the RFkill switch. Hopefully dhcpcd will have spat out a load of messages which you can copy and paste into a new attachment for me :)
Created attachment 396822 [details] dhcpcd -dB6 (In reply to Roy Marples from comment #31) > [...] > Can you do this please in an xterm, with the it all working. > dhcpcd -x > dhcpcd -dB6 > > Then kill and restore the RFkill switch. See attachment
Can you attach your dhcpcd.conf as well please?
Created attachment 396830 [details] dhcpcd.conf (In reply to Roy Marples from comment #33) > Can you attach your dhcpcd.conf as well please? Added
Shouldn't this depend on Bug 523174 instead of blocking it? And, could it please come true in OpenRC-0.14?
Created attachment 402856 [details, diff] runscript-background.patch, updated for epatch_user (In reply to Roy Marples from comment #2) > Created attachment 384408 [details, diff] [details, diff] > Add IN_BACKGROUND support to runscript service templates Updated for openrc-0.13.11 for epatch_user, to be dropped into /etc/portage/patches/sys-apps/openrc-0.13.11/
Created attachment 402858 [details, diff] 99-openrc_dhcpcd_hook.patch, updated for epatch_user (In reply to Roy Marples from comment #17) > Created attachment 384626 [details] > 99-openrc dhcpcd hook script > > Use RC_SVCNAME Updated for dhcpcd-6.6.7 for epatch_user, to be dropped into /etc/portage/patches/net-misc/dhcpcd-6.6.7/
(In reply to Roy Marples from comment #2) > Created attachment 384408 [details, diff] [details, diff] > Add IN_BACKGROUND support to runscript service templates Since runscript.sh has been replaced with openrc-run for newer OpenRC, this patch no longer works. Please provide a new patch for sys-apps/openrc-0.16.4.
Created attachment 415554 [details, diff] 99-openrc_dhcpcd_hook.patch for dhcpcd-6.9.3, suitable for epatch_user (In reply to charles17 from comment #37) > Created attachment 402858 [details, diff] [details, diff] > 99-openrc_dhcpcd_hook.patch, updated for epatch_user > [...] > Updated for dhcpcd-6.6.7 for epatch_user, to be dropped > into /etc/portage/patches/net-misc/dhcpcd-6.6.7/ charles17's patch (attachmet 402858) worked fine for me for dhcpcd-6.9.1, but for dhcpcd-6.9.3, I had to remove the "10-mtu" reference from the Makefile, because the mtu hook is gone (see http://roy.marples.name/projects/dhcpcd/info/26896eb763faaf9b).
(In reply to karsten_s from comment #39) > charles17's patch (attachmet 402858) worked fine for me for dhcpcd-6.9.1, > but for dhcpcd-6.9.3, I had to remove the "10-mtu" reference from the > Makefile, because the mtu hook is gone (see > http://roy.marples.name/projects/dhcpcd/info/26896eb763faaf9b). my bad - this is the actual commit where the 10-mtu hook gets deleted: http://roy.marples.name/projects/dhcpcd/info/2195587ec636ec63
(In reply to karsten_s from comment #39) > [...] > charles17's patch (attachmet 402858) worked fine for me for dhcpcd-6.9.1, > but for dhcpcd-6.9.3, I had to remove the "10-mtu" reference from the > Makefile, because the mtu hook is gone (see > http://roy.marples.name/projects/dhcpcd/info/26896eb763faaf9b). @ karsten_s Which version of OpenRC do you have and how did you patch it? Do you have a replacement for attachment 384408 [details, diff] (comment #38)?
(In reply to charles17 from comment #41) > @ karsten_s > Which version of OpenRC do you have and how did you patch it? > Do you have a replacement for attachment 384408 [details, diff] [details, diff] (comment > #38)? I'm actually still on openrc-0.12.4-r4. I've used your attachment 402856 [details, diff] to patch it. Sorry, can't help you on that end. I actually only noticed the update because I didn't have ftp or samba access to my box when I needed it...