Bug 780644 - interface could not be set up until now
interface could not be set up until now
Status: RESOLVED FIXED
: 781646 (view as bug list)
Classification: openSUSE
Product: openSUSE 12.2
Classification: openSUSE
Component: Network
Final
x86-64 openSUSE 12.2
: P5 - None : Normal (vote)
: ---
Assigned To: Frederic Crozat
E-mail List
maint:released:sle11-sp2:50983
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-15 23:51 UTC by Don Hughes
Modified: 2013-05-16 10:00 UTC (History)
5 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
ifcfg (188 bytes, application/octet-stream)
2012-09-24 16:36 UTC, Don Hughes
Details
ifstatus (15.86 KB, application/octet-stream)
2012-09-24 16:36 UTC, Don Hughes
Details
dhclient6 log (8.86 KB, application/octet-stream)
2012-09-26 13:33 UTC, Don Hughes
Details
system log (77.10 KB, application/octet-stream)
2012-09-26 13:33 UTC, Don Hughes
Details
DEBUG=EXTRA (1.32 MB, application/octet-stream)
2012-09-26 17:40 UTC, Don Hughes
Details
Configs (915 bytes, application/octet-stream)
2012-09-26 17:41 UTC, Don Hughes
Details
DEBUG=EXTRA (415.34 KB, application/octet-stream)
2012-09-27 12:15 UTC, Don Hughes
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Don Hughes 2012-09-15 23:51:53 UTC
User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0.1

System upgraded from 11.4 to 12.2

During boot I get the following message:

Warning: ifcfg-Net1 overrides interface type detection.
Please open a bug report



Sep 15 19:19:24 Buzzard ifup-dhcp[1079]: .
Sep 15 19:19:25 Buzzard dhcpcd[1858]: Net1: leased 10.168.1.11 for 259200 seconds
Sep 15 19:19:25 Buzzard dhcpcd[1858]: Net1: adding IP address 10.168.1.11/21
Sep 15 19:19:25 Buzzard dhcpcd[1858]: Net1: adding default route via 10.168.7.1 metric 0
Sep 15 19:19:25 Buzzard ifdown[2058]:     Net1      device: Broadcom Corporation NetLink BCM57788 Gigabit Ethernet PCIe (rev 01)
Sep 15 19:19:26 Buzzard dhcpcd[1858]: Net1: setting hostname to `Buzzard'
Sep 15 19:19:26 Buzzard ifup[2171]:     Net1      device: Broadcom Corporation NetLink BCM57788 Gigabit Ethernet PCIe (rev 01)
Sep 15 19:19:27 Buzzard ifup-dhcp[1079]: .
Sep 15 19:19:27 Buzzard ifup[2447]:     Net1      device: Broadcom Corporation NetLink BCM57788 Gigabit Ethernet PCIe (rev 01)
Sep 15 19:19:30 Buzzard ifup-dhcp[1079]: .
Sep 15 19:19:32 Buzzard ifup-dhcp[1079]: .
Sep 15 19:19:35 Buzzard network[641]: Net1      Starting DHCP4+DHCP6 client. . . .
Sep 15 19:19:35 Buzzard ifup-dhcp[1079]:
Sep 15 19:19:35 Buzzard network[641]: Net1      DHCP4 continues in background
Sep 15 19:19:35 Buzzard ifup-dhcp[1079]:     Net1      DHCP4 continues in background
Sep 15 19:19:35 Buzzard network[641]: Net1      DHCP6 continues in background
Sep 15 19:19:35 Buzzard ifup-dhcp[1079]:     Net1      DHCP6 continues in background
Sep 15 19:19:35 Buzzard network[641]: [1Awaiting
Sep 15 19:19:35 Buzzard network[641]: Net1      Warning: ifcfg-Net1 overrides interface type detection.
Sep 15 19:19:35 Buzzard network[641]: Please open a bug report.
Sep 15 19:19:35 Buzzard network[641]: Net1      device: Broadcom Corporation NetLink BCM57788 Gigabit
Sep 15 19:19:35 Buzzard network[641]: Net1      . . . is just beeing set up
Sep 15 19:19:35 Buzzard network[641]: Net1      IP address: 10.168.1.11/21
Sep 15 19:19:35 Buzzard network[641]: Net1      IP address: 2001:470:1f06:838:3:5:11:1/64
Sep 15 19:19:35 Buzzard network[641]: Net1      is up
Sep 15 19:19:35 Buzzard network[641]: [1Awaiting
Sep 15 19:19:35 Buzzard network[641]: Net1      interface could not be set up until now
Sep 15 19:19:35 Buzzard network[641]: ..failedSetting up service (localfs) network  .  .  .  .  .  .  .  .  .  ...failed
Sep 15 19:19:35 Buzzard systemd[1]: network.service: control process exited, code=exited status=7
Sep 15 19:19:35 Buzzard systemd[1]: Unit network.service entered failed state.
Sep 15 19:19:36 Buzzard /usr/sbin/cron[3292]: (CRON) INFO (running with inotify support)
Sep 15 19:19:36 Buzzard mysql[3293]: /etc/rc.status: line 57: /dev/stderr: No such device or address
Sep 15 19:19:36 Buzzard kernel: [   24.875524] Bluetooth: Core ver 2.16
Sep 15 19:19:36 Buzzard kernel: [   24.875543] NET: Registered protocol family 31
Sep 15 19:19:36 Buzzard kernel: [   24.875544] Bluetooth: HCI device and connection manager initialized
Sep 15 19:19:3

Reproducible: Always

Steps to Reproduce:
1.Boot system
2.Inspect log
3.
Comment 1 Bin Li 2012-09-18 05:55:44 UTC
Assign to Maintainer.
Comment 2 Marius Tomaschewski 2012-09-21 07:05:58 UTC
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
Comment 3 Marius Tomaschewski 2012-09-21 07:10:39 UTC
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.
Comment 4 Don Hughes 2012-09-24 16:33:32 UTC
I did not modify the ifcfg-Net1 file.

The result of get_iface_type Net1 was 'eth'

status-Net1.out attached
Comment 5 Don Hughes 2012-09-24 16:36:04 UTC
Created attachment 506793 [details]
ifcfg
Comment 6 Don Hughes 2012-09-24 16:36:51 UTC
Created attachment 506794 [details]
ifstatus
Comment 7 Marius Tomaschewski 2012-09-25 12:39:27 UTC
(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)

?
Comment 8 Don Hughes 2012-09-25 20:21:46 UTC
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)
Comment 9 Marius Tomaschewski 2012-09-26 10:46:13 UTC
(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.
Comment 10 Marius Tomaschewski 2012-09-26 12:16:04 UTC
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
Comment 11 Don Hughes 2012-09-26 13:31:57 UTC
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.
Comment 12 Don Hughes 2012-09-26 13:33:25 UTC
Created attachment 507184 [details]
dhclient6 log
Comment 13 Don Hughes 2012-09-26 13:33:55 UTC
Created attachment 507185 [details]
system log
Comment 14 Marius Tomaschewski 2012-09-26 14:32:56 UTC
Going to review what happens here.

See also bug 781646 -- it may be related.
Comment 15 Marius Tomaschewski 2012-09-26 14:34:51 UTC
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?
Comment 16 Marius Tomaschewski 2012-09-26 14:36:09 UTC
Or better, can you install "supportutils", call "supportconfig" and
attach the resulting file please?
Comment 17 Marius Tomaschewski 2012-09-26 14:45:38 UTC
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.
Comment 18 Marius Tomaschewski 2012-09-26 15:00:18 UTC
In my testes I've never seen more than 5 sec for the post scripts
(see bug 781646 comment 14).
Comment 19 Marius Tomaschewski 2012-09-26 17:30:43 UTC
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.
Comment 20 Don Hughes 2012-09-26 17:38:12 UTC
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
Comment 21 Don Hughes 2012-09-26 17:40:33 UTC
Created attachment 507241 [details]
DEBUG=EXTRA
Comment 22 Don Hughes 2012-09-26 17:41:02 UTC
Created attachment 507242 [details]
Configs
Comment 23 Don Hughes 2012-09-26 18:05:44 UTC
In reference to not being able to update ifcfg-?, I previously filed bug #695262.
Comment 24 Marius Tomaschewski 2012-09-27 10:35:28 UTC
(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...
Comment 25 Marius Tomaschewski 2012-09-27 10:46:21 UTC
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.
Comment 26 Marius Tomaschewski 2012-09-27 10:53:26 UTC
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" ...
Comment 27 Don Hughes 2012-09-27 12:13:37 UTC
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.
Comment 28 Don Hughes 2012-09-27 12:15:03 UTC
Created attachment 507416 [details]
DEBUG=EXTRA
Comment 29 Marius Tomaschewski 2012-09-27 12:49:29 UTC
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...
Comment 30 Marius Tomaschewski 2012-09-27 12:52:41 UTC
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?
Comment 31 Don Hughes 2012-09-27 13:57:20 UTC
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.
Comment 32 Marius Tomaschewski 2012-09-27 14:44:03 UTC
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).
Comment 33 Frederic Crozat 2012-09-27 16:59:16 UTC
Ok, I've duplicated the issue in a VM, I'll look into it..
Comment 34 Jiri Slaby 2012-09-27 17:35:27 UTC
*** Bug 781646 has been marked as a duplicate of this bug. ***
Comment 35 Don Hughes 2012-09-27 19:52:03 UTC
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.
Comment 36 Marius Tomaschewski 2012-09-28 08:07:03 UTC
(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.
Comment 37 Frederic Crozat 2012-09-28 08:34:39 UTC
(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".
Comment 38 Frederic Crozat 2012-10-09 16:12:26 UTC
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.
Comment 39 Marius Tomaschewski 2012-10-25 15:30:48 UTC
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.
Comment 40 Bernhard Wiedemann 2012-11-01 18:00:15 UTC
This is an autogenerated message for OBS integration:
This bug (780644) was mentioned in
https://build.opensuse.org/request/show/139934 Factory / sysconfig
Comment 41 Marius Tomaschewski 2012-11-02 08:23:57 UTC
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!
Comment 42 Bernhard Wiedemann 2012-11-14 13:42:05 UTC
This is an autogenerated message for OBS integration:
This bug (780644) was mentioned in
https://build.opensuse.org/request/show/141173
Comment 43 Frederic Crozat 2012-11-19 14:54:00 UTC
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.
Comment 44 Marius Tomaschewski 2012-11-19 17:09:16 UTC
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.
Comment 45 Marius Tomaschewski 2012-11-19 17:16:43 UTC
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.

-------------------------------------------------------------------
Comment 46 Frederic Crozat 2012-11-19 18:13:31 UTC
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.
Comment 47 Bernhard Wiedemann 2012-11-23 10:00:19 UTC
This is an autogenerated message for OBS integration:
This bug (780644) was mentioned in
https://build.opensuse.org/request/show/142549 Maintenance /
Comment 48 Bernhard Wiedemann 2012-11-23 11:00:19 UTC
This is an autogenerated message for OBS integration:
This bug (780644) was mentioned in
https://build.opensuse.org/request/show/142552 Maintenance /
Comment 49 Bernhard Wiedemann 2012-11-23 13:00:08 UTC
This is an autogenerated message for OBS integration:
This bug (780644) was mentioned in
https://build.opensuse.org/request/show/142576 Factory / sysconfig
Comment 50 Bernhard Wiedemann 2012-11-26 11:00:11 UTC
This is an autogenerated message for OBS integration:
This bug (780644) was mentioned in
https://build.opensuse.org/request/show/142883 Factory / sysconfig
Comment 51 Swamp Workflow Management 2012-12-04 13:10:32 UTC
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
Comment 52 Bernhard Wiedemann 2012-12-06 19:00:26 UTC
This is an autogenerated message for OBS integration:
This bug (780644) was mentioned in
https://build.opensuse.org/request/show/144440 Maintenance /
Comment 53 Swamp Workflow Management 2012-12-17 12:09:18 UTC
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
Comment 54 Benjamin Brunner 2012-12-17 12:11:31 UTC
Update released for 12.1 and 12.2. Resolved fixed.
Comment 55 Swamp Workflow Management 2013-02-05 20:21:41 UTC
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)
Comment 56 Bernhard Wiedemann 2013-03-25 09:00:08 UTC
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 /
Comment 57 Bernhard Wiedemann 2013-05-16 09:00:10 UTC
This is an autogenerated message for OBS integration:
This bug (780644) was mentioned in
https://build.opensuse.org/request/show/175838 Factory / sysconfig
Comment 58 Bernhard Wiedemann 2013-05-16 10:00:09 UTC
This is an autogenerated message for OBS integration:
This bug (780644) was mentioned in
https://build.opensuse.org/request/show/175839 Factory / sysconfig