|
Bugzilla – Full Text Bug Listing |
| Summary: | No networking with systemd | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 12.1 | Reporter: | James Knott <james.knott> |
| Component: | Network | Assignee: | Marius Tomaschewski <mt> |
| Status: | RESOLVED DUPLICATE | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Major | ||
| Priority: | P5 - None | CC: | olivier |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
James Knott
2011-12-10 03:12:15 UTC
On failure, dmesg shows: "14.389944] ifup[726]: Service network not started and mode 'auto' -> skipping" Marius, Do you have any idea about this? Thanks! Yes, see bnc#725503#c10 and bnc#724777#c4 and bnc#735943. Could you look with "ps axfwww" what the ifup trying to bring up the interface is doing? I guess it looks like this: 1369 ? S 0:00 /sbin/dhcpcd --netconfig -L -E -c /etc/sysconfig/network/scripts/dhcpcd-hook -t 0 -h xanthos eth0 2579 ? S 0:00 \_ /bin/bash /etc/sysconfig/network/scripts/dhcpcd-hook /var/lib/dhcpcd/dhcpcd-eth0.info complete 2584 ? S 0:00 \_ /bin/bash /sbin/ifup eth0 -o dhcp 2658 ? S 0:00 \_ /bin/bash if-up.d/21-dhcpcd-hook-samba eth0 eth0 -o dhcp 2661 ? S 0:00 \_ /bin/systemctl force-reload nmb.service and similar with the dhcpv6 client. Neither of those are in the list, however, I do not use DHCP at all on this computer. I have a static configuration in IPv4 and automatic configuration (MAC & random number based addresses) in IPv6. However, I have saved the entire output of that command, should you wish to see it. I seem to have the same or similar problem. I have installed OpenSUSE 12.1 on 2 systems (fresh installs). After booting up I switched the network configuration from DHCP to static on eth0. I set a default gateway and a DNS server. Both are 64 bit installs. One system just has ethernet, while the other has ethernet and WiFi. Here is what I see happen: 1. (Re)start networking with "/etc/init.d/network (re)start" 2. Type "ip addr" and see that eth0 is down with no IP address 3. (Re)start networking with "/etc/init.d/network (re)start -o debug" 4. Type "ip addr" and see that eth0 is now OK with the static IP address Here is some info from /var/log/messages for the failing case: Dec 17 12:42:31 rilian network[15954]: Setting up network interfaces: Dec 17 12:42:32 rilian network[15954]: eth0 device: Realtek Semiconductor Co., Ltd. RTL-8110SC/81 Dec 17 12:42:32 rilian ifup: eth0 device: Realtek Semiconductor Co., Ltd. RTL-8110SC/81 Dec 17 12:42:32 rilian ifup: eth0 Dec 17 12:42:32 rilian ifup: IP address: 192.168.72.54/24 Dec 17 12:42:32 rilian network[15954]: eth0 IP address: 192.168.72.54/24 Dec 17 12:42:32 rilian ifup: Dec 17 12:42:32 rilian network[15954]: ..failed wlan0 device: Ralink corp. RT2860 Dec 17 12:42:32 rilian ifup: wlan0 device: Ralink corp. RT2860 Dec 17 12:42:32 rilian network[15954]: wlan0 Startmode is 'off' Dec 17 12:42:32 rilian ifup: wlan0 Startmode is 'off' Dec 17 12:42:32 rilian network[15954]: ..skippedSetting up service network . . . . . . . . . ...done Dec 17 12:42:33 rilian network[16301]: Shutting down network interfaces: Dec 17 12:42:33 rilian network[16301]: eth0 device: Realtek Semiconductor Co., Ltd. RTL-8110SC/81 Dec 17 12:42:33 rilian ifdown: eth0 device: Realtek Semiconductor Co., Ltd. RTL-8110SC/81 You can see that after eth0 is up, a new set of log messages (pid change from 15954 to 16301) are stating that the network is being brought down...?!? Those log messages are caused by typing "/etc/init.d/network start" If instead I type "/etc/init.d/network start -o debug", the interface stays up. Looking at the log in that case, I see a little clue: Dec 17 12:52:08 rilian ifup: eth0 device: Realtek Semiconductor Co., Ltd. RTL-8110SC/81 Dec 17 12:52:08 rilian kernel: [ 2980.547694] r8169 0000:04:0b.0: eth0: link down Dec 17 12:52:08 rilian kernel: [ 2980.547713] r8169 0000:04:0b.0: eth0: link down Dec 17 12:52:08 rilian kernel: [ 2980.548488] ADDRCONF(NETDEV_UP): eth0: link is not ready Dec 17 12:52:08 rilian ifup: eth0 Dec 17 12:52:08 rilian ifup: IP address: 192.168.72.54/24 Dec 17 12:52:08 rilian ifup: Dec 17 12:52:08 rilian avahi-daemon[805]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.72.54. Dec 17 12:52:08 rilian avahi-daemon[805]: New relevant interface eth0.IPv4 for mDNS. Dec 17 12:52:08 rilian avahi-daemon[805]: Registering new address record for 192.168.72.54 on eth0.IPv4. Dec 17 12:52:09 rilian ifup: wlan0 device: Ralink corp. RT2860 Dec 17 12:52:09 rilian ifup: wlan0 Startmode is 'off' Dec 17 12:52:09 rilian network: ... still waiting for hotplug devices: Dec 17 12:52:09 rilian network: SUCCESS_IFACES= eth0 wlan0 Dec 17 12:52:09 rilian network: MANDATORY_DEVICES= Dec 17 12:52:09 rilian network: ... final Dec 17 12:52:09 rilian network: SUCCESS_IFACES= eth0 wlan0 Dec 17 12:52:09 rilian network: MANDATORY_DEVICES= Dec 17 12:52:09 rilian network: FAILED=0 Dec 17 12:52:09 rilian network: TTWAIT=2 Dec 17 12:52:09 rilian network: ... still waiting for virtual devices: Dec 17 12:52:09 rilian network: SUCCESS_IFACES= eth0 wlan0 Dec 17 12:52:09 rilian network: VIRTUAL_IFACES= Dec 17 12:52:11 rilian kernel: [ 2983.555938] r8169 0000:04:0b.0: eth0: link up Dec 17 12:52:11 rilian kernel: [ 2983.556777] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready What I see here is that the link is marked as down at the start and isn't noted as up until 2 seconds after the interface is up (kinda). I hope this helps get this bug resolved, because not having static networking working out of the box is making me wonder about having picked OpenSUSE as the distribution for my server and clients at home... :-( If you need any more information and/or testing I'm glad to help. (PS: IMHO Importance of this bug should be much higher than None.) (In reply to comment #4) > Neither of those are in the list, however, I do not use DHCP at all on this > computer. I have a static configuration in IPv4 and automatic configuration > (MAC & random number based addresses) in IPv6. > > However, I have saved the entire output of that command, should you wish to > see it. Yes, please attach the tree. if-up.d scripts are executed also for static interfaces, not only for dhcp. (In reply to comment #5) > I hope this helps get this bug resolved, because not having static networking > working out of the box is making me wonder about having picked OpenSUSE as the > distribution for my server and clients at home... :-( Ahm... When you want something stable and proved, do not use the bleeding edge systemd, install "sysvinit-init" package to switch to sysvinit. One of the problems is, that systemd does not provide correct "status" from a LSB service -- it does not query the __current__ status of the service by calling "service status" but is using own/cached status. Please install all updates. Does the network work under sysvinit? Please provide the output of: /./etc/init.d/network stop -o boot /./etc/init.d/network start -o boot ip a s ; ip r s ; ip -6 r s And the /etc/sysconfig/network/{config,routes,ifcfg-*,ifroute-*} files. Note the "/./" -- it is to avoid the redirection to systemd and back. Here's the log that I collected earlier. I'll have to do that other stuff later, as I have converted the 2 problem systems back to system v.
PID TTY STAT TIME COMMAND
2 ? S 0:00 [kthreadd]
3 ? S 0:00 \_ [ksoftirqd/0]
4 ? S 0:00 \_ [kworker/0:0]
5 ? S 0:00 \_ [kworker/u:0]
6 ? S 0:00 \_ [migration/0]
7 ? SN 0:00 \_ [rcuc0]
8 ? S 0:00 \_ [rcun0]
9 ? S 0:00 \_ [rcub0]
10 ? S 0:00 \_ [rcun1]
11 ? S 0:00 \_ [rcub1]
12 ? S 0:00 \_ [watchdog/0]
13 ? S< 0:00 \_ [cpuset]
14 ? S< 0:00 \_ [khelper]
15 ? S 0:00 \_ [kdevtmpfs]
16 ? S< 0:00 \_ [netns]
17 ? S 0:00 \_ [sync_supers]
18 ? S 0:00 \_ [bdi-default]
19 ? S< 0:00 \_ [kintegrityd]
20 ? S< 0:00 \_ [kblockd]
21 ? S< 0:00 \_ [ata_sff]
22 ? S 0:00 \_ [khubd]
23 ? S< 0:00 \_ [md]
44 ? S 0:00 \_ [kworker/0:1]
45 ? S 0:00 \_ [khungtaskd]
46 ? S 0:00 \_ [kswapd0]
47 ? SN 0:00 \_ [ksmd]
48 ? SN 0:00 \_ [khugepaged]
49 ? S 0:00 \_ [fsnotify_mark]
50 ? S< 0:00 \_ [crypto]
54 ? S< 0:00 \_ [kthrotld]
61 ? S< 0:00 \_ [kpsmoused]
62 ? S 0:00 \_ [kworker/0:2]
94 ? S 0:00 \_ [scsi_eh_0]
95 ? S 0:00 \_ [scsi_eh_1]
96 ? S 0:00 \_ [kworker/u:1]
97 ? S 0:00 \_ [kworker/u:2]
98 ? S 0:00 \_ [kworker/u:3]
101 ? S 0:00 \_ [scsi_eh_2]
102 ? S 0:00 \_ [scsi_eh_3]
104 ? S 0:00 \_ [scsi_eh_4]
105 ? S 0:00 \_ [scsi_eh_5]
106 ? S 0:00 \_ [kworker/u:4]
329 ? S< 0:00 \_ [kdmflush]
334 ? S< 0:00 \_ [kdmflush]
339 ? S< 0:00 \_ [kdmflush]
344 ? S< 0:00 \_ [kdmflush]
349 ? S< 0:00 \_ [kdmflush]
391 ? S 0:00 \_ [jbd2/dm-1-8]
392 ? S< 0:00 \_ [ext4-dio-unwrit]
398 ? S 0:00 \_ [flush-253:1]
439 ? S 0:00 \_ [kauditd]
565 ? S 0:00 \_ [kworker/0:3]
699 ? S< 0:00 \_ [edac-poller]
723 ? S 0:00 \_ [kworker/0:4]
816 ? S 0:00 \_ [jbd2/sdb1-8]
817 ? S< 0:00 \_ [ext4-dio-unwrit]
829 ? S 0:00 \_ [jbd2/dm-3-8]
830 ? S< 0:00 \_ [ext4-dio-unwrit]
835 ? S< 0:00 \_ [ext4-dio-unwrit]
840 ? S 0:00 \_ [jbd2/sda2-8]
841 ? S< 0:00 \_ [ext4-dio-unwrit]
845 ? S 0:00 \_ [jbd2/dm-4-8]
846 ? S< 0:00 \_ [ext4-dio-unwrit]
852 ? S 0:00 \_ [jbd2/dm-0-8]
853 ? S< 0:00 \_ [ext4-dio-unwrit]
1432 ? S 0:00 \_ [flush-8:0]
1433 ? S 0:00 \_ [flush-8:16]
1434 ? S 0:00 \_ [flush-253:0]
1435 ? S 0:00 \_ [flush-253:3]
1436 ? S 0:00 \_ [flush-253:4]
1 ? Ss 0:00 /sbin/init
430 ? Ss 0:00 /sbin/udevd
663 ? S 0:00 \_ /sbin/udevd
664 ? S 0:00 \_ /sbin/udevd
440 ? Ss 0:00 /lib/systemd/systemd-stdout-syslog-bridge
880 ? Ss 0:00 /lib/systemd/systemd-logind
938 ? Sl 0:00 /sbin/rsyslogd -c 5 -f /etc/rsyslog.early.conf
964 ? Ss 0:00 avahi-daemon: running [linux.local]
999 ? Ss 0:00 /sbin/acpid
1003 ? Ss 0:00 /bin/dbus-daemon --system --address=systemd: --nofork --systemd-activation
1004 ? Ss 0:00 /sbin/haveged -w 1024 -v 1
1205 ? S 0:00 /usr/bin/kdm
1332 tty7 Ss+ 0:03 \_ /usr/bin/Xorg -br :0 vt7 -nolisten tcp -auth /var/lib/xdm/authdir/authfiles/A:0-81FBIb
2759 ? S 0:00 \_ -:0
3172 ? Ss 0:00 \_ /bin/sh /usr/bin/startkde
3244 ? Ss 0:00 \_ /usr/bin/gpg-agent --sh --daemon --write-env-file /home/jknott/.gnupg/agent.info /usr/bin/ssh-agent /etc/X11/xinit/xinitrc
3245 ? Ss 0:00 \_ /usr/bin/ssh-agent /etc/X11/xinit/xinitrc
3348 ? S 0:00 \_ kwrapper4 ksmserver
1761 tty1 Ss+ 0:00 /sbin/agetty tty1 38400
1768 ? Ss 0:00 /usr/sbin/nscd
1772 ? Ss 0:00 /usr/sbin/cron -n
1939 ? Ss 0:00 /usr/sbin/mcelog --daemon --pidfile /var/run/mcelog.pid
2013 ? S 0:00 /bin/sh /usr/bin/mysqld_safe --mysqld=mysqld --user=mysql --pid-file=/var/run/mysql/mysqld.pid --socket=/var/run/mysql/mysql.sock --datadir=/var/lib/mysql
2524 ? Sl 0:00 \_ /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --user=mysql --log-error=/var/log/mysql/mysqld.log --pid-file=/var/run/mysql/mysqld.pid --socket=/var/run/mysql/mysql.sock --port=3306
2072 ? Ss 0:00 /usr/sbin/cupsd -C /etc/cups/cupsd.conf
2115 ? Ss 0:00 /usr/sbin/sshd -o PidFile=/var/run/sshd.init.pid
2965 ? Ss 0:00 /usr/sbin/dovecot
2966 ? S 0:00 \_ dovecot/anvil
2967 ? S 0:00 \_ dovecot/log
2975 ? S 0:00 \_ dovecot/config
3030 ? Ss 0:00 /usr/lib/postfix/master
3049 ? S 0:00 \_ pickup -l -t fifo -u
3050 ? S 0:00 \_ qmgr -l -t fifo -u
3091 ? Ssl 0:00 /usr/sbin/console-kit-daemon --no-daemon
3158 ? Sl 0:00 /usr/lib/polkit-1/polkitd --no-debug
3288 ? S 0:00 dbus-launch --sh-syntax --exit-with-session
3289 ? Ss 0:00 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
3296 ? S 0:00 /usr/lib64/kde4/libexec/start_kdeinit +kcminit_startup
3297 ? Ss 0:00 kdeinit4: kdeinit4 Running...
3298 ? S 0:00 \_ kdeinit4: klauncher [kdeinit] --fd=9
3354 ? Sl 0:00 \_ kdeinit4: ksmserver [kdeinit]
3363 ? Sl 0:00 | \_ kwin -session 10e4696e75000132302721100000022450000_1323963291_678471
3407 ? S 0:00 \_ kdeinit4: kio_desktop [kdeinit] desktop local:/tmp/ksocket-jkn
3413 ? Sl 0:00 \_ kdeinit4: kio_trash [kdeinit] trash local:/tmp/ksocket-jknott/
3428 ? S 0:00 \_ kdeinit4: kio_file [kdeinit] file local:/tmp/ksocket-jknott/kl
3550 ? S 0:00 \_ kdeinit4: konqueror [kdeinit] -session 10e4696e750001323368023
3581 ? Sl 0:00 \_ kdeinit4: kio_trash [kdeinit] trash local:/tmp/ksocket-jknott/
3623 ? S 0:00 \_ /bin/sh /usr/bin/firefox
3628 ? Sl 0:02 \_ /usr/lib64/firefox/firefox-bin
3679 ? S 0:00 \_ /usr/lib/mozilla/kmozillahelper
3300 ? Sl 0:00 kdeinit4: kded4 [kdeinit]
3305 ? S 0:00 kdeinit4: kglobalaccel [kdeinit]
3307 ? S 0:00 /usr/sbin/modem-manager
3309 ? Sl 0:00 /usr/lib/upower/upowerd
3350 ? Sl 0:00 /usr/lib/udisks/udisks-daemon
3351 ? S 0:00 \_ udisks-daemon: not polling any devices
3395 ? S 0:00 /usr/bin/kactivitymanagerd
3398 ? Sl 0:00 /usr/bin/knotify4
3401 ? Sl 0:02 kdeinit4: plasma-desktop [kdeinit]
3404 ? S 0:00 /usr/bin/kuiserver
3410 ? Sl 0:00 /usr/bin/akonadi_control
3412 ? Sl 0:00 \_ akonadiserver
3415 ? Sl 0:00 | \_ /usr/sbin/mysqld --defaults-file=/home/jknott/.local/share/akonadi//mysql.conf --datadir=/home/jknott/.local/share/akonadi/db_data/ --socket=/home/jknott/.local/share/akonadi/socket-linux/mysql.socket
3446 ? Sl 0:00 \_ /usr/bin/akonadi_agent_launcher akonadi_akonotes_resource akonadi_akonotes_resource_0
3447 ? Sl 0:00 \_ /usr/bin/akonadi_agent_launcher akonadi_ical_resource akonadi_ical_resource_0
3448 ? Sl 0:00 \_ /usr/bin/akonadi_agent_launcher akonadi_ical_resource akonadi_ical_resource_1
3449 ? Sl 0:00 \_ /usr/bin/akonadi_agent_launcher akonadi_ical_resource akonadi_ical_resource_2
3450 ? Sl 0:00 \_ /usr/bin/akonadi_agent_launcher akonadi_maildir_resource akonadi_maildir_resource_0
3451 ? S 0:00 \_ /usr/bin/akonadi_maildispatcher_agent --identifier akonadi_maildispatcher_agent
3452 ? Sl 0:00 \_ /usr/bin/akonadi_nepomuk_calendar_feeder --identifier akonadi_nepomuk_calendar_feeder
3453 ? Sl 0:00 \_ /usr/bin/akonadi_nepomuk_contact_feeder --identifier akonadi_nepomuk_contact_feeder
3454 ? Sl 0:00 \_ /usr/bin/akonadi_nepomuk_email_feeder --identifier akonadi_nepomuk_email_feeder
3455 ? Sl 0:00 \_ /usr/bin/akonadi_agent_launcher akonadi_vcard_resource akonadi_vcard_resource_0
3491 ? Sl 0:00 /usr/bin/nepomukserver
3497 ? SNl 0:00 \_ /usr/bin/nepomukservicestub nepomukstorage
3526 ? SNl 0:03 | \_ /usr/bin/virtuoso-t +foreground +configfile /tmp/virtuoso_Ti3497.ini +wait
3657 ? SNl 0:00 \_ /usr/bin/nepomukservicestub nepomukfilewatch
3658 ? SN 0:00 \_ /usr/bin/nepomukservicestub digikamnepomukservice
3659 ? SN 0:00 \_ /usr/bin/nepomukservicestub nepomukqueryservice
3662 ? SN 0:00 \_ /usr/bin/nepomukservicestub nepomukbackupsync
3507 ? S 0:00 kdeinit4: kaccess [kdeinit]
3518 ? Sl 0:01 kdeinit4: krunner [kdeinit]
3540 ? S 0:00 /usr/bin/nepomukcontroller -session 10e4696e75000132302724800000022450011_1323963291_658323
3542 ? Sl 0:00 kdeinit4: kmix [kdeinit] -session 10e4696e75000132302724800000
3547 ? Sl 0:00 /usr/bin/kgpg -session 10e4696e75000132302724800000022450013_1323963291_658492
3549 ? S 0:00 /usr/bin/basket -session 10e4696e75000132303977500000032770031_1323963291_658570
3553 ? Sl 0:00 kdeinit4: konsole [kdeinit] -session 10e4696e75000132361430300
3599 pts/0 Ss 0:00 \_ /bin/bash
3703 pts/0 R+ 0:00 \_ ps axfwww
3559 ? Sl 0:00 /usr/bin/pulseaudio --start --log-target=syslog
3561 ? SNl 0:00 /usr/lib/rtkit/rtkit-daemon
3590 ? Sl 0:00 /usr/lib64/kde4/libexec/polkit-kde-authentication-agent-1
3591 ? S 0:00 kdeinit4: klipper [kdeinit]
3653 ? S 0:00 /usr/lib/GConf/2/gconfd-2
3685 ? S 0:00 /usr/lib/gvfs/gvfsd
3693 ? Ssl 0:00 /usr/lib/gvfs//gvfs-fuse-daemon /home/jknott/.gvfs
(In reply to comment #6) > (In reply to comment #5) > > I hope this helps get this bug resolved, because not having static networking > > working out of the box is making me wonder about having picked OpenSUSE as the > > distribution for my server and clients at home... :-( > > Ahm... When you want something stable and proved, do not use the bleeding > edge systemd, install "sysvinit-init" package to switch to sysvinit. OK, it's good to know I have a simple option. However, I just did a straightforward clean install of OpenSUSE 12.1 64 bit and systemd is what was installed and setup on my systems, which gives the impression that OpenSUSE considered it "stable and proved". Since a new user which does a normal install and then sets a static IP address may experience this bug, I'll try and respond to the following questions when I'm home this evening; it's a bit hard debugging network things over the network... ;-) BTW, bug number 737641 sounds like my problem also. > One of the problems is, that systemd does not provide correct "status" > from a LSB service -- it does not query the __current__ status of the > service by calling "service status" but is using own/cached status. > > Please install all updates. Does the network work under sysvinit? > > Please provide the output of: > /./etc/init.d/network stop -o boot > /./etc/init.d/network start -o boot > ip a s ; ip r s ; ip -6 r s > > And the /etc/sysconfig/network/{config,routes,ifcfg-*,ifroute-*} files. > > Note the "/./" -- it is to avoid the redirection to systemd and back. I were testing it in the last days. It are AFAIS all timing problems because of some hanging services or systemctl "deadlocks" because of dependencies or whatever. Further, the fact, that systemd is using own status instead of the status returned by "rcnetwork status". Try to set DEBUG=EXTRA in /etc/sysconfig/network/config -- this will produce a lot of "bash -x" traces in /dev/.sysconfig. Please attach a tar of this directory. Except of the nmb reload, it could be also the ntp that needs a lot of time, at least while restart. It also tries to communicate with IPv6 ntp servers while there is no global IPv6 address it could use (AdvManagedFlag yes, AdvAutonomous off on the router and no dhcpv6 client started [yet]). Workarounds are: - move the /etc/sysconfig/network/if-*.d/21* links away - remove ntp-runtime from NETCONFIG_MODULES_ORDER in /etc/sysconfig/network/config. This a duplicate of bug 727771 [and maybe bug 732930 & Co (samba deadlock) that causes the start delays via if-down.d/21-cifs]. Please install systemd update, it provides the support for the X-Systemd-RemainAfterExit LSB flag and sysconfig update package (not released yet) from: http://download.opensuse.org/repositories/home:/mtomaschewski:/branches:/openSUSE:/12.1:/Update:/Test that is using it. *** This bug has been marked as a duplicate of bug 727771 *** |