Bugzilla – Bug 781646
systemd is painfully slow -- waiting for network?
Last modified: 2014-08-31 18:13:49 UTC
Created attachment 506659 [details] systemd-analyze plot When booting, systemd always waits for something like 30 s. It looks like it waits for network interface to become up. But network.service is not shown in the output of systemd-analyze? How can I debug this?
Here network.service is shown: # systemd-analyze blame|head 5160ms md.service 4342ms network.service 1899ms systemd-vconsole-setup.service 1228ms home.mount 677ms syslog.service 619ms network-remotefs.service 596ms systemd-logind.service 539ms apache2.service 508ms localnet.service 416ms mpd.service So what takes those 30s if network takes only 4s?
Ok, just in case. I don't use NM, it's a plain ifup+dhcp, one interface. systemd-44-19.1.x86_64
systemd-analyze plot > boot.svg is usually more useful to debug those issues.
(In reply to comment #3) > systemd-analyze plot > boot.svg is usually more useful to debug those issues. This is what is attachment 506659 [details], isn't it?
(In reply to comment #4) > (In reply to comment #3) > > systemd-analyze plot > boot.svg is usually more useful to debug those issues. > > This is what is attachment 506659 [details], isn't it? oops, I missed it :) strange that you don't see network.service at all what is the output of systemctl status network.service ?
Just in case you run into this issue: Are you using BOOTPROTO=dhcp in the ifcfg file or BOOTPROTO=dhcp4? A setting of dhcp means dhcp4+dhcp6 and waits up to 15sec for IPv6 address... change to dhcp4 when there is no dhcp6 server in your network. The yast2 network default on 12.2 seems to be dhcp4 for the first interface and dhcp when you have more than one. See also bnc#779928. The difference to previous versions is, that before the dhcp6 client were not always installed by the install-pattern/package selection...
(In reply to comment #5) > what is the output of systemctl status network.service ? network.service - LSB: Configure the localfs depending network interfaces Loaded: loaded (/etc/init.d/network) Active: active (running) since Mon, 24 Sep 2012 11:44:09 +0200; 11s ago Process: 15973 ExecStop=/etc/init.d/network stop (code=exited, status=0/SUCCESS) Process: 16837 ExecStart=/etc/init.d/network start (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/network.service └ 18119 /sbin/dhcpcd --netconfig -L -E -c /etc/sysconfig/n... + tail from messages (In reply to comment #6) > Are you using BOOTPROTO=dhcp in the ifcfg file or BOOTPROTO=dhcp4? grep BOOTPROTO /etc/sysconfig/network/ifcfg-eth100 BOOTPROTO='dhcp4'
Hmm wait. It is failed after fresh boot: network.service - LSB: Configure the localfs depending network interfaces Loaded: loaded (/etc/init.d/network) Active: failed (Result: exit-code) since Mon, 24 Sep 2012 21:53:47 +0200; 1h 33min ago CGroup: name=systemd:/system/network.service └ 5260 /sbin/dhcpcd --netconfig -L -E -c /etc/sysconfig/network/scripts/dhcpcd-hook -t 0 -h bellona eth100 But why? dhcp is running, networking is fine. So?
Could you try out the following patch / change?: --- /sbin/ifup-dhcp +++ /sbin/ifup-dhcp 2012-09-25 14:47:58.050145466 +0200 @@ -694,7 +694,7 @@ ${LLADDR:+address $LLADDR} $LINK_OPTIONS # wait a bit or dhclient(6) may produce false send errors - link_ready_wait "$INTERFACE" 3 + link_ready_wait "$INTERFACE" $((${DHCLIENT_WAIT_AT_BOOT:-15}/2)) # (optionally) wait until a device is really configured sleep ${DHCLIENT_SLEEP:-0} and / or setting a DHCLIENT_SLEEP=3 or something like this. Reason: when the dhcp client is started too early (link is not really ready yet), the first packets may never reach the server and the timeout between the resend gets increased / doubled. Finally, it may need more time: Sep 25 12:39:21 trinity kernel: [ 3205.004153] ADDRCONF(NETDEV_UP): eth0: link is not ready Sep 25 12:39:25 trinity kernel: [ 3208.418415] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx Sep 25 12:39:25 trinity kernel: [ 3208.419175] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Sep 25 12:39:25 trinity ifup-dhcp: eth0 Starting DHCP4 client Sep 25 12:39:25 trinity dhcpcd[8905]: eth0: dhcpcd 3.2.3 starting Sep 25 12:39:25 trinity dhcpcd[8905]: eth0: hardware address = 90:b1:1c:5e:16:cf Sep 25 12:39:25 trinity dhcpcd[8905]: eth0: broadcasting for a lease Sep 25 12:39:25 trinity ifup-dhcp: . Sep 25 12:39:27 trinity ifup-dhcp: . Sep 25 12:39:30 trinity ifup-dhcp: . Sep 25 12:39:32 trinity ifup-dhcp: . Sep 25 12:39:34 trinity dhcpcd[8905]: eth0: offered 172.16.20.4 from 172.16.0.245 `exodus'
Another test you may try: stop using the network "rcnetwork stop" (will redirect to the systemd). Then stop again with -o boot (systemd not involved here) and remove the modules: /etc/init.d/network stop -o boot ; rmmod e1000e then load & start again + check the time: modprobe e1000e ; time /etc/init.d/network stop -o boot This should be very similar to the time it needs at boot.
(In reply to comment #10) > then load & start again + check the time: > modprobe e1000e ; time /etc/init.d/network stop -o boot ^^^^ start
(In reply to comment #10) > then load & start again + check the time: > modprobe e1000e ; time /etc/init.d/network start -o boot real 0m5.808s user 0m0.220s sys 0m0.240s But at boot, I see waiting for mandatory devices: eth100. . . . . And it looks like it must time out to proceed...
Hmm... I've installed 12.2 on my brand new machine that arrived yesterday and it needs up to 15 sec to get dhcp4 + dhcp6 IPs on its Intel NIC -- this is longer than my old machine...: Sep 26 15:01:27 trinity network[4685]: Setting up (localfs) network interfaces: ... Sep 26 15:01:27 trinity ifup[5050]: eth0 device: Intel Corporation 82579LM Gigabit Network Con Sep 26 15:01:28 trinity kernel: [ 499.013491] e1000e 0000:00:19.0: irq 45 for MSI/MSI-X Sep 26 15:01:28 trinity kernel: [ 499.114196] e1000e 0000:00:19.0: irq 45 for MSI/MSI-X Sep 26 15:01:28 trinity kernel: [ 499.114993] ADDRCONF(NETDEV_UP): eth0: link is not ready Sep 26 15:01:31 trinity kernel: [ 502.585932] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx Sep 26 15:01:31 trinity kernel: [ 502.586680] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Sep 26 15:01:31 trinity ifup-dhcp[5100]: eth0 Starting DHCP4+DHCP6 client ... Sep 26 15:01:31 trinity dhcpcd[5949]: eth0: sending DHCP_DISCOVER with xid 0x36f274b6 Sep 26 15:01:31 trinity dhcpcd[5949]: eth0: waiting for 20 seconds Sep 26 15:01:31 trinity dhclient[5965]: Internet Systems Consortium DHCP Client 4.2.4-P2 Sep 26 15:01:32 trinity dhclient[5965]: Bound to *:546 Sep 26 15:01:32 trinity dhclient[5965]: Listening on Socket/eth0 Sep 26 15:01:32 trinity dhclient[5965]: Sending on Socket/eth0 Sep 26 15:01:33 trinity dhclient[5965]: XMT: Confirm on eth0, interval 980ms. Sep 26 15:01:33 trinity dhclient[5965]: send_packet6: Cannot assign requested address Sep 26 15:01:33 trinity dhclient[5965]: dhc6: sendpacket6() sent -1 of 82 bytes <==== 1st send failed because it were sent before the interface has a link-local address (fe80:*). Sep 26 15:01:33 trinity dhclient[5965]: XMT: Confirm on eth0, interval 1890ms. Sep 26 15:01:34 trinity ifup-dhcp[5100]: . Sep 26 15:01:34 trinity dhcpcd[5949]: eth0: sending DHCP_DISCOVER with xid 0x36f274b6 <==== 1st send never arrived (also too early?), now resend after ~3 sec. Sep 26 15:01:35 trinity dhclient[5965]: XMT: Confirm on eth0, interval 3850ms. Sep 26 15:01:35 trinity dhclient[5965]: RCV: Reply message on eth0 from fe80::21b:21ff:febf:79f0. Sep 26 15:01:35 trinity dhclient[5965]: message status code Success: "All addresses still on link." <==== OK, IPv6 address confirmed, so basically DHCPv6 is done here <==== and dhclient-script calls "ifup -o dhcp": Sep 26 15:01:36 trinity ifup[6440]: eth0 device: Intel Corporation 82579LM Gigabit Network Connection (rev 04) <==== OK, DHCPv6 completed here... it needed 5 secs to confirm. 1sec more than optimal because it started too early. Sep 26 15:01:36 trinity ifup-dhcp[5100]: . Sep 26 15:01:39 trinity ifup-dhcp[5100]: . Sep 26 15:01:40 trinity dhcpcd[5949]: eth0: sending DHCP_DISCOVER with xid 0x36f274b6 <==== Again?! Sep 26 15:01:40 trinity dhcpcd[5949]: eth0: got a packet with xid 0x36f274b6 Sep 26 15:01:40 trinity dhcpcd[5949]: eth0: offered 172.16.20.4 from 172.16.0.245 `exodus' Sep 26 15:01:40 trinity dhcpcd[5949]: eth0: sending DHCP_REQUEST with xid 0x36f274b6 Sep 26 15:01:40 trinity dhcpcd[5949]: eth0: waiting for 11 seconds Sep 26 15:01:41 trinity dhcpcd[5949]: eth0: got a packet with xid 0x36f274b6 Sep 26 15:01:41 trinity dhcpcd[5949]: eth0: checking 172.16.20.4 is available on attached networks Sep 26 15:01:41 trinity dhcpcd[5949]: eth0: sending ARP probe #1 Sep 26 15:01:41 trinity dhcpcd[5949]: eth0: sending ARP probe #2 Sep 26 15:01:41 trinity ifup-dhcp[5100]: . Sep 26 15:01:41 trinity dhcpcd[5949]: eth0: sending ARP probe #3 Sep 26 15:01:41 trinity dhcpcd[5949]: eth0: sending ARP claim #1 Sep 26 15:01:41 trinity dhcpcd[5949]: eth0: sending ARP claim #2 Sep 26 15:01:42 trinity dhcpcd[5949]: eth0: leased 172.16.20.4 for 3600 seconds Sep 26 15:01:42 trinity dhcpcd[5949]: eth0: renew in 1800 seconds Sep 26 15:01:42 trinity dhcpcd[5949]: eth0: rebind in 3150 seconds Sep 26 15:01:42 trinity dhcpcd[5949]: eth0: adding IP address 172.16.20.4/24 Sep 26 15:01:42 trinity dhcpcd[5949]: eth0: adding default route via 172.16.20.254 metric 0 Sep 26 15:01:42 trinity dhcpcd[5949]: eth0: no dns information to write Sep 26 15:01:42 trinity dhcpcd[5949]: eth0: writing /var/lib/dhcpcd/dhcpcd-eth0.info Sep 26 15:01:42 trinity dhcpcd[5949]: eth0: exec "/etc/sysconfig/network/scripts/dhcpcd-hook" "/var/lib/dhcpcd/dhcpcd-eth0.info" "new" Sep 26 15:01:42 trinity dhcpcd-hook: State: new. Leaseinfo: /var/lib/dhcpcd/dhcpcd-eth0.info Sep 26 15:01:42 trinity dhcpcd-hook: new IP address: 172.16.20.4 Sep 26 15:01:42 trinity dhcpcd-hook: debug: no /var/run/ntp directory - skipping Sep 26 15:01:42 trinity dhcpcd-hook: Running ifdown eth0 -o dhcp Sep 26 15:01:42 trinity ifdown[7074]: eth0 device: Intel Corporation 82579LM Gigabit Network Connection (rev 04) Sep 26 15:01:42 trinity dhcpcd[5949]: eth0: exec "/etc/sysconfig/network/scripts/dhcpcd-hook" "/var/lib/dhcpcd/dhcpcd-eth0.info" "complete" Sep 26 15:01:42 trinity dhcpcd-hook: State: complete. Leaseinfo: /var/lib/dhcpcd/dhcpcd-eth0.info Sep 26 15:01:42 trinity dhcpcd-hook: Running ifup eth0 -o dhcp Sep 26 15:01:42 trinity ifup[7179]: eth0 device: Intel Corporation 82579LM Gigabit Network Connection (rev 04) Sep 26 15:01:42 trinity dhcpcd-hook: DHCP4 configuration of eth0 is complete Sep 26 15:01:42 trinity dhcpcd[5949]: eth0: forking to background Sep 26 15:01:42 trinity dhcpcd[5949]: eth0: exiting Sep 26 15:01:42 trinity dhcpcd[7307]: eth0: waiting for 1800 seconds Sep 26 15:01:42 trinity network[4685]: eth0 Starting DHCP4+DHCP6 client. . . . . Sep 26 15:01:42 trinity ifup-dhcp[5100]: Sep 26 15:01:42 trinity network[4685]: eth0 IP address: 172.16.20.4/24 (trinity) Sep 26 15:01:42 trinity ifup-dhcp[5100]: eth0 IP address: 172.16.20.4/24 (trinity) Sep 26 15:01:42 trinity network[4685]: eth0 IP address: 2001:470:5036:2000::4/64 Sep 26 15:01:42 trinity ifup-dhcp[5100]: eth0 IP address: 2001:470:5036:2000::4/64 Sep 26 15:01:42 trinity network[4685]: ..done eth1 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B Sep 26 15:01:42 trinity ifup[7357]: eth1 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B Sep 26 15:01:42 trinity network[4685]: No configuration found for eth1 Sep 26 15:01:42 trinity ifup[7357]: No configuration found for eth1 Sep 26 15:01:42 trinity network[4685]: ..unusedSetting up service (localfs) network . . . . . . . . . ...done but it is not DHCPv6 that needs longer in this case but DHCPv4... why?! I think I've to take a look at my dhcpv4 server, ... I've set DHCLIENT_SLEEP=3 and then I have ~ 4 sec until link becomes ready + 3 sleep, then 2 discovers and dhcp4 is ready after 4 sec; total rcnetwork boot time of 12 sec: Sep 26 15:26:31 trinity network[540]: Setting up (localfs) network interfaces: Sep 26 15:26:31 trinity ifup[926]: eth0 device: Intel Corporation 82579LM Gigabit Network Con Sep 26 15:26:32 trinity kernel: [ 12.726890] e1000e 0000:00:19.0: irq 45 for MSI/MSI-X Sep 26 15:26:32 trinity kernel: [ 12.827797] e1000e 0000:00:19.0: irq 45 for MSI/MSI-X Sep 26 15:26:32 trinity kernel: [ 12.828596] ADDRCONF(NETDEV_UP): eth0: link is not ready Sep 26 15:26:36 trinity kernel: [ 16.191785] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx Sep 26 15:26:36 trinity kernel: [ 16.192285] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Sep 26 15:26:38 trinity ifup-dhcp[976]: eth0 Starting DHCP4+DHCP6 client Sep 26 15:26:38 trinity dhcpcd[1804]: eth0: dhcpcd 3.2.3 starting Sep 26 15:26:38 trinity dhcpcd[1804]: eth0: sending DHCP_DISCOVER with xid 0x2542804d Sep 26 15:26:38 trinity dhclient[1822]: Internet Systems Consortium DHCP Client 4.2.4-P2 Sep 26 15:26:40 trinity dhclient[1822]: RCV: Reply message on eth0 from fe80::21b:21ff:febf:79f0. Sep 26 15:26:40 trinity dhclient[1822]: message status code Success: "All addresses still on link." Sep 26 15:26:40 trinity ifup[2159]: eth0 device: Intel Corporation 82579LM Gigabit Network Connection (rev 04) Sep 26 15:26:40 trinity ifup-dhcp[976]: . Sep 26 15:26:41 trinity dhcpcd[1804]: eth0: sending DHCP_DISCOVER with xid 0x2542804d Sep 26 15:26:41 trinity dhcpcd[1804]: eth0: got a packet with xid 0x2542804d Sep 26 15:26:41 trinity dhcpcd[1804]: eth0: offered 172.16.20.4 from 172.16.0.245 `exodus' Sep 26 15:26:41 trinity dhcpcd[1804]: eth0: sending DHCP_REQUEST with xid 0x2542804d Sep 26 15:26:41 trinity dhcpcd[1804]: eth0: waiting for 17 seconds Sep 26 15:26:41 trinity dhcpcd[1804]: eth0: got a packet with xid 0x2542804d Sep 26 15:26:42 trinity dhcpcd-hook: DHCP4 configuration of eth0 is complete Sep 26 15:26:43 trinity network[540]: ..Setting up service (localfs) network . . . . . . . . . ...done next boot sent only 1 discover and dhcp4+6 needed only ~3 sec (+4 link and +3 sleep), but total at 15 again -- some post-hook wasted time (samba hook problems or a similar issue kicks us back?)? Sep 26 15:35:11 trinity network[498]: Setting up (localfs) network interfaces: Sep 26 15:35:12 trinity kernel: [ 9.966713] ADDRCONF(NETDEV_UP): eth0: link is not ready Sep 26 15:35:15 trinity kernel: [ 12.704165] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Sep 26 15:35:18 trinity dhcpcd[1634]: eth0: dhcpcd 3.2.3 starting Sep 26 15:35:18 trinity kernel: [ 15.716686] NET: Registered protocol family 17 Sep 26 15:35:18 trinity dhclient[1652]: Internet Systems Consortium DHCP Client 4.2.4-P2 Sep 26 15:35:19 trinity dhcpcd-hook: DHCP4 configuration of eth0 is complete Sep 26 15:35:23 trinity ifup-dhcp[946]: . Sep 26 15:35:35 ifup-dhcp[946]: last message repeated 5 times Sep 26 15:35:35 trinity network[498]: ..unusedSetting up service (localfs) network . . . . . . . . . ...done But it looks to me, that the time between "ip link set up", link ready and link really usable is much longer than before & packets go to /dev/null.
I've added a "modprobe af_packet" before the link is set up or dhcp clients are started and it is much better now: Sep 26 16:05:37 trinity network[526]: Setting up (localfs) network interfaces: Sep 26 16:05:38 trinity ifup[910]: eth0 device: Intel Corporation 82579LM Gigabit Network Con Sep 26 16:05:39 trinity kernel: [ 5.413336] NET: Registered protocol family 17 Sep 26 16:05:39 trinity kernel: [ 5.547356] e1000e 0000:00:19.0: irq 45 for MSI/MSI-X Sep 26 16:05:39 trinity kernel: [ 5.648244] e1000e 0000:00:19.0: irq 45 for MSI/MSI-X Sep 26 16:05:39 trinity kernel: [ 5.649048] ADDRCONF(NETDEV_UP): eth0: link is not ready Sep 26 16:05:41 trinity kernel: [ 8.401977] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx Sep 26 16:05:42 trinity kernel: [ 8.402730] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Sep 26 16:05:45 trinity dhcpcd[1649]: eth0: dhcpcd 3.2.3 starting Sep 26 16:05:45 trinity dhcpcd[1649]: eth0: sending DHCP_DISCOVER with xid 0x67773c8a ... Sep 26 16:05:45 trinity dhclient[1665]: Internet Systems Consortium DHCP Client 4.2.4-P2 Sep 26 16:05:45 trinity dhcpcd[1649]: eth0: offered 172.16.20.4 from 172.16.0.245 `exodus' Sep 26 16:05:45 trinity dhcpcd[1649]: eth0: sending DHCP_REQUEST with xid 0x67773c8a Sep 26 16:05:45 trinity dhcpcd[1649]: eth0: got a packet with xid 0x67773c8a Sep 26 16:05:45 trinity dhcpcd[1649]: eth0: sending ARP probe #1 ... Sep 26 16:05:46 trinity dhclient[1665]: Bound to *:546 Sep 26 16:05:46 trinity dhclient[1665]: XMT: Confirm on eth0, interval 980ms. Sep 26 16:05:46 trinity dhclient[1665]: RCV: Reply message on eth0 from fe80::21b:21ff:febf:79f0. Sep 26 16:05:46 trinity dhclient[1665]: message status code Success: "All addresses still on link." Sep 26 16:05:46 trinity dhcpcd[1649]: eth0: leased 172.16.20.4 for 3600 seconds Sep 26 16:05:46 trinity dhcpcd-hook: DHCP4 configuration of eth0 is complete <<<=== basically done: link ready 5sec after start [NIC needs 4sec[, dhcp4 done in 2sec, dhcp6 in 1sec, total until now 9sec (with bash -x debug enabled). Sep 26 16:05:47 trinity ifup-dhcp[960]: . Sep 26 16:05:49 trinity ifup-dhcp[960]: . Sep 26 16:05:51 trinity network[526]: ..unusedSetting up service (localfs) network . . . . . . . . . ...done the post scripts need 5sec ... :-( But I think we have a significant improvement already. Sep 26 16:05:53 trinity systemd[1]: Startup finished in 2s 902ms 599us (kernel) + 17s 230ms 659us (userspace) = 20s 133ms 258us. I'll prepare a test package that contains my changes.
Frederic, I reassign to myself for now -- when we're done with network, it may come back :-)
(In reply to comment #14) > I've added a "modprobe af_packet" before the link is set up or dhcp > clients are started and it is much better now: Just a note. This won't definitely help me, since I have no modules. Everything is built in here.
Ah... ok. When you look at bnc#780644, Don has a "infinite" post-script time instead of the 5 sec I've noticed [end of comment 15]. Looks like there something would go really wrong under some conditions... Please set DHCLIENT_DEBUG=yes, DHCLIENT6_DEBUG=yes in network/dhcp plus DEBUG=EXTRA in /etc/sysconfig/network/config, reboot, then grab the results: "tar cvzpf /tmp/network-exdbg.tgz /dev/.sysconfig/network" and attach /tmp/network-exdbg.tgz, messages and /var/log/dhclient*.log.
(In reply to comment #17) > of the 5 sec I've noticed [end of comment 15]. Looks like there something 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.
Created attachment 507249 [details] packed /dev/.sysconfig/network
Created attachment 507250 [details] excerpt from /var/log/messages
(In reply to comment #17) > /var/log/dhclient*.log. dhcpcd here.
(In reply to comment #19) > Could you try if this package helps (not yet published): > > http://download.opensuse.org/repositories/home:/mtomaschewski:/branches:/openSUSE:/12.2:/Update/ Updating sysconfig from here has no effect, unfortunately.
It is the "systemctl --ignore-dependencies force-reload nmb.service" provided by samba-client (21-dhcpcd-hook-samba) again (bnc#732395); See: grep "systemctl.*force-reload" exdeb.*. 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, when not needed.
Frederic, can you take a look at the hooks again?
(In reply to comment #24) > It is the "systemctl --ignore-dependencies force-reload nmb.service" > provided by samba-client (21-dhcpcd-hook-samba) again (bnc#732395); Confirmed. Removing that line from the hook fixes the problem. Actually I hit the issue some time ago (bnc#731308), but already forgot...
Too lazy to track two bugs about the same. *** This bug has been marked as a duplicate of bug 780644 ***