Am 18.09.2013 15:18, schrieb Andrey Borzenkov:

В Wed, 18 Sep 2013 23:05:38 +1000 Basil Chupin пишет:

...

...when the boot process reaches the stage 'Starting Login Service'?

Because other services that are being started take longer?

...

I have noticed this for quite some time but hadn't bothered about this until now.

When the system is booting there is a pause of 21.7 seconds when the kernel messages on the screen show 'Starting Login Service'. After this pause the login screen is reached in about 3 seconds.

Login Service has nothing to do with login screen, the name is misleading. Login Service starts systemd-logind which registers sessions, but it is not responsible for starting programs that let you log in (getty, [kgx]dm etc). So two events are not related.

...

Anybody know why there is this long pause, please?

Install systemd-analyze and look at graph that shows relative timing of different services. This will answer, what startup is waiting for.

...

I really don't remember when this started but if it is of any relevance this delay is present even in the just-upgraded kernel 3.11.1-2.

BC

Basil, my machine shows the same behaviour. You can do what Andrey suggested, then open a console and enter the following commands. This will tell you how much time your system and the services need during startup: ~> systemd-analyze Startup finished in 5209ms (kernel) + 30604ms (userspace) = 35814ms ~> systemd-analyze blame 1555ms download.mount 1451ms cycle.service 1450ms systemd-udev-root-symlink.service 1355ms network.service 1319ms systemd-vconsole-setup.service 981ms systemd-remount-fs.service 967ms dev-hugepages.mount 966ms dev-mqueue.mount 866ms systemd-modules-load.service 517ms systemd-logind.service 363ms irq_balancer.service 328ms rsyslog.service 289ms home.mount 230ms boot.mount 136ms lm_sensors.service 133ms systemd-readahead-replay.service 121ms xdm.service 100ms console-kit-daemon.service -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Am 18.09.2013 16:24, schrieb Andrey Borzenkov:

В Wed, 18 Sep 2013 15:45:06 +0200 Freigeist пишет:

...

~> systemd-analyze blame

No, in this case you want systemd-analyze plot which shows when exactly service startup began and finished. blame shows how long individual services tool, but it won't answer what exactly was waited for in this period.

You are right. My mistake, sorry for this. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 18/09/13 23:18, Andrey Borzenkov wrote:

� Wed, 18 Sep 2013 23:05:38 +1000 Basil Chupin �����:

...

...when the boot process reaches the stage 'Starting Login Service'?

Because other services that are being started take longer?

...

I have noticed this for quite some time but hadn't bothered about this until now.

When the system is booting there is a pause of 21.7 seconds when the kernel messages on the screen show 'Starting Login Service'. After this pause the login screen is reached in about 3 seconds.

Login Service has nothing to do with login screen, the name is misleading. Login Service starts systemd-logind which registers sessions, but it is not responsible for starting programs that let you log in (getty, [kgx]dm etc). So two events are not related.

...

Anybody know why there is this long pause, please?

Install systemd-analyze and look at graph that shows relative timing of different services. This will answer, what startup is waiting for.

Thanks for this, but I see no graph when I run systemd-analyze - even with the 'plot' option which you mention later. When I do run 'plot' all I see are pages and pages and pages of meaningless - to me - output.

I really don't remember when this started but if it is of any relevance this delay is present even in the just-upgraded kernel 3.11.1-2.

BC -- Using openSUSE 12.3, KDE 4.11.1 & kernel 3.11.1-2 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 20/09/13 23:02, Andrey Borzenkov wrote:

В Fri, 20 Sep 2013 22:56:16 +1000 Basil Chupin пишет:

...

On 18/09/13 23:18, Andrey Borzenkov wrote:

...

� Wed, 18 Sep 2013 23:05:38 +1000 Basil Chupin �����:

...

...when the boot process reaches the stage 'Starting Login Service'?

Because other services that are being started take longer?

...

I have noticed this for quite some time but hadn't bothered about this until now.

When the system is booting there is a pause of 21.7 seconds when the kernel messages on the screen show 'Starting Login Service'. After this pause the login screen is reached in about 3 seconds.

Login Service has nothing to do with login screen, the name is misleading. Login Service starts systemd-logind which registers sessions, but it is not responsible for starting programs that let you log in (getty, [kgx]dm etc). So two events are not related.

...

Anybody know why there is this long pause, please?

Install systemd-analyze and look at graph that shows relative timing of different services. This will answer, what startup is waiting for. Thanks for this, but I see no graph when I run systemd-analyze - even with the 'plot' option which you mention later. When I do run 'plot' all I see are pages and pages and pages of meaningless - to me - output.

Could you make it available?

OK, if you insist :-) . But I am sending it to you personally as an attachment in a separate message 'cause it is 437Kb big.

I really don't remember when this started but if it is of any relevance this delay is present even in the just-upgraded kernel 3.11.1-2.

BC -- Using openSUSE 12.3, KDE 4.11.1 & kernel 3.11.1-2 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 20/09/13 23:44, Andrey Borzenkov wrote:

В Fri, 20 Sep 2013 23:18:53 +1000 Basil Chupin пишет:

...

On 20/09/13 23:02, Andrey Borzenkov wrote:

...

В Fri, 20 Sep 2013 22:56:16 +1000 Basil Chupin пишет:

...

On 18/09/13 23:18, Andrey Borzenkov wrote:

...

� Wed, 18 Sep 2013 23:05:38 +1000 Basil Chupin �����:

...

...when the boot process reaches the stage 'Starting Login Service'?

Because other services that are being started take longer?

...

I have noticed this for quite some time but hadn't bothered about this until now.

When the system is booting there is a pause of 21.7 seconds when the kernel messages on the screen show 'Starting Login Service'. After this pause the login screen is reached in about 3 seconds.

Login Service has nothing to do with login screen, the name is misleading. Login Service starts systemd-logind which registers sessions, but it is not responsible for starting programs that let you log in (getty, [kgx]dm etc). So two events are not related.

...

Anybody know why there is this long pause, please?

Install systemd-analyze and look at graph that shows relative timing of different services. This will answer, what startup is waiting for. Thanks for this, but I see no graph when I run systemd-analyze - even with the 'plot' option which you mention later. When I do run 'plot' all I see are pages and pages and pages of meaningless - to me - output.

Could you make it available? OK, if you insist :-) . But I am sending it to you personally as an attachment in a separate message 'cause it is 437Kb big.

network.service took about 22 seconds to become active.

Yes I gathered that from what I saw when booting 13.1 Beta. The question, of course, is what exactly, and why, should be taking so much time to activate the network. I am not using the new Network Manager (as far as I know) and there is nothing special about my setup - a wired modem/router with 2 computers on the LAN. BC -- Using openSUSE 12.3, KDE 4.11.1 & kernel 3.11.1-2 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 21/09/13 00:37, Anton Aylward wrote:

Basil Chupin said the following on 09/20/2013 10:10 AM:

...

...

network.service took about 22 seconds to become active.

Yes I gathered that from what I saw when booting 13.1 Beta.

The question, of course, is what exactly, and why, should be taking so much time to activate the network. I am not using the new Network Manager (as far as I know) and there is nothing special about my setup - a wired modem/router with 2 computers on the LAN.

That question becomes 'what does it depend on?'

It could also be 'what actually does 'network.service' mean? Does it just mean the Ethernet connection to the LAN? Or does it include the network SERVICES such as DNS/NAMED, any routing protocols and more?

On my server DNS takes a long time to start because, as I've written before, I have the huge table from http://pgl.yoyo.org/as/serverlist.php?hostformat=bindconfig&showintro=1&mimetype=plaintext

which takes a few tens of seconds to digest.

Sensibly, DHCP depends on having DNS up so that it can tell the DNS server about hosts that now have an IP address that wasn't in the original. Until DHCP is up no other hosts on the LAN get an IP address :-(

Until DNS is up the mail subsystem can't work.

Until DNS is up SpamAssassin can't work so fetchmail can't work.

And so it goes.

So the question becomes 'what does it depend on?'

What are your dependencies? Does the chart show them?

The answer to your last 2 questions is simple: I don't know - you'll have to educate me :-) . If I sent you the graph which I just generated perhaps you could tell me what it shows? The file is 427Kb big so I won't send it unless you OK it. BC -- Using openSUSE 12.3, KDE 4.11.1 & kernel 3.11.1-2 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 21/09/13 19:13, Andrey Borzenkov wrote:

� Sat, 21 Sep 2013 17:12:48 +1000 Basil Chupin �����:

...

On 21/09/13 00:37, Anton Aylward wrote:

...

Basil Chupin said the following on 09/20/2013 10:10 AM:

...

...

network.service took about 22 seconds to become active. Yes I gathered that from what I saw when booting 13.1 Beta.

The question, of course, is what exactly, and why, should be taking so much time to activate the network. I am not using the new Network Manager (as far as I know) and there is nothing special about my setup - a wired modem/router with 2 computers on the LAN. That question becomes 'what does it depend on?'

It could also be 'what actually does 'network.service' mean? Does it just mean the Ethernet connection to the LAN? Or does it include the network SERVICES such as DNS/NAMED, any routing protocols and more?

On my server DNS takes a long time to start because, as I've written before, I have the huge table from http://pgl.yoyo.org/as/serverlist.php?hostformat=bindconfig&showintro=1&mimetype=plaintext

which takes a few tens of seconds to digest.

Sensibly, DHCP depends on having DNS up so that it can tell the DNS server about hosts that now have an IP address that wasn't in the original. Until DHCP is up no other hosts on the LAN get an IP address :-(

Until DNS is up the mail subsystem can't work.

Until DNS is up SpamAssassin can't work so fetchmail can't work.

And so it goes.

So the question becomes 'what does it depend on?'

What are your dependencies? Does the chart show them? The answer to your last 2 questions is simple: I don't know - you'll have to educate me :-) .

If I sent you the graph which I just generated perhaps you could tell me what it shows? The file is 427Kb big so I won't send it unless you OK it.

It is not the question of dependencies. You have single service that takes this time to start.

The first obvious question - are you using ifup or NetworkManager.

ifup. BC -- Using openSUSE 12.3, KDE 4.11.1 & kernel 3.11.1-2 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 21/09/13 23:18, Andrey Borzenkov wrote:

� Sat, 21 Sep 2013 22:53:10 +1000 Basil Chupin �����:

...

...

It is not the question of dependencies. You have single service that takes this time to start.

The first obvious question - are you using ifup or NetworkManager. ifup.

OK, then you can simply test what happens if you manually start it.

export SYSTEMD_NO_WRAP=1 /etc/init.d/network stop /etc/init.d/network start

Does it take the same time?

Yep, perhaps a second longer as well. BC -- Using openSUSE 12.3, KDE 4.11.1 & kernel 3.11.1-3 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 22/09/13 05:35, Andrey Borzenkov wrote:

В Sun, 22 Sep 2013 00:11:03 +1000 Basil Chupin пишет:

...

On 21/09/13 23:18, Andrey Borzenkov wrote:

...

� Sat, 21 Sep 2013 22:53:10 +1000 Basil Chupin �����:

...

...

It is not the question of dependencies. You have single service that takes this time to start.

The first obvious question - are you using ifup or NetworkManager. ifup.

OK, then you can simply test what happens if you manually start it.

export SYSTEMD_NO_WRAP=1 /etc/init.d/network stop /etc/init.d/network start

Does it take the same time? Yep, perhaps a second longer as well.

OK. Check "journalctl -u network.service". It gives you output of scripts run when networks starts with time stamps. This could provide enough hints what step takes the most time.

If not, you can stick "set -x" on top of /etc/init.d/network and look where it stalls.

Here is the output of 'journalctl': -- Logs begin at Mon, 2013-09-23 00:01:38 EST, end at Mon, 2013-09-23 13:15:01 EST. -- Sep 23 00:01:58 linux-67gf.site network[576]: Setting up network interfaces: Sep 23 00:01:59 linux-67gf.site network[576]: lo Sep 23 00:01:59 linux-67gf.site network[576]: lo IP address: 127.0.0.1/8 Sep 23 00:01:59 linux-67gf.site network[576]: ..done eth0 device: Realtek Semiconductor Co., Ltd. RTL8111/8168 Sep 23 00:02:01 linux-67gf.site dhcpcd[1461]: eth0: dhcpcd 3.2.3 starting Sep 23 00:02:01 linux-67gf.site dhcpcd[1461]: eth0: hardware address = 90:f6:52:03:81:44 Sep 23 00:02:01 linux-67gf.site dhcpcd[1461]: eth0: broadcasting for a lease Sep 23 00:02:01 linux-67gf.site dhcpcd[1461]: eth0: offered 192.168.1.2 from 192.168.1.1 Sep 23 00:02:02 linux-67gf.site dhcpcd[1461]: eth0: checking 192.168.1.2 is available on attached networks Sep 23 00:02:03 linux-67gf.site dhcpcd[1461]: eth0: leased 192.168.1.2 for 86400 seconds Sep 23 00:02:03 linux-67gf.site dhcpcd[1461]: eth0: no renewal time supplied, assuming 43200 seconds Sep 23 00:02:03 linux-67gf.site dhcpcd[1461]: eth0: no rebind time supplied, assuming 75600 seconds Sep 23 00:02:03 linux-67gf.site dhcpcd[1461]: eth0: adding IP address 192.168.1.2/24 Sep 23 00:02:03 linux-67gf.site dhcpcd[1461]: eth0: adding default route via 192.168.1.1 metric 0 Sep 23 00:02:03 linux-67gf.site dhclient[1477]: send_packet6: Cannot assign requested address Sep 23 00:02:03 linux-67gf.site dhclient[1477]: dhc6: send_packet6() sent -1 of 58 bytes Sep 23 00:02:03 linux-67gf.site dhcpcd[1461]: eth0: Failed to lookup hostname via DNS: Name or service not known Sep 23 00:02:20 linux-67gf.site network[576]: eth0 Starting DHCP4+DHCP6 client. . . . . . . . Sep 23 00:02:20 linux-67gf.site network[576]: eth0 IP address: 192.168.1.2/24 Sep 23 00:02:20 linux-67gf.site network[576]: eth0 DHCP6 continues in background Sep 23 00:02:20 linux-67gf.site network[576]: ..doneSetting up service network . . . . . . . . . . . . ...done BC -- Using openSUSE 13.1, KDE 4.11.1 & kernel 3.11.1-3 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Rodney Baker wrote:

On Mon, 23 Sep 2013 13:19:10 Basil Chupin wrote:

...

On 22/09/13 05:35, Andrey Borzenkov wrote:

...

В Sun, 22 Sep 2013 00:11:03 +1000

Basil Chupin пишет:

...

On 21/09/13 23:18, Andrey Borzenkov wrote:

...

� Sat, 21 Sep 2013 22:53:10 +1000

Basil Chupin �����:

...

> It is not the question of dependencies. You have single service > that takes this time to start. > > The first obvious question - are you using ifup or > NetworkManager.

ifup.

OK, then you can simply test what happens if you manually start it.

export SYSTEMD_NO_WRAP=1 /etc/init.d/network stop /etc/init.d/network start

Does it take the same time?

Yep, perhaps a second longer as well.

OK. Check "journalctl -u network.service". It gives you output of scripts run when networks starts with time stamps. This could provide enough hints what step takes the most time.

If not, you can stick "set -x" on top of /etc/init.d/network and look where it stalls.

Here is the output of 'journalctl':

[...snip...]

...

Sep 23 00:02:03 linux-67gf.site dhcpcd[1461]: eth0: adding default route via 192.168.1.1 metric 0 Sep 23 00:02:03 linux-67gf.site dhclient[1477]: send_packet6: Cannot assign requested address Sep 23 00:02:03 linux-67gf.site dhclient[1477]: dhc6: send_packet6() sent -1 of 58 bytes Sep 23 00:02:03 linux-67gf.site dhcpcd[1461]: eth0: Failed to lookup hostname via DNS: Name or service not known Sep 23 00:02:20 linux-67gf.site network[576]: eth0 Starting DHCP4+DHCP6 client. . . . . . . . Sep 23 00:02:20 linux-67gf.site network[576]: eth0 IP address: 192.168.1.2/24 Sep 23 00:02:20 linux-67gf.site network[576]: eth0 DHCP6 continues in background Sep 23 00:02:20 linux-67gf.site network[576]: ..doneSetting up service network . . . . . . . . . . . . ...done

BC

The timeout is occurring because your DHCP client is looking for an IPv6 dhcp server and can't find one. This can also cause slow DNS response times because IP6 names are searched for before IP4 names.

If you're not using IPv6 locally, disable it in network settings (via YaST) and reboot.

Or just change the network config to only use dhcpv4. No reboot necessary, except to verify :-) -- Per Jessen, Zürich (12.6°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Basil Chupin wrote:

On 23/09/13 18:37, Per Jessen wrote:

...

Or just change the network config to only use dhcpv4. No reboot necessary, except to verify :-)

Sorry Per - changing this requires a reboot. YaST tells me so and I am not about to argue with YaST :-)

Funny, if I change this, it doesn't require a reboot. In fact, no network changes ever require a reboot. -- Per Jessen, Zürich (16.3°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Basil Chupin wrote:

On 23/09/13 21:18, Per Jessen wrote:

...

Basil Chupin wrote:

...

On 23/09/13 18:37, Per Jessen wrote:

...

Or just change the network config to only use dhcpv4. No reboot necessary, except to verify :-) Sorry Per - changing this requires a reboot. YaST tells me so and I am not about to argue with YaST :-) Funny, if I change this, it doesn't require a reboot. In fact, no network changes ever require a reboot.

Eh, I get a message in YaST as soon as I untick the ip6 box that doing this change will require a reboot. This in both 12.3 and 13.1.

Well, that's not the change I proposed - I proposed you go and change the network config for the interface to only use dhcpv4. Disabling ipv6 is a big gun for such a tiny issue, and probably will require a reboot, yes. -- Per Jessen, Zürich (19.0°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Basil Chupin wrote:

On 23/09/13 23:34, Per Jessen wrote:

...

Basil Chupin wrote:

...

On 23/09/13 21:18, Per Jessen wrote:

...

Basil Chupin wrote:

...

On 23/09/13 18:37, Per Jessen wrote:

...

Or just change the network config to only use dhcpv4. No reboot necessary, except to verify :-) Sorry Per - changing this requires a reboot. YaST tells me so and I am not about to argue with YaST :-) Funny, if I change this, it doesn't require a reboot. In fact, no network changes ever require a reboot. Eh, I get a message in YaST as soon as I untick the ip6 box that doing this change will require a reboot. This in both 12.3 and 13.1.

Well, that's not the change I proposed - I proposed you go and change the network config for the interface to only use dhcpv4.

You speak in foreign tongue - I know not what you are talking about :-) .

Where in the bowls of oS am I to find this mysterious "dhcpv4" to be able to do unspeakable things to it? :-)

Sorry - you go to Yast->Network devices - then edit the address assignment mode for the individual device(s). Usually you will have static, dhcpv4, dhcpv6 and 4+6. (all from memory, ymmv). -- Per Jessen, Zürich (18.9°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Basil Chupin [09-24-13 07:24]:

On 24/09/13 02:29, Per Jessen wrote: [...]

...

Sorry - you go to Yast->Network devices - then edit the address assignment mode for the individual device(s). Usually you will have static, dhcpv4, dhcpv6 and 4+6. (all from memory, ymmv).

Thanks for this but the water is too cold and too deep so I'll stay in the boat where it is safe :-) .

You can "stay in the boat" where you may *never* reach shore, but the described action does work as I have been using it for several years on my server machine(s), which are still on 11.2. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Basil Chupin wrote:

On 24/09/13 22:23, Patrick Shanahan wrote:

...

* Basil Chupin [09-24-13 07:24]:

...

On 24/09/13 02:29, Per Jessen wrote: [...]

...

Sorry - you go to Yast->Network devices - then edit the address assignment mode for the individual device(s). Usually you will have static, dhcpv4, dhcpv6 and 4+6. (all from memory, ymmv). Thanks for this but the water is too cold and too deep so I'll stay in the boat where it is safe :-) . You can "stay in the boat" where you may *never* reach shore, but the described action does work as I have been using it for several years on my server machine(s), which are still on 11.2.

That's nice.... for you :-) . But when one has never touched anything-networking telling one to "edit address assignment mode...." goes totally over the head.

Now, if someone posts a screenshot of YaST where such a change was done then one can start to understand what "address assignment mode....." means and where it is configured :-) .

I'd be happy to, but I only use the ncurses interface, and I expect you use the GUI? -- Per Jessen, Zürich (16.2°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, 25 Sep 2013 00:05:13 Basil Chupin wrote:

On 24/09/13 22:23, Patrick Shanahan wrote:

...

* Basil Chupin [09-24-13 07:24]:

...

On 24/09/13 02:29, Per Jessen wrote: [...]

...

...

Sorry - you go to Yast->Network devices - then edit the address assignment mode for the individual device(s). Usually you will have static, dhcpv4, dhcpv6 and 4+6. (all from memory, ymmv).

Thanks for this but the water is too cold and too deep so I'll stay in the boat where it is safe :-) .

You can "stay in the boat" where you may *never* reach shore, but the described action does work as I have been using it for several years on my server machine(s), which are still on 11.2.

That's nice.... for you :-) . But when one has never touched anything-networking telling one to "edit address assignment mode...." goes totally over the head.

Now, if someone posts a screenshot of YaST where such a change was done then one can start to understand what "address assignment mode....." means and where it is configured :-) .

BC

The suggestions that have been made operate on 2 different levels. My original suggestion (disable IPV6 system wide) disables IPV6 functionality at kernel level (as I understand it), hence the need for a reboot. Others have suggested modifying the dhcp protocol per-interface, which is easily achieved via Yast's Network Settings dialog (the same dialog where you find the checkbox to disable IPV6 systemwide but on a different tab) or by manually editing /etc/sysconfig/network/ifcfg-. If you want to understand what is going on under the hood, do what a real sysadmin would do and hack the config files using vi/emacs/nano/<name-your- preferred-text-editor> (after making a backup first, of course). ;-) On my oS 12.3 box the relevant file would be /etc/sysconfig/network/ifcfg-eth0 but if your system is using the new interface naming standard (en0p0 or whatever)...well, you can figure it out. [Note: these files are writable only by root]. Learning to administer your box via the CLI is really helpful. You never know when you might need to know how to rescue a broken system. It's good to practice on a non-critical (non-"production") box though if you can spare one, because its really easy to break things too (but easy to fix if you remember - or note - how it was before you changed it). :-) RB. -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au ============================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

James Knott said the following on 09/23/2013 07:56 AM:

BTW, in IPv6, DHCP is generally used for stuff other than getting an address. It can be used for pointing to DNS and other servers.

Isn't that the case for IPV4 as well? It seems so on my systems. -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 23/09/13 17:39, Rodney Baker wrote:

On Mon, 23 Sep 2013 13:19:10 Basil Chupin wrote:

...

On 22/09/13 05:35, Andrey Borzenkov wrote:

...

В Sun, 22 Sep 2013 00:11:03 +1000

...

On 21/09/13 23:18, Andrey Borzenkov wrote:

...

� Sat, 21 Sep 2013 22:53:10 +1000

Basil Chupin �����:

...

> It is not the question of dependencies. You have single service that > takes this time to start. > > The first obvious question - are you using ifup or NetworkManager. ifup. OK, then you can simply test what happens if you manually start it.

export SYSTEMD_NO_WRAP=1 /etc/init.d/network stop /etc/init.d/network start

Does it take the same time? Yep, perhaps a second longer as well. OK. Check "journalctl -u network.service". It gives you output of

Basil Chupin пишет: scripts run when networks starts with time stamps. This could provide enough hints what step takes the most time.

If not, you can stick "set -x" on top of /etc/init.d/network and look where it stalls. Here is the output of 'journalctl':

[...snip...]

...

Sep 23 00:02:03 linux-67gf.site dhcpcd[1461]: eth0: adding default route via 192.168.1.1 metric 0 Sep 23 00:02:03 linux-67gf.site dhclient[1477]: send_packet6: Cannot assign requested address Sep 23 00:02:03 linux-67gf.site dhclient[1477]: dhc6: send_packet6() sent -1 of 58 bytes Sep 23 00:02:03 linux-67gf.site dhcpcd[1461]: eth0: Failed to lookup hostname via DNS: Name or service not known Sep 23 00:02:20 linux-67gf.site network[576]: eth0 Starting DHCP4+DHCP6 client. . . . . . . . Sep 23 00:02:20 linux-67gf.site network[576]: eth0 IP address: 192.168.1.2/24 Sep 23 00:02:20 linux-67gf.site network[576]: eth0 DHCP6 continues in background Sep 23 00:02:20 linux-67gf.site network[576]: ..doneSetting up service network . . . . . . . . . . . . ...done

BC The timeout is occurring because your DHCP client is looking for an IPv6 dhcp server and can't find one. This can also cause slow DNS response times because IP6 names are searched for before IP4 names.

If you're not using IPv6 locally, disable it in network settings (via YaST) and reboot.

Thanks Rodney. Deselection of check for ipv6 done. Now to see how the speed improves. BC -- Using openSUSE 13.1, KDE 4.11.1 & kernel 3.11.1-3 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

В Mon, 23 Sep 2013 20:24:23 +1000 Basil Chupin пишет:

On 23/09/13 20:04, Basil Chupin wrote:

...

On 23/09/13 17:39, Rodney Baker wrote:

[pruned]

...

...

The timeout is occurring because your DHCP client is looking for an IPv6 dhcp server and can't find one. This can also cause slow DNS response times because IP6 names are searched for before IP4 names.

If you're not using IPv6 locally, disable it in network settings (via YaST) and reboot.

Thanks Rodney. Deselection of check for ipv6 done. Now to see how the speed improves.

BC

Well that has made things a LOT better - a small delay of under 5 seconds.

BUT, I just this on the 13.1 Beta and this "fix" had no affect where the 22 second delay is at the kernel message, "Starting Ifup manager network interface enp6s0". The output from journalctl for this is:

In 13.1 every interface is started as own service (if you use ifup) so you need to use journalctl -u network@enp6s0.service

-- Logs begin at Tue 2013-09-24 06:12:32 EST, end at Mon 2013-09-23 20:15:40 EST. -- Sep 24 06:12:40 linux-njij systemd[1]: Starting LSB: Configure network interfaces and set up routing... Sep 24 06:12:40 linux-njij network[621]: Setting up network interfaces: Sep 24 06:12:41 linux-njij network[621]: lo Sep 24 06:12:41 linux-njij network[621]: lo IP address: 127.0.0.1/8 Sep 24 06:13:04 linux-njij network[621]: ..done..doneSetting up service network . . . . . . . . . . . . ...done Sep 24 06:13:04 linux-njij systemd[1]: Started LSB: Configure network interfaces and set up routing.

Now I know that this is for 13.1 and not for a released version of oS but I think it still can be mentioned here and not in Factory.

BC

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 24/09/13 00:43, Basil Chupin wrote:

On 24/09/13 00:00, Andrey Borzenkov wrote:

...

� Mon, 23 Sep 2013 20:24:23 +1000 Basil Chupin �����:

...

On 23/09/13 20:04, Basil Chupin wrote:

...

On 23/09/13 17:39, Rodney Baker wrote: [pruned]

...

...

The timeout is occurring because your DHCP client is looking for an IPv6 dhcp server and can't find one. This can also cause slow DNS response times because IP6 names are searched for before IP4 names.

If you're not using IPv6 locally, disable it in network settings (via YaST) and reboot. Thanks Rodney. Deselection of check for ipv6 done. Now to see how the speed improves.

BC Well that has made things a LOT better - a small delay of under 5 seconds.

BUT, I just this on the 13.1 Beta and this "fix" had no affect where the 22 second delay is at the kernel message, "Starting Ifup manager network interface enp6s0". The output from journalctl for this is:

In 13.1 every interface is started as own service (if you use ifup) so you need to use

journalctl -u network@enp6s0.service

OK I'll try this in a minute (or so).

And the output from this is: -- Logs begin at Tue 2013-09-24 10:52:22 EST, end at Tue 2013-09-24 00:54:24 EST. -- Sep 24 10:52:29 linux-njij systemd[1]: Starting ifup managed network interface enp6s0... Sep 24 10:52:29 linux-njij ifup[1025]: enp6s0 device: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 01) Sep 24 10:52:32 linux-njij dhcpcd[1510]: enp6s0: dhcpcd 3.2.3 starting Sep 24 10:52:32 linux-njij dhcpcd[1510]: enp6s0: hardware address = 90:f6:52:03:81:44 Sep 24 10:52:32 linux-njij dhcpcd[1510]: enp6s0: broadcasting for a lease Sep 24 10:52:32 linux-njij dhcpcd[1510]: enp6s0: offered 192.168.1.2 from 192.168.1.1 Sep 24 10:52:32 linux-njij dhcpcd[1510]: enp6s0: checking 192.168.1.2 is available on attached networks Sep 24 10:52:33 linux-njij dhcpcd[1510]: enp6s0: leased 192.168.1.2 for 86400 seconds Sep 24 10:52:33 linux-njij dhcpcd[1510]: enp6s0: no renewal time supplied, assuming 43200 seconds Sep 24 10:52:33 linux-njij dhcpcd[1510]: enp6s0: no rebind time supplied, assuming 75600 seconds Sep 24 10:52:33 linux-njij dhcpcd[1510]: enp6s0: adding IP address 192.168.1.2/24 Sep 24 10:52:33 linux-njij dhcpcd[1510]: enp6s0: adding default route via 192.168.1.1 metric 0 Sep 24 10:52:35 linux-njij dhcpcd[1510]: enp6s0: Failed to lookup hostname via DNS: Name or service not known Sep 24 10:52:52 linux-njij ifup[1025]: Starting DHCP4+DHCP6 client on enp6s0. . . . . . . . Sep 24 10:52:52 linux-njij ifup[1025]: enp6s0 DHCP4 continues in background Sep 24 10:52:52 linux-njij ifup[1025]: enp6s0 DHCP6 continues in background Sep 24 10:52:52 linux-njij systemd[1]: Started ifup managed network interface enp6s0. Sep 24 10:52:54 linux-njij avahi-autoipd(enp6s0)[3557]: Found user 'avahi-autoipd' (UID 487) and group 'avahi-autoipd' (GID 485). Sep 24 10:52:54 linux-njij avahi-autoipd(enp6s0)[3557]: Successfully called chroot(). Sep 24 10:52:54 linux-njij avahi-autoipd(enp6s0)[3557]: Successfully dropped root privileges. Sep 24 10:52:54 linux-njij avahi-autoipd(enp6s0)[3557]: Starting with address 169.254.5.252 Sep 24 10:52:54 linux-njij avahi-autoipd(enp6s0)[3557]: Routable address already assigned, sleeping. BC -- Using openSUSE 13.1, KDE 4.11.1 & kernel 3.11.1-3 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

В Sat, 21 Sep 2013 09:40:11 +0200 Per Jessen пишет:

Anton Aylward wrote:

...

Basil Chupin said the following on 09/20/2013 10:10 AM:

...

...

network.service took about 22 seconds to become active.

Yes I gathered that from what I saw when booting 13.1 Beta.

The question, of course, is what exactly, and why, should be taking so much time to activate the network. I am not using the new Network Manager (as far as I know) and there is nothing special about my setup - a wired modem/router with 2 computers on the LAN.

That question becomes 'what does it depend on?'

It could also be 'what actually does 'network.service' mean? Does it just mean the Ethernet connection to the LAN? Or does it include the network SERVICES such as DNS/NAMED, any routing protocols and more?

afaik, network.service is the "old" sysvinit network startup, and only about the network interfaces.

No, if NetworkManager is selected, network.service becomes alias for NetworkManager.service -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hans de Faber said the following on 09/21/2013 08:22 AM:

...

...

No, if NetworkManager is selected, network.service becomes alias for NetworkManager.service

Sorry for interruption, Several months ago I had a similar problem. The cause of the problem was kmix. I replaced kmix by gmix and the problem is gone.

??? I'm under the impression that kmix is the KDE sound mixer. http://www.muktware.com/5792/kmix-now-stable I was under the impression that is not part of the boot sequences but rather part of the desktop. -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrey Borzenkov wrote:

В Sat, 21 Sep 2013 09:40:11 +0200 Per Jessen пишет:

...

Anton Aylward wrote:

...

Basil Chupin said the following on 09/20/2013 10:10 AM:

...

...

network.service took about 22 seconds to become active.

Yes I gathered that from what I saw when booting 13.1 Beta.

The question, of course, is what exactly, and why, should be taking so much time to activate the network. I am not using the new Network Manager (as far as I know) and there is nothing special about my setup - a wired modem/router with 2 computers on the LAN.

That question becomes 'what does it depend on?'

It could also be 'what actually does 'network.service' mean? Does it just mean the Ethernet connection to the LAN? Or does it include the network SERVICES such as DNS/NAMED, any routing protocols and more?

afaik, network.service is the "old" sysvinit network startup, and only about the network interfaces.

No, if NetworkManager is selected, network.service becomes alias for NetworkManager.service

Sorry, you're right. I was wearing my server-cap. -- Per Jessen, Zürich (18.2°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 21/09/13 02:02, Dylan wrote:

On 20/09/13 13:56, Basil Chupin wrote:

...

On 18/09/13 23:18, Andrey Borzenkov wrote:

...

Install systemd-analyze and look at graph that shows relative timing of different services. This will answer, what startup is waiting for.

Thanks for this, but I see no graph when I run systemd-analyze - even with the 'plot' option which you mention later. When I do run 'plot' all I see are pages and pages and pages of meaningless - to me - output.

Try: systemd-analyze -plot > systemd.svg

then open it in an app that can show an svg file... (reading the man page would make this obvious)

Thanks for this. I now have this graph but it doesn't mean much to me as I find it hard to interpret it - and even if I could I wouldn't be able to solve the delay as it's in the system as far as I know. BTW, Gimp was the app. which opened and displayed the *.svg file. BC -- Using openSUSE 12.3, KDE 4.11.1 & kernel 3.11.1-2 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 22/09/13 20:38, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Saturday, 2013-09-21 at 17:08 +1000, Basil Chupin wrote:

...

BTW, Gimp was the app. which opened and displayed the *.svg file.

You can use "display", or even libreoffice.

And of course, you can compress it for email :-)

Ah, thanks for this. Added to my "Little Black Book of Magical Tricks and Tips" :-) . BC -- Using openSUSE 13.1, KDE 4.11.1 & kernel 3.11.1-3 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 18/09/13 23:48, C wrote:

...

...when the boot process reaches the stage 'Starting Login Service'?

I have noticed this for quite some time but hadn't bothered about this until now.

When the system is booting there is a pause of 21.7 seconds when the kernel messages on the screen show 'Starting Login Service'. After this pause the login screen is reached in about 3 seconds.

Anybody know why there is this long pause, please?

I really don't remember when this started but if it is of any relevance this delay is present even in the just-upgraded kernel 3.11.1-2.

BC Do you have a drive or partition defined in the fstab or elsewhere

On Wed, Sep 18, 2013 at 3:05 PM, Basil Chupin wrote: that isn't accessible at boot?

Nope, but I do have partitions which contain other systems. I found that a similar thing is occurring in 13.1 Mx and Beta and from what shows up on the screen I can see that the hold-up appears to be in configuring/establishing the networking system.

I've encountered this when I had my NAS drive set to be mounted via NFS. If the drive was off at boot, the boot sequence would pause for about 20 seconds waiting for it to respond. Once it hit the timeout, it would continue, sending the mount task to the background.

This was on 12.1 I think... it's been a while since I've encountered this. All I can really think of at the moment.

C.

BC -- Using openSUSE 12.3, KDE 4.11.1 & kernel 3.11.1-2 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org