Bug 183407 - [rc.d] [patch] Routing restart returns non-zero exitcode in case of no extra routing parameter or missing atm/ipx
Summary: [rc.d] [patch] Routing restart returns non-zero exitcode in case of no extra ...
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: conf (show other bugs)
Version: unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-net mailing list
URL:
Keywords:
Depends on:
Blocks: 202602
  Show dependency treegraph
 
Reported: 2013-10-28 16:00 UTC by abhikumar163
Modified: 2018-05-28 19:47 UTC (History)
1 user (show)

See Also:


Attachments
file.diff (3.68 KB, patch)
2013-10-28 16:00 UTC, abhikumar163
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
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).

Perform
`/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 
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.