I have openSUSE 11.4. After one of the recent updates the network service does not start automatically anymore and I have to start it manually (network service start) after I log in. I tried removing the symlinks in /etc/init.d/rc5.d and then enabling the service again in Yast, but this doesn’t help. The network connection is controled by the NetworkManager. It’s hard for me to troubleshoot the problem, since I can’t find any relevant information in the log files. It seems that there is no log file that would contain information about starting services (shouldn’t they be in /var/log/boot.log? such file does not exist on my system). Any help?
Network is either started on boot when you configured “traditional with ifup”, or it is started on login of (the first) user by network manager.
When you tell in your story that it is managed by network Manager, it is logical that the network does not start on boot. Thus please decide what you are wanting to use and configure accordingly in YaST. BTW I hope you haven’t borked something by fumbling around with those symlinks.
Thanks hcvv. Despite my low number of posts, I’ve been using linux for years so I know what I’m doing with symlinks in init.d 
Umm… what? This may sound stupid, but it never worked that way. I mean so far the NM acquired the network address during boot and it still works that way on my second computer with suse 11.3 (I have system-wide connection configured to automatically acquire DHCP address). That aside, the NM does not acquire the network address even after I log in. Note also that after logging in, when I type “service network start” the Network Manager starts - if it was already running it should produce message “NetworkManager already running”. This clearly indicates that it does not start during boot and I am unable to figure out why.
Hm, I appologise for having not enough knowledge here.
I see that /etc/init.d/network is also able to start NetworkManager. I only use the “traditional with ifup” method (wouldn’t know why to use NM).
A suggestion, you could compare the /etc/sysconfig/network/ifcfg-eth0 files of those two systems.
Also you could post the contents of the “not working” one here so others can see how it is configured.
I have personally found that contrary to what has often been posted to these forums that Network Manager does not start when a User logons, but when the Desktop starts (at least on the KDE desktops I’ve been running).
Partly for that reason, I’ve therefor also discovered that if multiple Users logon to the machine, Network Manager will associate network management with only one User and one User only… So for example if you logout of your normal User account and logon with Root, you’ll be prompted to use the regular User Account’s network settings and should already be running.
Note this also means that Network Manager is not starting during bootup (It never has, never likely will), but might still be consistent with the OP’s observation what he thought was happening before.
HTH,
Tony
Wel, network manager is a client/server application (IIRC) and I guess (!) that the server starts at boot (and runs with user root and can thus meddle around with he network). The client starts when the user logs in (in the GUI, every destop having his own client more ort less, I am not aware of a CLI client). The user thus being able by going through the server to influence the network (the normal user can’t of course do anything himself).
But this is a lot of guessing as I never used network manager myself, but that is what my impression is reading NetworkManager - Wikipedia, the free encyclopedia
I am not following you when you say " if you logout of your normal User account and logon with Root". You mean a user (the only one loged in at that moment) logs out of his GUI and then root logs in in the CLI (e.g. on logical console 1), that root will then get some message?
Hello Henk,
Assuming your comment was directed to my post,
I was describing after having logged into a non-root Desktop environment, logging off and then logging into the Desktop environment again but with the Root account instead.
The scenario you suggest is interesting though… If you logon as a different user (eg root) to a CLI environment, with the Desktop not running should that mean that networking isn’t configured or continues with the previous Desktop network configuration?
This also poses another interesting question…
If auto-logon is disabled is networking already possible if no User logs on to a Desktop environment but instead logs on to a CLI environment?
Maybe when I get some spare time I’ll run these quick and simple tests…
Tony
You realy mean to log in as root in the Desktop?
That is not something I would advice to anybody and I certainly would not do that myself.
For the rest, there are of course many combinations of loging in and out in all different sorts of combintions of users in many different GUI and CLI sessions, remote and local. And it is not only difficult to predict which of those logins has the saying with his network manager client. The same is true on who is the owner of a dynamicaly attached storage device (USB stick, CD). A complete different subject from the one here, but definitely related because IMHO the designers here try to mimic what happens on MS OSs on Linux and that is a bit difficult because the one is a sole user system, while the other is a multi user system.
We had a few years ago allready the story of the father that loged in, locked the screen and walked away, the mother that loged in in next logical console and walked away, the daughter that did not misuse the open mother’s session, but started yet another one and entered an USB sticky. Now guess what happened.
My idea is that it is not much different with network manager.
Of course auto-login is just a login and the results are not different from a normal login at the same time.
Well, certainly I <would> recommend logging in as root as part of a troubleshooting process. It’s a unique User Account profile which can be used to great advantage understanding and possibly fixing issues.
Would I recommend doing more than troubleshooting if logged in as root? Absolutely and of course not, any process that insinuates itself into the system and runs under the permissions of the actively logged on User would assume the same permissions and cause havoc.
But, troubleshooting is a very specialized case where your activities should be focused only on what needs to be fixed, then that session can be terminated.
IMO,
Tony
Hi guys. Sorry for not responding, I was quite busy at work. Anyway, I did some experiments:
-
I disabled NM and enabled network control via ifup. The network starts at boot, so it looks like the problem is really caused by NM. ifup is very inconvenient on a laptop so I need to get NM running.
-
can’t login to GUI as root - most GUI’s block that and so does KDE
-
after the system boots up, I go to the first console and log in as root (without loggin to Desktop, I do not use auto login). Then:
[root@xerxes : /dane/download] service network status
Checking for the NetworkManager: unused
[root@xerxes : /dane/download] service network start
Starting the NetworkManager done
Connecting........ 14s done
[root@xerxes : /dane/download] service network start
NetworkManager already running done
So it is clear that the NM does not start during the boot process and in my opinion it is highly unlikely that the problem is in any way related to DE.
- I did some comparing of the configuration present on both computers and I just can’t find the difference. I mean there are some, since one computer has suse 11.4, while the second has 11.3 (this one works). I’m using KDE 3.5, which doesn’t operate to well with NM and nm-applet because of the Polkit. I have to apply some changes to file in /etc/dbus-1/system.d in order to access connection settings.
When I get home I’ll check if the network is accessible without logging to Desktop. I’m 99% certain that it is - as I said I have system-wide connections defined in the /etc/NetworkManager/system-connections/DHCP:
[connection]
id=DHCP
uuid=7f41477d-cbfc-4494-8bb0-b1396f410970
type=802-3-ethernet
autoconnect=true
timestamp=0
[ipv4]
method=auto
ignore-auto-routes=false
ignore-auto-dns=false
dhcp-send-hostname=false
never-default=false
[802-3-ethernet]
speed=0
duplex=full
auto-negotiate=true
mac-address=0:1e:37:d9:9d:77
mtu=0
[ipv6]
method=ignore
ignore-auto-routes=false
ignore-auto-dns=false
never-default=false
NM reads them during boot and initializes the DHCP client on eth0 (autoconnect=true).
The big question is: why there is no file that would contain starting of the services during boot? In other distros it should be in boot.log. Is Suse affected by the same problem as Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=151238 ?
One more experiment: i removed /var/log/NetworkManager and rebooted the system. The file is recreated but it is empty. When I start the network service the file is filled with log messages. This, combined with earlier observations, leads me to conclusion that there is no attempt to start NM during booting. The question is why?
A small update on my previous proposed experiment and responding to the OP…
Just now, I booted into a console (as root) and ran ifconfig to verify whether any of my network adapters which are configured as DHCP clients were successfully auto-configured, and as expected did not… So that is further proof that until and unless the Desktop ir running, network devices are detected and configured with default values but not yet properly functioning.
As long as I was logged into the console without having started any Desktop, just for kicks I did a “su [regularuser]” to see what might be possible. As “regularuser” I was able to do a “startx” which started up the Desktop, but interestingly did not start knetworkmanager, in fact trying to startup knetworkmanager manually returned a startup error warning that knetworkmanager would no longer startup automatically.
So,
Returning to the OP, IMO this should be the summary…
- IFUP/IFDOWN will start your networking services on bootup. If you instead choose to use a network manager that is part of a Desktop, network connections will not be possible until a User with networking permissions has logged on.
- At least with KDE, networking can still not be invoked reliably if you first logon with one account, then without logging off simply modify your existing session. You <must> terminate the session by logging off or maybe open up a new session to initiate a <full Desktop initialization> to initiate the network manager.
HTH,
Tony
I did the same on my second machine (one that works) and the interfaces were configured correctly. This is expected behaviour if you have system wide connections (see my last post on the previous page). If you have only user connections, then the result you got is correct. On the working machine I can also see a message about starting the NM service:
Starting the NetworkManager done
Connecting............
As I said this message is missing on the other computer which is yet another proof that there is no attempt to even start NM during the boot process. It’s not the case of defined connections, login into the Desktop or anything like that - NM does simply not start and there is no attempt to start it!
Now I’ve done a very nasty workaround. I created a file network_workaround in the /etc/init.d:
#!/bin/bash
/sbin/service network start
And enabled it as a service:
chkconfig -a /etc/init.d/network_workaround
And now the network starts during boot. This shows that for some unknown reason there is no attempt to start the network service in the boot process, despite the fact that the service is enabled (confirmed via YaST, chkconfig and existence of symlinks in /etc/init.d/rc5.d). What might prevent a system from starting that service? Some sort of service dependencies maybe?
Are You using knetworkmanager or something else to control NetworkManager ?
Please try changing dhcpd to dhclient.
IFUP Woes and grief (set up looks fine and works, but won’t auto-connect)
I’ve got no idea what is your problem but I’ve seen this helped some people here, even when using NM
Best regards,
Greg
Please read my posts and you will see that this is totally irrelevant to my problem.
Why do you think this would affect running the service during boot?
I’ve got no idea what is your problem
Then please read my posts - I have clearly stated what my problem is a couple of times already.
Ok I’ve read them all now and I think You should try this suggestion because I think I have seen a very similar case on these forums. I know it sounds irrational and I agree that these things should not be connected at all but it sure won’t hurt to try and it’s easy to switch it back in case it’s not it
Best regards,
Greg
Well… why not. Tomorrow I’ll have access to that computer so I’ll give it a try.
I tried changing dhcpd to dhclient and it does not work.
Thanks for the feedback. I’m afraid I’m out of ideas as to what might the problem be.
Best regards,
Greg
I’ll make a try…
First, I now notice that indeed in knetworkmanager there is a checkbox or “system” which suggests network configuration on bootup instead of on User logon, but it’s greyed out and unavailable at least for the wireless connections my laptop uses.
From what you’ve tried, I agree it sounds like you don’t have a problem with the network service installed but do have a problem initiating the service on bootup. I also think that this is totally unrelated to network manager because AFAIK it only manages network configuration, not service initialization.
So, I suppose it’s reasonable to look at all the usual suspects first, but primarily how the service is configured. It’s been a very long time since I’ve looked at config files which might not even be relevant today. Most likely the only tool that makes sense is the YAST services tool, advanced.
If the YAST tool doesn’t reveal your problem, a shot in the dark might be to first try updating all network components, and if that doesn’t work to uninstall all network components, then re-install them.
Last thought, although it should only be seen when configuring IFUP/IFDOWN and not when using network manager, verify in YAST (and maybe even inspect your network interface file directly) that only the correct number of interfaces is listed. While mucking around, it might be possible that extra interfaces get listed and need to be purged manually… If not purged, then wrong virtual interfaces can be configured or used that aren’t really working.
BTW - If this is a brand new installation or still a relatively simple deployment, you might consider your networking issue likely an anomaly and troubleshooting far more time consuming than simply doing a new install (If side by side, then copy your content to your new, working instance).
HTH,
Tony