Bug 183407

Summary: [rc.d] [patch] Routing restart returns non-zero exitcode in case of no extra routing parameter or missing atm/ipx
Product: Base System Reporter: abhikumar163
Component: confAssignee: freebsd-net (Nobody) <net>
Status: Open ---    
Severity: Affects Only Me CC: pi
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   
Bug Depends on:    
Bug Blocks: 202602    
Description Flags
file.diff none

Description abhikumar163 2013-10-28 16:00:00 UTC
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).

`/etc/rc.d/routing restart ; echo $?`

This will show a non-zero exitcode for routing service restart action.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2013-10-29 19:38:37 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-net

Over to maintainer(s).
Comment 2 J.R. Oldroyd 2014-02-22 17:07:10 UTC
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.
Comment 3 Kurt Jaeger freebsd_committer 2016-10-21 10:22:27 UTC
problem can still be reproduced.
Comment 4 Kurt Jaeger freebsd_committer 2016-10-21 10:24:35 UTC
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).
Comment 5 abhikumar163 2016-10-21 11:45:05 UTC
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
Comment 6 Kurt Jaeger freebsd_committer 2016-10-21 11:50:24 UTC
Yes, you can submit a new patch, using the 'add an attachment' link in bugzilla, and mark the old patch obsolete.
Comment 7 Kurt Jaeger freebsd_committer 2016-10-21 11:50:44 UTC
Btw, ipx was removed, so that's basically the cause of the patch to fail.
Comment 8 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:47:55 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
- Untouched since 2018-01-01.
- Affects Base System OR Documentation


Reset to open status.

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.