I have a desktop and a server. Desktop has eth5 getting an IP via DHCP, and mounts some smbfs shares via netmount. All works fine. Following the upgrade to openrc-0.11.5 netmount is stopped by default after net.eth5, therefore the umount hangs indefinitely. I have set rc_need="net.eth5 dhcpcd" as instructed by /etc/conf.d/netmount, but this does not seem to help. The only workaround I can find is to set need net in /etc/init.d/netmount, but it seems this is not the desired solution. As a conclusion, I believe it is a bug in OpenRC, where the rc_need in /etc/conf.d is only accounted for during startup, and not during shutdown. Reproducible: Always
(In reply to comment #0) > I have a desktop and a server. Desktop has eth5 getting an IP via DHCP, and > mounts some smbfs shares via netmount. All works fine. > > Following the upgrade to openrc-0.11.5 netmount is stopped by default after > net.eth5, therefore the umount hangs indefinitely. > > I have set rc_need="net.eth5 dhcpcd" as instructed by /etc/conf.d/netmount, > but this does not seem to help. The only workaround I can find is to set > need net in /etc/init.d/netmount, but it seems this is not the desired > solution. No, you should not touch /etc/init.d/netmount. Try setting this in /etc/conf.d/netmount: rc_need="net.eth5" If that doesn't work, try: rc_need="net" Let me know which one works.
as i mentioned in Bug 439660, the netmount defaults have to be smarter
@Vapier: Does commit 8661af3 make it more clear?
I have read the commit, which made it clear for me not to mix net.eth5 and dhcpcd in the rc_need settings. However, needing just net.eth5 does not seem to work either; here are the details: Test 1: rc_need="net.eth5". On reboot I could clearly see that net.eth5 was no longer stopped before netmount, but it still hung. However, I noticed above a line stating "Stopping DHCP Client daemon" above the hung "Unmounting network filesystems". My conclusion is that dhcpcd removed the IP from eth5, and umount hanged, but you would know more about these subtleties. Test 2: rc_need="net". Rebooted cleanly 2 times. Test 3: back to rc_need="net.eth5". Rebooted cleanly a few times. I assume that passing the dependency tree through need=net for netmount changed some ordering in whatever caches live in /lib/rc, so that by accident now the situation where it hangs no longer occurs. However, this points to the fact that your tests should account for such cases. I can provide more info if you instruct me how.
(In reply to comment #4) > Test 1: rc_need="net.eth5". On reboot I could clearly see that net.eth5 was > no longer stopped before netmount, but it still hung. However, I noticed > above a line stating "Stopping DHCP Client daemon" above the hung > "Unmounting network filesystems". My conclusion is that dhcpcd removed the > IP from eth5, and umount hanged, but you would know more about these > subtleties. > > Test 2: rc_need="net". Rebooted cleanly 2 times. > > Test 3: back to rc_need="net.eth5". Rebooted cleanly a few times. I should have had you run rc-update -u each time you changed the rc_need setting. It sounds like your cache may not have been updated right away.
The above-mentioned commit will be included in openrc-0.11.6 to make the setup more clear. Please re-open if there are still issues.
(In reply to comment #3) yep, that change looks great http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git;a=commitdiff;h=8661af3223d4115284fcebdf430017d19581d611
Seems that having rc_need="net.eth5" in /etc/conf.d/netmount works just fine. However, the system does not update dependencies without manually running rc-update -u. Perhaps this still needs to be addressed. Thanks for your support.
