ifdown: failed to open statefile /var/run/network/ifstate:

[Jeffrey Ratcliffe]

Binary package hint: ifupdown

Booting Jaunty, configuring networking interfaces fails, as does

~$ sudo /etc/init.d/networking restart
 * Reconfiguring network interfaces...
ifdown: failed to open statefile /var/run/network/ifstate: No such file or directory
ifup: failed to open statefile /var/run/network/ifstate: No such file or directory

If I mkdir /var/run/network/, then I get my network - for this boot, and have the same problem again the next time I boot.

[Jeffrey Ratcliffe (jeffreyratcliffe)]

Deleting /etc/udev/rules.d/85-ifupdown.rules fixed the problem

[Gustavo Niemeyer (niemeyer)]

Why has this been marked as Invalid? We've just upgraded a Jaunty machine to Karmic and had exactly the same problem. If this is a file which has to be removed, the upgrade should do something about it.

[Gustavo Niemeyer (niemeyer)]

We don't have this file by the way, and the problem still happens.

The directory /var/run/network doesn't exist, and that's the reason why the networking init.d script is failing. Something is removing the directory during reboot, since even if the directory is created by hand, it's gone on the next reboot.

[Scott James Remnant (Canonical) (canonical-scott)]

If you delete the /etc/udev/rules.d/85-ifupdown.rules file, does the problem go away?

[Bryce Thornton (brycethornton)]

I ran into this yesterday.

I had to manually create the /var/run/network directory and then manually create an "ifstate" file within it. I haven't rebooted since, so I can't confirm that it gets deleted upon reboot.

The /etc/udev/rules.d/85-ifupdown.rules file didn't exist on my system, so that method of "fixing" the problem didn't apply.

[Scott James Remnant (Canonical) (canonical-scott)]

On Wed, 2009-08-05 at 14:19 +0000, Bryce Thornton wrote:

> I ran into this yesterday.
>
> I had to manually create the /var/run/network directory and then
> manually create an "ifstate" file within it. I haven't rebooted since,
> so I can't confirm that it gets deleted upon reboot.
>
> The /etc/udev/rules.d/85-ifupdown.rules file didn't exist on my system,
> so that method of "fixing" the problem didn't apply.
>
Do you have a file of the same name in /lib/udev/rules.d ?

Scott
--
Scott James Remnant
<email address hidden>

[Bryce Thornton (brycethornton)]

Yes, there is a file named "85-ifupdown.rules" in /lib/udev/rules.d.

Thanks,
Bryce

On Thu, Aug 13, 2009 at 7:10 AM, Scott James Remnant<email address hidden> wrote:
> On Wed, 2009-08-05 at 14:19 +0000, Bryce Thornton wrote:
>
>> I ran into this yesterday.
>>
>> I had to manually create the /var/run/network directory and then
>> manually create an "ifstate" file within it.  I haven't rebooted since,
>> so I can't confirm that it gets deleted upon reboot.
>>
>> The /etc/udev/rules.d/85-ifupdown.rules file didn't exist on my system,
>> so that method of "fixing" the problem didn't apply.
>>
> Do you have a file of the same name in /lib/udev/rules.d ?
>
> Scott
> --
> Scott James Remnant
> <email address hidden>
>
> --
> ifdown: failed to open statefile /var/run/network/ifstate:
> https://bugs.launchpad.net/bugs/377432
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “ifupdown” package in Ubuntu: New
>
> Bug description:
> Binary package hint: ifupdown
>
> Booting Jaunty, configuring networking interfaces fails, as does
>
> ~$ sudo /etc/init.d/networking restart
>  * Reconfiguring network interfaces...
> ifdown: failed to open statefile /var/run/network/ifstate: No such file or directory
> ifup: failed to open statefile /var/run/network/ifstate: No such file or directory
>
> If I mkdir  /var/run/network/, then I get my network - for this boot, and have the same problem again the next time I boot.
>

[Scott James Remnant (Canonical) (canonical-scott)]

On Thu, 2009-08-13 at 12:43 +0000, Bryce Thornton wrote:

> Yes, there is a file named "85-ifupdown.rules" in /lib/udev/rules.d.
>
Could you attach it to this bug?

Scott
--
Scott James Remnant
<email address hidden>

[Bryce Thornton (brycethornton)]

I'm attaching the "85-ifupdown.rules" that is in /lib/udev/rules.d.

[GriFF3n (griff3ng)]

Having the same problem as original poster, though i do not have a "/etc/udev/rules.d/85-ifupdown.rules". /etc/udev/rules.d contatins "70-persistent-cd.rules and 70-persistent-net.rules". When i make the directories, restarting my network gives a:

ifdown: failed to open statefile /var/run/network/ifstate: Is a directory
ifup: failed to open statefile /var/run/network/ifstate: Is a directory

Can't do anything with the server. Did anyone find a way to fix this yet?

[Etienne Goyer (etienne-goyer-outlands)]

Same as GriFF3n above. I do not have a 85-ifupdown.rules in either /etc/udev/rules.d/ or /lib/udev/rules.d/.

[Jani Monoses (jani)]

If on a virtualized server (such as hosted on linode) udev may not behave as on real hardware or maybe not run at all.

A workaround described here
http://www.fs3.ph/article/ubuntu-904-in-an-openvz-ve

[Bryce Thornton (brycethornton)]

Thanks for posting the link to the workaround. Just tested it and it worked perfectly.

[GriFF3n (griff3ng)]

Tried the approach posted by Jani and still doesn't work. The only way I can get connection is by creating the directory myself and then doing ifup eth0. Nothing else works!!!

[Wit (witaly-s)]

http://www.fs3.ph/article/ubuntu-904-in-an-openvz-ve

doesn't really help. For some reason I still need to do

/etc/init.d/networking restart

manually afterwards.

[michael brenden (mike-brenden)]

We had the same problem here today in Washington, DC with a 6.06 server running root on a 3ware RAID5. Problem did not appear until today's snowstorm and PEPCO power outage. A month or so ago we ran the usual apt-get update / apt-get upgrade to keep 6.06 current.

After noticing boot details showed missing /var/run/network/ifstate file, we manually did "mkdir /var/run/network" and then rebooted; everything seemed to work okay.

We have the /etc/udev/rules.d/85-ifupdown.rules file.

Not content to leave well enough alone, we added the workaround suggested here http://www.fs3.ph/article/ubuntu-904-in-an-openvz-ve -- i.e., adding to /etc/init.d/networking, immediately after "start)" line: [ -d /var/run/network ] || mkdir /var/run/network

Again, no problem after we manually created the absent dir + file and rebooted. We modified the "networking" file anyway. Will advise any problem on next forced reboot....next snowstorm, PEPCO outage, or hardware failure. Love, love, love linux!

[Steve Langasek (vorlon)]

I believe this is the same as bug #446031, fixed in ifupdown 0.6.8ubuntu23. Changelog enty:

ifupdown (0.6.8ubuntu23) lucid; urgency=low

  * debian/ifupdown.network-interface.upstart:
  * debian/ifupdown.networking.upstart:
    - Revert Kees's change; this flat out doesn't work.
  * debian/ifupdown.network-interface-security.upstart:
    - Instead use "starting" so that the network-interface-security job
      is started before the first network-interface, and blocks it from
      finishing.

  (The above fixes the second ifup never completing due to waiting for
   network-interface-security to be restarted - which will never happen.)

  * debian/ifupdown.networking.upstart:
    - Make /var/run/network as we do in the network-interface job; this
      might end up running first. LP: #446031.

[openvz-rescue (openvz-rescue)]

In a Ubuntu 10.04 container, I see that the file /var/run/network/ifstate is deleted automatically on stop/start the container.

[michael brenden (mike-brenden)]

Follow-up on identical problem, almost one year later...on another server that was upgraded to 6.06 LTS. This issue may have been fixed, I don't know -- still slogging through it on various older servers.

FYI: PEPCO power and Comcast Internet here in the Washington DC metro area (both monopolies) are extremely unreliable. We just came back up after being down for over two days, between the dangerous service provided by these two clowns.

In case the original page (noted above) goes away (like its "comments" recently have), here's the basic text from it:

Ubuntu 9.04 in an OpenVZ VE

Networking ceases to function after upgrading Ubuntu 8.10 to 9.04 within an OpenVZ VE. The symptoms are that none of the network interfaces are created, and running ifup complains with ifup: failed to open statefile /var/run/network/ifstate: No such file or directory. Manually creating the directory /var/run/network fixes this problem temporarily, allowing ifup to work.

The root cause of this is a change in the ifupdown package. In previous versions, /etc/init.d/loopback created the /var/run/network directory. In the new version, this action has been reassigned to /lib/udev/rules.d/85-ifupdown.rules. Because udev is disabled within OpenVZ VEs, /lib/udev/rules.d/85-ifupdown.rules was never run, and the /var/run/network directory never created.

We’ve fixed this by modifying /etc/init.d/networking and adding this line (to create the dir if it doesn't exist)

[ -d /var/run/network ] || mkdir /var/run/network

immediately after the "start)" line.

— Federico Sevilla III, 29 April 2009, 17:40

[michael brenden (mike-brenden)]

uh, that's 6.06.2 LTS that we upgraded to and hit the problem of non-existent /var/run/network

[michael brenden (mike-brenden)]

this page may be related
http://utcc.utoronto.ca/~cks/space/blog/linux/UbuntuVarRun

Another obnoxious discovery about Ubuntu's /var/run stuff

Today, I had the distinct pleasure of discovering that /var/run must exist on the root filesystem, even if you have a separate /var filesystem. If your root filesystem does not have such a hidden /var/run, you experience mysterious failures of various boot stuff, including an inability to bring up the network; for bonus points, nothing gives you any meaningful error messages.

(For bonus points, the default Ubuntu server startup sequence wipes out the console scroll buffer, so you can't scroll back to see many boot time messages anyways. And nothing captures them elsewhere.)

I find this incredibly obnoxious, because it means that if you move your root filesystem around, you must move it with something that peeks under mount points (effectively only dump or an equivalent will do) and you must not, on any account, move it to a place with a replacement /var already mounted in place. (Guess what we did, not knowing any better.)

If you started out without a separate /var filesystem and now want to move to one, apparently your life just sucks.

There are some comments in /etc/init.d/mountvirtfs that suggest that it should be recreating the root filesystem's /var/run if it doesn't exist. However, there are two problems:

there is no actual code in mountvirtfs to do this, just comments saying that it should be done.
trying to do it wouldn't help anyways, because the root filesystem is mounted read-only at this point.
(While /var/lock also exists on the root filesystem and is necessary, don't worry about it; LVM will helpfully create it for you in early startup as a side effect of making its /var/lock/lvm directory. So you only have to reboot twice to have everything working right with that.)

[michael brenden (mike-brenden)]

2011-07-03 - Another prolonged PEPCO outage (25 miles outside of DC) brought down another Ubuntu 6.06 LTS 2 server today. Did I mention PEPCO is shit, and if DC power is any indication we are in severe jeopardy as a country...Anyway...

This missing /var/run/network/ifstate issue remains an issue, even with these lines added (after "start)" line) in following two files:

lines:
[ -d /var/run/network ] || mkdir /var/run/network
[ -f /var/run/network/ifstate ] || touch /var/run/network/ifstate

files:
/etc/init.d/networking
/etc/init.d/loopback

I'll surely follow up here as soon as I find the right fix.
Temporary workaround is to, after machine boots without networking, manually create /var/run/networking/ifstate and then run ifup -a

[norbie (nseibert)]

I have seen in many previous posts that the BUG was fixed and the issue was closed. In the contrary this one here seems to be relatively fresh/alive and does not suggest that BUG was killed. Although, relatively recent, I have encountered the same problem that exists now for more than 5 years.
After reboot the /var/run/network directory disappears and has to be recreated in order to get networking up and running. I read about a directory /var/run under root and seems to cause all kinds of problems if incorrect or missing.
In the same token, I believe that it might be very possible that it is related to a particular piece of hardware that is either not captured by the driver or the OS, but may work flawless with other hardware.
Just a thought, and sounds far fetched, because why did it work before the distro upgrade?

Cheer,
Norbert