I have two machines where upon reboot, sometimes eth0 will go down once the logon prompt appears. Based on constant pings, it does come up during the boot process but then something happens around when the logon screen appears to makes it stop responding. And this doesn't happen at every boot, but enough to where it's caused issues/pain.

I've never been able to figure out why, but I'm wondering if there's some sort of workaround I can do by maybe scheduling a cron job to start/restart eth0 like a minute or two after reboot, that way regardless it will be up after that.

I know, very cheesy and not ideal, but it would get me through till those machines are retired.

You can typically run a cronjob at reboot. @reboot in a crontab is something that I have used quite a bit to run something after we have rebooted a server.

1 members found this post helpful.

Sounds like exactly what I need. thanks!

I think it depends on the distribution.

Gnome makes an assumption that the network shouldn't be available until a user logs in. This can usually be corrected by marking the inteface "not configurable by users".

These machines are RHEL, not sure how they handle it.

RH is basically the same as Fedora.

Their default is gnome - so if you are using gnome then you likely have the problem that Gnome is turning the network OFF under the assumption that only the logged in user will turn it on.

The final symptom is that if the user logs out, the network is again disabled...

1 members found this post helpful.

Maybe that's it. My server boots to a CLI logon prompt though, but maybe gnome is running/installed?

Although the network never turns itself off after I manually restart it if it dies when the logon prompt appears. Unless maybe that's because some system account "logs in" but never logs out due to running processes?

Gnome shouldn't be running...

but it is possible that the elements required by Gnome are. Things like the credential managment crap, logind, and some others that got grafted into the system. These are useful in some areas, but just cause more problems most of the time for servers.

Just more complex than it needs to be.

Whether that gets the root login identified as never logging out I'm not sure. But marking the interface "not under user control" should stop it from shutting the network down.

BTW, the cron restart might fix it... and it might not. Cron is usually started at the same time as the interactive logins. If it happens to run first, I would expect it to fail as the network would still be up. And then be shutdown by whatever is doing it now.

1 members found this post helpful.

So how do I do that "not under user control" thing from the command line?

On my system I have the /etc/sysconfig/network-scripts/ifcfg-eth0 (or whatever you name it marked as "NM_CONTROLED=no", and "ONBOOT=yes".

What I'm not sure of is how much NetworkManager does with this. I gave up on it, and use the legacy network startup. But that is just because I don't remember. I think the network is started anyway, but once started, it is ignored by NetworkManager - thus it isn't under user control.

in my ifcfg-eth0 is have ONBOOT=yes but I don't even have a NM_CONTROLLED listed in it, not sure what that means.

All of the current RH releases have been using NetworkManager to handle the startup/shutdown of networks, and to provide a service daemon that users can interact with to start/stop those they are permitted to control.

Without that entry (being specifically set to "no"), I think NetworkManager assumes control.

My servers kinda old, is there a way to tell if mine uses that setting? I tried man ifcfg but it said a man page didn't exist.

NM_CONTROLLED appears since RHEL 6.X, it doesn't appears in earlier versions of RHEL.
You check the ifcfg-eth0 configuration, is ok? Do you review the dmesg/messages/boot files in /var/log/?
Maybe a work around, it would be put a crontab with a script that will check the networks and when something is wrong (link down), it can restart the network service. Anyway the case is really strange, because the network service starts after the file system check.

I'm only running 5.4. Nothing I noticed in /var/log that gave a hint as to why it's doing it sometimes.