Bug 780644

Assign to Maintainer.

The ifcfg-Net1 config file contains an INTERFACETYPE variable and
ifup provides a warning. Did you added it to the ifcfg-Net1 file?

Please attach the ifcfg-Net1 file and the output of this command:

. /etc/sysconfig/network/scripts/functions ; set -x ; get_iface_type Net1

[Note, there is a "." at the begin].

Except of this, it has usually nothing to do with the failure.

Please execute the following command as soon as possible after
the failure:

   bash -x ifstatus Net1 &>/tmp/status-Net1.out

A little bit background about INTERFACETYPE: it should be never
required to set it (also on 11.4 not). _When_ it is required,
there is a bug in the detection of a interface we've to fix.

I did not modify the ifcfg-Net1 file.

The result of get_iface_type Net1 was 'eth'

status-Net1.out attached

Created attachment 506793 [details]
ifcfg

Created attachment 506794 [details]
ifstatus

(In reply to comment #5)
> Created an attachment (id=506793) [details]
> ifcfg

Please remove INTERFACETYPE='eth' line from the ifcfg file to get rid
of the warning. I guess this has been caused by an already fixed bug:

* Do Aug 11 2011 mvidner@suse.cz
- Omit unnecessary INTERFACETYPE declaration in ifcfg (bnc#711762)
  This broke the VM-proposed bridge because it copied ifcfg-ethN's
  INTERFACETYPE=eth (bnc#704999).
- 2.21.2

Further, please set WAIT_FOR_INTERFACES again to 30 - 8 sec is not
enough (dhcp waits 15 sec already by default).

Instead, please set BOOTPROTO='dhcp4' in the ifcfg file as there
seems to be no DHCPv6 server on your network.

On 11.4, the dhcpv6 client were not installed by default -- now it
is (and has been installed while update) and this causes a failure
because of the lowered timings you're using.

Does it work when you:

- remove INTERFACETYPE from ifcfg file
- set WAIT_FOR_INTERFACES=30 (default) in network/config file
- change BOOTPROTO to dhcp4 (optional, but no need to wait for v6)

?

1) removing INTERFACETYPE= cleared up the error message.

2) There is a dhcpv6 server, and the system is assigned a v6 address.

3) I set the WAIT_FOR_INTERFACES to 8 because the interface does not seem to complete the setup until AFTER the WAIT_FOR time has expired.  Here is the log with the WAIT_FOR_INTERFACES set to 120.  Other than the extra delay, it is not different than with it set to 8, and, in both cases, even though the network reports an error, ifconfig shows both addresses correctly assigned.

Sep 25 15:55:14 Buzzard ifup-dhcp[1183]:     Net1      Starting DHCP4+DHCP6 client
Sep 25 15:55:14 Buzzard dhcpcd[1914]: Net1: dhcpcd 3.2.3 starting
Sep 25 15:55:14 Buzzard dhcpcd[1914]: Net1: hardware address = 00:26:2d:20:f1:20
Sep 25 15:55:14 Buzzard kernel: [   11.586345] NET: Registered protocol family 17
Sep 25 15:55:14 Buzzard dhcpcd[1914]: Net1: broadcasting for a lease
Sep 25 15:55:14 Buzzard dhcpcd[1914]: Net1: offered 10.168.1.11 from 10.168.1.10
Sep 25 15:55:14 Buzzard dhcpcd[1914]: Net1: checking 10.168.1.11 is available on attached networks
Sep 25 15:55:14 Buzzard ifup-dhcp[1183]: .
Sep 25 15:55:15 Buzzard dhcpcd[1914]: Net1: leased 10.168.1.11 for 259200 seconds
Sep 25 15:55:15 Buzzard dhcpcd[1914]: Net1: adding IP address 10.168.1.11/21
Sep 25 15:55:15 Buzzard dhcpcd[1914]: Net1: adding default route via 10.168.7.1 metric 0
Sep 25 15:55:16 Buzzard ifdown[2118]:     Net1      device: Broadcom Corporation NetLink BCM57788 Gigabit Ethernet PCIe (rev 01)
Sep 25 15:55:16 Buzzard dhcpcd[1914]: Net1: setting hostname to `Buzzard'
Sep 25 15:55:16 Buzzard ifup[2223]:     Net1      device: Broadcom Corporation NetLink BCM57788 Gigabit Ethernet PCIe (rev 01)
Sep 25 15:55:17 Buzzard ifup[2457]:     Net1      device: Broadcom Corporation NetLink BCM57788 Gigabit Ethernet PCIe (rev 01)
Sep 25 15:55:17 Buzzard ifup-dhcp[1183]: .
Sep 25 15:55:20 Buzzard ifup-dhcp[1183]: .
Sep 25 15:55:22 Buzzard ifup-dhcp[1183]: .
Sep 25 15:55:25 Buzzard network[657]: Net1      Starting DHCP4+DHCP6 client. . . .
Sep 25 15:55:25 Buzzard network[657]: Net1      DHCP4 continues in background
Sep 25 15:55:25 Buzzard ifup-dhcp[1183]:
Sep 25 15:55:25 Buzzard ifup-dhcp[1183]:     Net1      DHCP4 continues in background
Sep 25 15:55:25 Buzzard ifup-dhcp[1183]:     Net1      DHCP6 continues in background
Sep 25 15:55:25 Buzzard network[657]: Net1      DHCP6 continues in background
Sep 25 15:55:25 Buzzard network[657]: [1Awaiting
Sep 25 15:55:25 Buzzard network[657]: Waiting for mandatory devices:  Net1
Sep 25 15:57:10 Buzzard network[657]: 104 103 101 100 99 98 96 95 94 93 91 90 89 88 86 85 84 83 81 80 79 78 76 75 74 73 72 70 69 68 67 65 64 63 62 60 59 58 57 55 54 53 52 50 49 48 47 45 44 43 42 40 39 38 37 35 34 33 32 30 29 28 27 25 24 23 22 20 19 18 17 16 14 13 12 11 9 8 7 6 4 3 2 1
Sep 25 15:57:11 Buzzard network[657]: Net1      device: Broadcom Corporation NetLink BCM57788 Gigabit
Sep 25 15:57:11 Buzzard network[657]: Net1      . . . is just beeing set up
Sep 25 15:57:11 Buzzard network[657]: Net1      IP address: 10.168.1.11/21
Sep 25 15:57:11 Buzzard network[657]: Net1      IP address: 2001:470:1f06:838:3:5:11:1/64
Sep 25 15:57:11 Buzzard network[657]: Net1      is up
Sep 25 15:57:11 Buzzard network[657]: [1Awaiting
Sep 25 15:57:11 Buzzard network[657]: Net1      interface could not be set up until now
Sep 25 15:57:11 Buzzard network[657]: ..failedSetting up service (localfs) network  .  .  .  .  .  .  .  .  .  ...failed
Sep 25 15:57:10 Buzzard systemd[1]: network.service: control process exited, code=exited status=7


Net1      Link encap:Ethernet  HWaddr 00:26:2D:20:F1:20
          inet addr:10.168.1.11  Bcast:10.168.7.255  Mask:255.255.248.0
          inet6 addr: 2001:470:1f06:838:3:5:11:1/64 Scope:Global
          inet6 addr: fe80::226:2dff:fe20:f120/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2507 errors:0 dropped:0 overruns:0 frame:0
          TX packets:363 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:494208 (482.6 Kb)  TX bytes:123264 (120.3 Kb)
          Interrupt:19

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::2/128 Scope:Compat
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:74 errors:0 dropped:0 overruns:0 frame:0
          TX packets:74 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:6106 (5.9 Kb)  TX bytes:6106 (5.9 Kb)

(In reply to comment #8)
> 1) removing INTERFACETYPE= cleared up the error message.
> 
> 2) There is a dhcpv6 server, and the system is assigned a v6 address.

Ah.. I see now.

> 3) I set the WAIT_FOR_INTERFACES to 8 because the interface does not seem to
> complete the setup until AFTER the WAIT_FOR time has expired.  Here is the log
> with the WAIT_FOR_INTERFACES set to 120.  Other than the extra delay, it is
> not different than with it set to 8, and, in both cases, even though the
> network reports an error, ifconfig shows both addresses correctly assigned.

[Yes, but as I wrote 8sec is not enough, except you lower also several another
 timing values. A setting of 120 is only required on broken hardware/driver
 (bnx2 in the past; needed 60 sec to find a link) or when there is a bridge
 with enabled STP and default settings. A WAIT_FOR_INTERFACES of 30 should
 work fine in most cases, even with 2 NICs.]

What you can try is to increase DHCLIENT_WAIT_AT_BOOT from 15 to 30 and set
WAIT_FOR_INTERFACES to 60 (DHCLIENT_WAIT_AT_BOOT * 2).

Further also DHCLIENT_DEBUG=yes, DHCLIENT6_DEBUG=yes -- all the DHCLIENT*
variables in /etc/sysconfig/network/dhcp.

Does it finish in time then?

When not, please attach the messages and also the /var/log/dhclient6-script.Net1.log file.

Ahm.. Could you edit the /sbin/ifup-dhcp script and add the -v option to
the args when debug is enabled in the start_dhcp*_dhclient function?

--- /sbin/ifup-dhcp	2012-08-13 20:00:56.000000000 +0200
+++ /sbin/ifup-dhcp	2012-09-26 14:08:52.347301633 +0200
@@ -362,7 +362,7 @@ start_dhcp4_dhclient() {
 
 	# don't write copyright info
 	local args="-q" 
-	test "$DHCLIENT_DEBUG" = "yes" && args=""
+	test "$DHCLIENT_DEBUG" = "yes" && args="-v"
 
 	# send hostname for DDNS?
 	case "$DHCLIENT_HOSTNAME_OPTION" in
@@ -423,7 +423,7 @@ start_dhcp6_dhclient() {
 
 	# don't write copyright info
 	local args="-q" 
-	test "$DHCLIENT6_DEBUG" = "yes" && args=""
+	test "$DHCLIENT6_DEBUG" = "yes" && args="-v"
 
 	# send hostname for DDNS?
 	case "$DHCLIENT6_HOSTNAME_OPTION" in

I made the requested changes, except there was no DHCLIENT6_DEBUG in the /etc/sysconfig/network/dhcp file, so I added one.

The only apparent change was that the boot process took longer.

Log files attached.

Created attachment 507184 [details]
dhclient6 log

Created attachment 507185 [details]
system log

Going to review what happens here.

See also bug 781646 -- it may be related.

Sep 26 09:16:21 Buzzard ifup[959]: IP address: ::1/
Sep 26 09:16:21 Buzzard network[639]: IP address: ::1/
Sep 26 09:16:21 Buzzard ifup[959]: IP address: ::2/128
Sep 26 09:16:21 Buzzard network[639]: IP address: ::2/128

Can you attach your ifcfg-lo file?

Or better, can you install "supportutils", call "supportconfig" and
attach the resulting file please?

Hmm... link + dhcp4 + dhcp6 are ready after ~ 6 sec, but then something
goes really wrong.
Looks like ifup-dhcp would not receive a "complete" from dhcp client's.

Please set DEBUG=EXTRA in /etc/sysconfig/network/config, reboot and then
grab the results "tar cvzpf /tmp/network-exdbg.tgz /dev/.sysconfig/network"
and attach /tmp/network-exdbg.tgz. Additionally to supportconfig, please.

In my testes I've never seen more than 5 sec for the post scripts
(see bug 781646 comment 14).

Could you try if this package helps (not yet published):

http://download.opensuse.org/repositories/home:/mtomaschewski:/branches:/openSUSE:/12.2:/Update/

it looks like the timeout is causes by ntp runtime add-server using
the init script try-restart and trying to synchrinize (at least in
my case), so I've added the code doing it directly to netconfig's
ntp-runtime module (<1sec now).

Except of this, please provide the requested debug output.

Request information attached.

In case it is relevant: Running yast2 / Network Devices / Network Settings always shows the device as un-configured. If I make changes and save them, the ifcfg-Net1 file is not changed.  It has been this way since the upgrade from 11.1 -> 11.2

Created attachment 507241 [details]
DEBUG=EXTRA

Created attachment 507242 [details]
Configs

In reference to not being able to update ifcfg-?, I previously filed bug #695262.

(In reply to comment #23)
> In reference to not being able to update ifcfg-?, I previously filed bug
> #695262.

See bug 695262 comment 2 for a list of the steps needed to rename an interface.
I guess, yast2 does not make all them. Rename to "ifcfg-" was a bug and I hope
it is fixed now...

Please set DEBUG=EXTRA in /etc/sysconfig/network/config, then _reboot_,
then attach the debug-extra logs. The attachment you've attached does
not contain the debug logs.

Just as side note: The 127.0.0.2 stuff IMO breaks more than it solves.
Further, while in IPv4 the complete 127.0.0.0/8 network is reserved
for loopback, in IPv6 it is only one single address "::1". I don't
know / I didn't tested if your "::2" causes some problems or not,
but I'd not use it. I guess it is interpreted as "::0.0.0.2" ...

I Did set DEBUG, however, it was lowercase and, apparently, case counts.

I removed the 127.0.0.2 and :: entries

New tar attached.

I had previously done the steps suggested to rename the interface.  However, even after doing that, and having a Net1 that starts and shows in ifconfig, I can not use yast2 to configure it in 12.2.

Created attachment 507416 [details]
DEBUG=EXTRA

In debug provided in bug 781646 it seems to be the samba-client hook
again (bnc#732395) that is blocking the ifup -o dhcp processing.

You may try DHCLIENT_MODIFY_SMB_CONF=no in /etc/sysconfig/network/dhcp,
or move away the /etc/sysconfig/network/if-{up,down}.d/ hooks:

   21-dhcpcd-hook-samba, 55-samba-winbindd [, 21-smbfs]

or uninstall samba-client & co. Going to review your debug logs...

Yes, in your case it seems also to be the force-reload nmb.service
and winbind.service.

Does it help when you set DHCLIENT_MODIFY_SMB_CONF=no? When not,
does it help when you move away the samba hooks?

DHCLIENT_MODIFY_SMB_CONF=no

seems to resolve the issue - i.e. the boot process finishes in a reasonable time and the network setup finishes without the error message.

OK, thanks!

Frederic, same as in 781646. samba-client blocks again. Any idea how
we can solve this?

I'll keep this assigned to me to not forget the ntp & other fixes I've
made to sysconfig (#c19).

Ok, I've duplicated the issue in a VM, I'll look into it..

*** Bug 781646 has been marked as a duplicate of this bug. ***

I had to add a "/standard/" to the end of the repository URL in #19.  I applied the updates, and I still needed the smb change.

(In reply to comment #35)
> I had to add a "/standard/" to the end of the repository URL in #19.  I applied
> the updates, and I still needed the smb change.

Yes. Frederic is looking at the smb issue (comment 33).

The sysconfig RPMs contains only the following changes:

- netconfig/ntp-runtime: add servers, do not try-restart
  I've noticed that similar problem may occur when ntp is enabled by the
  try-restart (which pickups the server dhcp provided) we've made before
  [it seems to try to sync in foreground now], that causes a delay at least.
  Further, because there may be two "try-restart" (systemctl ...) calls
  [from dhcp4 and dhcp6], same problem as in nmb case may happen.
  I've changed to use the "add runtime server" code directly, instead to
  go via the init script, so it can't happen any more and the post-up
  is simply faster now.
- modprobe af_packet early, before link set up, added DHCLIENT_WAIT_LINK
  variable instead the hardcoded 3 secs (my intel nic needs 4).
  This fixes dhcp4 and dhcp6 to need only 1 or 2 second together, because
  everything is ready to use when they start and they usually don't need
  to repeat/resend anything (and "sleep" between each try).
- Use dhclient -v when debug is enabled (bnc#780644)
  Enabled verbose mode when debug is enabled in ifcfg file, so we see
  what the dhclient is currently doing. It was too quiet by default.

(In reply to comment #36)
nly the following changes:
> 
> - netconfig/ntp-runtime: add servers, do not try-restart
>   I've noticed that similar problem may occur when ntp is enabled by the
>   try-restart (which pickups the server dhcp provided) we've made before
>   [it seems to try to sync in foreground now], that causes a delay at least.
>   Further, because there may be two "try-restart" (systemctl ...) calls
>   [from dhcp4 and dhcp6], same problem as in nmb case may happen.
>   I've changed to use the "add runtime server" code directly, instead to
>   go via the init script, so it can't happen any more and the post-up
>   is simply faster now.

try-restart (without --ignore-dependencies) shouldn't be a problem with systemd in 12.2 or later, because it has a "merge" activation function which will cause try-restart to be a no-op if "start" is already pending. Unfortunately, it looks like this "merge" function isn't working for "force-reload". In the "smb" activation bug, if you replace "--ignore-dependencies force-reload" with "try-restart", there is no deadlock. I need to discuss with upstream if we can have the same kind of behaviour with "force-reload".

hmm, strangely, I get the exact same "broken" behaviour if I replace the systemctl force-reload call with "sleep 10s"

I'm not 100% sure the bug is in systemd.

Well... sorry, but this is definitively a systemd issue / regression or
a samba-client bug, which should maybe call "try-restart" instead as a
workaround when under systemd.

When somebody is using "killproc -HUP" (reload) or checkproc + killproc + startproc (force-reload), they do not block as under systemd. Using the
above is not possible, because systemd will consider them "dead" after.
Further, systemd AFAIS never calls the LSB init-script's "status" action.

The if-up.d script hooks are something like events and the actions are
not allowed to block / deadlock.
Yes, sleep 10 may cause similar effect (it depends how long the hw and
other actions need): the interface will not come up in the specified
(initial) time. Increasing it to 100 sec would perhaps help, but then
it is better to disable the samba-client actions as workaround ...

The setup will continue in background and later "rcnetwork status" will
say you if it is up already or not... but systemd is never using it.

The only "fix" I see on sysconfig side is to change to use
   DHCLIENT_MODIFY_SMB_CONF=no
in %post scripts or use "if under_systemd ; then exit 0 ; fi" -- I don't
think this are good ideas.

This is an autogenerated message for OBS integration:
This bug (780644) was mentioned in
https://build.opensuse.org/request/show/139934 Factory / sysconfig

Hi!

I've linked Base:System/sysconfig (commment 40) into a 12.2-Test
branch at:

http://download.opensuse.org/repositories/home:/mtomaschewski:/branches:/openSUSE:/12.2:/Update:/Test/openSUSE_12.2_Update/

It contains somehow experimental workaround and differs from the
12.2:Update package by these relevant changes:

- Start ifup pre/post and if-up.d/if-down.d scripts in background.
  The new network/config variable WAIT_BACKGROUND_JOBS specifies
  the wait limit. Default is 5 secons, 0 disables backgrounding
  and reverts to previous blocking behavior. Attempt to solve the
  issues where interfaces are not come up in time, because some
  hook-script are blocking ifup (bnc#780644).
- Execute netconfig/ntp-runtime updates in background (bnc#780644).

This means, ifup starts all scripts in parallel into background.
When the scripts are not ready inside of 5 sec (e.g. something
is blocking them), ifup will continue -- like this:

   for script in $scriptdir/* ; do
     $script $options &
   done
   wait_jobs $WAIT_BACKGROUND_JOBS || disown -a

Any feedback about is welcome!

This is an autogenerated message for OBS integration:
This bug (780644) was mentioned in
https://build.opensuse.org/request/show/141173

Marius, I've tested your package and my test VM doesn't even get any network at all with it (but it doesn't look like WAIT_BACKGROUND_JOBS is causing it, setting the value to 0 doesn't fix the issue). And this is when disabling the systemd related ifup scripts.

Where exactly -- on factory / 12.2? This is something different I guess.

Candidates would be: the 77-network.rules udev rule is not executed because
you're on factory and the sysconfig you were using installs it in /lib and
not in /usr [update to use sysconfig with set_new_udevrules_dir.patch] or
yast2 configured ifcfg-eth0 but there is biosdevname now, which forces a
rename to eth0_s0_0 or similar crap.

BTW: I've made also a different patch for 12.2:

http://download.opensuse.org/repositories/home:/mtomaschewski:/branches:/openSUSE:/12.2:/Update/openSUSE_12.2_Update/x86_64/
-------------------------------------------------------------------
Tue Nov 13 14:15:47 UTC 2012 - mt@suse.de

- Changed rcnetwork to not report dhcp in background to systemd
  (bnc#785240,bnc#780644). You may set DHCLIENT_MODIFY_SMB_CONF
  to "no" in /etc/sysconfig/network/dhcp as the samba/cifs hooks
  make systemctl calls to reload/restart nmb and other services
  which block (systemd deadlock) ifup scripts for a long time.

-------------------------------------------------------------------

it is on 12.2. And with your updated package, I get back network and I can confirm samba / cifs hooks are no longer causing network service to fail.

This is an autogenerated message for OBS integration:
This bug (780644) was mentioned in
https://build.opensuse.org/request/show/142549 Maintenance /

This is an autogenerated message for OBS integration:
This bug (780644) was mentioned in
https://build.opensuse.org/request/show/142552 Maintenance /

This is an autogenerated message for OBS integration:
This bug (780644) was mentioned in
https://build.opensuse.org/request/show/142576 Factory / sysconfig

This is an autogenerated message for OBS integration:
This bug (780644) was mentioned in
https://build.opensuse.org/request/show/142883 Factory / sysconfig

openSUSE-RU-2012:1602-1: An update that has four recommended fixes can now be installed.

Category: recommended (low)
Bug References: 716652,780644,784952,785240
CVE References: 
Sources used:
openSUSE 12.2 (src):    sysconfig-0.76.4-1.4.1

This is an autogenerated message for OBS integration:
This bug (780644) was mentioned in
https://build.opensuse.org/request/show/144440 Maintenance /

openSUSE-RU-2012:1651-1: An update that has 5 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 716652,775281,780644,784952,785240
CVE References: 
Sources used:
openSUSE 12.1 (src):    sysconfig-0.75.4-2.16.1

Update released for 12.1 and 12.2. Resolved fixed.

Update released for: sysconfig, sysconfig-debuginfo, sysconfig-debugsource
Products:
SLE-DEBUGINFO 11-SP2 (i386, ia64, ppc64, s390x, x86_64)
SLE-DESKTOP 11-SP2 (i386, x86_64)
SLE-SERVER 11-SP2 (i386, ia64, ppc64, s390x, x86_64)
SLES4VMWARE 11-SP2 (i386, x86_64)

This is an autogenerated message for OBS integration:
This bug (780644) was mentioned in
https://build.opensuse.org/request/show/160871 Maintenance / 
https://build.opensuse.org/request/show/160872 Maintenance / 
https://build.opensuse.org/request/show/160873 Maintenance /

This is an autogenerated message for OBS integration:
This bug (780644) was mentioned in
https://build.opensuse.org/request/show/175838 Factory / sysconfig

This is an autogenerated message for OBS integration:
This bug (780644) was mentioned in
https://build.opensuse.org/request/show/175839 Factory / sysconfig