Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#6237 - Loopback in rc.sysinit

Attached to Project: Arch Linux
Opened by James Rayner (iphitus) - Saturday, 20 January 2007, 04:19 GMT
Last edited by Tobias Powalowski (tpowa) - Sunday, 21 October 2007, 09:16 GMT
Task Type Feature Request
Category System
Status Closed
Assigned To Tobias Powalowski (tpowa)
Architecture not specified
Severity Low
Priority Normal
Reported Version 0.7.2 Gimmick
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Frequently people have problems because they've accidentally disabled loopback, and I've done it myself by accident too.

I can't think of any reason why it would need to be disabled, and if there is one, it certainly doesnt apply to the majority.

Maybe it would be better to add to the end of rc.sysinit:

status "Enabling loopback" ifconfig lo up

If users want to disable it, they can ifconfig lo down in rc.local or reconfigure it in /etc/rc.d/network.
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Sunday, 21 October 2007, 09:16 GMT
Reason for closing:  Fixed
Additional comments about closing:  in next initscripts
Comment by Tobias Powalowski (tpowa) - Tuesday, 27 February 2007, 22:55 GMT
well by default it is already turned on in rc.conf, if you chose to disable it there it's your choice already.
i think the solution how it is now is better and more logical then the rc.local fiddling which complicates it imho.
Comment by James Rayner (iphitus) - Wednesday, 28 February 2007, 08:02 GMT
I think you completely miss the point.

there's no reason for it to be down, so there's no reason for it not to be in rc.sysinit.

James
Comment by Dale Blount (dale) - Wednesday, 28 February 2007, 18:44 GMT
How does one disable loopback by accident? Doesn't it still start even if ethX fails?
Comment by James Rayner (iphitus) - Wednesday, 28 February 2007, 23:41 GMT
new users frequently remove it from the INTERFACES=() line.

It's just redundant being there though, if it's always going to be there, then it should just be hard coded else where, because there's no need to disable it.
Comment by Tobias Powalowski (tpowa) - Friday, 09 March 2007, 16:28 GMT
i don't see any reason to modify the rc.sysinit it works as it should by default.
it's the users fault if they remove the option.
Comment by James Rayner (iphitus) - Friday, 09 March 2007, 21:04 GMT
it should not be removable, because there's no reason to remove it.

it's redundant having it in a config, when *EVERY* user has it there enabled.

James
Comment by Travis Willard (Cerebral) - Friday, 09 March 2007, 23:03 GMT
I'm inclined to agree with James on this one - while it may logically group with the rest of the interfaces in rc.conf - if it's something that essentially *needs* to be enabled on most systems, it should be.
Comment by Tobias Powalowski (tpowa) - Friday, 09 March 2007, 23:14 GMT
it is enabled by default in config you need user interaction for disabling!
Comment by Alexander Baldeck (kth5) - Friday, 09 March 2007, 23:23 GMT
i do see a reason to have it configurable in rc.conf. it's a network interface like any other except for that it's not using actual hardware. for those smart enough this will never present a problem, they'll figure it out. for those wanting to configure more than just one loopback network interface this is worth while to keep their config consistent. i understand why an arch beginner would like to see this in rc.sysinit, none for experienced arch admins with special requirements though. for the latter arch is for.
Comment by Travis Willard (Cerebral) - Saturday, 10 March 2007, 03:20 GMT
hm - that is a valid point. Maybe some kind of compromise - have it configurable in rc.conf but put a comment in there saying "Don't diable lo unless you know what you're doing - can cause slowdowns" or whatever.
Comment by Jürgen Hötzel (juergen) - Saturday, 10 March 2007, 12:23 GMT
Maybe this comment is suitable:
Don't disable lo unless you know what you're doing. localhost (bound to lo by default) is often used for interprocess communication.
Comment by Glenn Matthys (RedShift) - Thursday, 18 October 2007, 08:49 GMT
IMHO leaving it in rc.conf and adding a Big Fat Warning (tm) is the best option.
Comment by Tobias Powalowski (tpowa) - Thursday, 18 October 2007, 08:51 GMT
that is done in new initscripts in testing
Comment by James Rayner (iphitus) - Thursday, 18 October 2007, 09:13 GMT
hooray!

Loading...