Current "/etc/rc.d/routing" script is as such it returns non-zero exitcode on restart in very common cases. There are 2 issues in total... Issue#1. It unsets a var and only in case any additional routing options of the provided communication channel (inet, inet6, atm, ipx) is to be turned on, it gets set. It fails for us as we don't have any extra routing options. For now I've patched it not to fail in case of no additional routing options. Do check if any additional routing option is required or not. Issue#2. There is also error in default case of routing start, where it tries to setroute for all (inet, inet6, atm, ipx) modes. Before that it checks if it's present or not and fails for atm and ipx not being present. Since script is resilient enough, the required configuration gets applied. But the exitcode is erroneous which fails our configuration management tools by making them think the run failed itself. Fix: Patch attached with submission follows: How-To-Repeat: Shall happend for any install. But to be sure install it on a Virtualbox or any virtualization platform (have myself tried it on Xen and VirtualBox). Perform `/etc/rc.d/routing restart ; echo $?` This will show a non-zero exitcode for routing service restart action.
Responsible Changed From-To: freebsd-bugs->freebsd-net Over to maintainer(s).
I've received bug reports for wifimgr(8) when it resets interfaces using "/etc/rc.d/netif restart ifname" which calls /etc/rc.d/routing which is returning an incorrect value of 1. The patch proposed here does indeed fix things.
problem can still be reproduced.
the patch fails, needs to be updated: Hunk #1 failed at 21. Hunk #2 failed at 50. Hunk #3 succeeded at 67 (offset 2 lines). Hunk #4 failed at 86. Hunk #5 succeeded at 325 (offset 9 lines). Hunk #6 succeeded at 329 (offset 2 lines). Hunk #7 succeeded at 345 (offset 9 lines). Hunk #8 succeeded at 347 (offset 2 lines). Hunk #9 succeeded at 363 (offset 9 lines). Hunk #10 succeeded at 365 (offset 2 lines). Hunk #11 succeeded at 381 (offset 9 lines). Hunk #12 succeeded at 382 (offset 2 lines). Hunk #13 failed at 399. Hunk #14 succeeded at 409 with fuzz 1 (offset -13 lines).
this patch was submitted 2years back, somethings must have changed... I'll update and re-submit can I update this patch request itself, please guide
Yes, you can submit a new patch, using the 'add an attachment' link in bugzilla, and mark the old patch obsolete.
Btw, ipx was removed, so that's basically the cause of the patch to fail.
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Keyword: patch or patch-ready – in lieu of summary line prefix: [patch] * bulk change for the keyword * summary lines may be edited manually (not in bulk). Keyword descriptions and search interface: <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>