LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)
-   -   RTNETLINK answers: File exists - Error when doing ifup on alias (eth1:1) on RHEL5 (https://www.linuxquestions.org/questions/linux-networking-3/rtnetlink-answers-file-exists-error-when-doing-ifup-on-alias-eth1-1-on-rhel5-710766/)

MensaWater 03-11-2009 10:20 AM

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.

archtoad6 10-26-2010 04:10 AM

Thanks for taking the time to write this up & post it. Let's hope it does indeed help someone else.

7rx 02-04-2011 01:57 PM

Thanks
 
Thanks, this was exactly what I was looking for. Now if only all my questions were pre-answered like this!

hermanchen 05-11-2011 10:19 PM

helped me also
 
thanks!

mark. 05-28-2011 10:51 AM

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

archtoad6 05-29-2011 08:53 AM

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".

mark. 05-30-2011 07:31 AM

Quote:

Originally Posted by archtoad6 (Post 4370134)
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".

You can always click the little scales under MensaWater's name to give him Rep for the post ;-)

archtoad6 06-01-2011 10:03 AM

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.

tallship 08-25-2011 03:59 PM

Quote:

Originally Posted by mark. (Post 4370938)
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:

Code:

# 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.

Kindest regards,

Predatorian 08-14-2013 01:19 PM

This didn't exactly work for me, but what I had to do was

Code:

ifconfig eth0:1 192.168.2.1
instead of using a 192.168.1.1 address which was not being used. When ifup eth0:1 didn't work, I used ifconfig, and it gave me a different result.

Code:

SIOCSIFADDR: File exists
SIOCSIFFLAGS: Cannot assign requested address

So that's when I assigned it a odd IP address, and it worked for me.

MensaWater 08-22-2013 08:18 AM

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.

Predatorian 08-23-2013 08:26 AM

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.

bobdrad 05-19-2014 12:01 PM

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.

gessejomez 07-06-2014 12:12 AM

Red Hat's workaround worked for me - https://access.redhat.com/solutions/26543

MensaWater 07-07-2014 07:35 AM

Quote:

Originally Posted by gessejomez (Post 5199356)
Red Hat's workaround worked for me - https://access.redhat.com/solutions/26543

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.


All times are GMT -5. The time now is 04:25 AM.