On Fri, 2016-04-01 at 11:22 -0400, Anton Aylward wrote:
On 04/01/2016 10:45 AM, Carlos E. R. wrote:
Why it doesn't get an address is a different issue. But whatever network setup daemon you use, it has to wait till it gets one. And if it is the system connection, the machine doesn't boot, or waits for as long as the timeout is.
There's a systemd tool, systemd-analyze Try systemd-analyze critical-chain
and look for the line about network service. The @ number tells you when it started, how long from boot. The + number tells you how long it took.
Ahh, thanks muchly :) I'm not sure I understand it entirely so here it is for expert eyes: The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character. graphical.target @40.063s ââmulti-user.target @40.063s ââcron.service @40.063s ââpostfix.service @39.764s +298ms ââtime-sync.target @39.764s âântpd.service @39.619s +145ms âânetwork.target @39.606s ââwicked.service @21.637s +17.967s ââwickedd-nanny.service @21.633s +3ms ââwickedd.service @21.629s +3ms ââwickedd-dhcp4.service @21.622s +5ms ââSuSEfirewall2_init.service @9.607s +12.013s ââbasic.target @8.062s ââtimers.target @8.062s ââsystemd-tmpfiles-clean.timer @8.062s ââsysinit.target @8.062s ââapparmor.service @7.382s +679ms ââsystemd-tmpfiles-setup.service @7.271s +110ms ââlocal-fs.target @6.936s ââhome.mount @6.486s +448ms ââsystemd-fsck@dev-disk-by \x2duuid-8b409a8d\x2d81a2\x2d414c\x2d87ba\x2da0d74d61b189.service @4.976s +1.509s ââdev-disk-by \x2duuid-8b409a8d\x2d81a2\x2d414c\x2d87ba\x2da0d74d61b189.device @4.975s Apologies for the gobbledygook. The file displays correctly on the source machine (with tree lines) but not on the machine with the mail client. The file is binary identical on both machines. Both machines use utf-8. It's not the mail client 'cos it doesn't display properly in a terminal either. Missing font? (stupid display format for a basic system tool if it depends on a loadable font!) Anyway, it looks like wicked.service, SuSEfirewall2_init.service, and dev-disk-by\x2duuid* are the culprits in some way. wicked.service is perhaps only guilty by association? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org