[SOLVED] RTNETLINK answers: File exists - Error when doing ifup on alias (eth1:1) on RHEL5
Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
RTNETLINK answers: File exists - Error when doing ifup on alias (eth1:1) on RHEL5
Posting this as a solution since I didn't see the exact question when I Googled and a lot of what is written is fairly esoteric and not really germane:
I'd created an ifcfg-eth1:1 on a RHEL5.3 server. On running "ifup eth1:1" I got the following error.
"RTNETLINK answers: File exists"
A Google search mentioned this various times but nothing truly consistent and nothing directly related to what I was doing. Some mentioned routing which made me look at "netstat -rn" outuput. I saw it had added a new bogus route to the table. Also there was some discussion of the fact that message is somewhat bogus as it isn't a regular "file" that exists but rather a "file" in the broad sense that sockets, shared memory segment, et al are considered "files".
One link mentioned /usr/share/doc/initscripts<version> directory.
Reviewing documents there led me to the realization that starting any alias for an interface will attempt to also invoke the routing created for that interface. (We have a route-eth1 file for this due to the fact that default gateway is on eth0 which is the external facing NIC.)
Further read indicated there is an option for alias files to start the alias interface at same time as primary or not. The default is to start at same time.
All this along with the bogus route led me to the conclusion the "file" that "exists" is the route added at start of eth1.
Resolution was simply to "ifdown eth1:1; ifdown eth1; ifup eth1". The ifup eth1 at end starts both the primary and the alias AND only sets the route once so I didn't see the error starting this way.
Last edited by MensaWater; 03-11-2009 at 02:35 PM.
Very useful, your post pointed me at the right thing straight away.
For my setup eth1 is a secondary interface on the local LAN, 10.0.0.4, given that eth0 is the external interface the default gateway set in /etc/sysconfig/network points out that way..
I had added a line into route-eth1 defining a static route for the same LAN as eth1 is already in as I am getting the odd issue with a vpn session in not getting traffic back, despite getting assigned an IP in the same range. But after adding the route i was getting the "RTNETLINK answers: File exists". No route had been added showing the gateway 10.1.0.254 so i removed the line/route and hey presto, no error message.
You can always click the little scales under MensaWater's name to give him Rep for the post ;-)
Well you learn something every day! That's what I did, and thanks for that tip too
wrt the error, I got the error on a CentOS box where I bonded a couple of NICs. The error was on bond0 when I did a:
# service network restart
What got me is that I've done this dozens of times and this was the only time I received the error - everything looked fine (ifconfig) and everything worked.
So then, I restarted the network again and no error. All was well in syslog too, so I still don't know what caused the error, but at least I know why it might occur if it happens again, and what I might do to alleviate the error.
The problem with what you did Predatorian is that is not persistent. That is to say while it set the IP for your current session it will go away next time you restart networking (e.g. when you reboot).
The reason I did the methodology originally written was to insure it was persistent.
Yea, I should have specified what I was using it for. I was trying to make an HA Cluster with Zabbix using FreeHA. I wanted it to be able to come up with my HA program, and if the system stopped, or restarted, then my cluster would pick up the VIP, and run normally.
The above solution didn't help me. It turns out that "RTNETLINK answers: File exists" can mask a number of different root causes. If you run "ifup <INTERFACE>" you should get a better error message.
In my case, the root cause of this message was another host on my network that had the same IP address. Easy to rectify, once I know what the heck was actually going on. That's a terrible error message.
1.) That post didn't exist 5 years ago when I first posted here.
2.) That post requires a login to the RedHat site to see the full detail. If you were seeing the message on CentOS, Scientific Linux or another RHEL derivative you probably don't have an account with RedHat.
3.) That post doesn't actually include a "workaround". It just explains the error can occur due to DHCP config (which I don't use in my environment by the way so wouldn't have explained the one I saw) and says the error can safely be ignored. My original post tells you how you can get rid of the error rather than saying it should be ignored.