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. |
Thanks for taking the time to write this up & post it. Let's hope it does indeed help someone else.
|
Thanks
Thanks, this was exactly what I was looking for. Now if only all my questions were pre-answered like this!
|
helped me also
thanks!
|
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. Thanks again. mark |
Thanks to those who took the time to give rep for the post. Too bad the 1st post in a thread is presumed to be a question & can't be marked "Helpful".
|
Quote:
|
Indeed, at least 3 people did just that. My point is that each could have given a well deserved extra point through the "helpful" system if it were available.
|
Quote:
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: Code:
# service network restart 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. Kindest regards, |
This didn't exactly work for me, but what I had to do was
Code:
ifconfig eth0:1 192.168.2.1 Code:
SIOCSIFADDR: File exists |
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. |
Red Hat's workaround worked for me - https://access.redhat.com/solutions/26543
|
Quote:
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. |
All times are GMT -5. The time now is 04:25 AM. |