You are not logged in.
With the upgrade to Jessie on my Laptop I decided to deinstall the NetManager completely and setup an simple network configuration. I've also deinstalled the wireless drivers and blacklisted the related kernel modules.
The laptop is directly hooked up to my router. And the configuration works, the DHCP address is fetched from the router sucessfully.
This is my /etc/networking/interfaces currently :
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
I also use resolve resolveconf, updates are enabled and seem to work,
This is my /etc/dhcp/dhclient.conf currently :
option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;
#send host-name "andare.fugue.com";
send host-name = gethostname();
#send dhcp-client-identifier 1:0:a0:24:ab:fb:9c;
#send dhcp-lease-time 3600;
#supersede domain-name "fugue.com home.vix.com";
#prepend domain-name-servers 127.0.0.1;
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, domain-search, host-name,
netbios-name-servers, netbios-scope, interface-mtu,
rfc3442-classless-static-routes, ntp-servers;
# dhcp6.name-servers, dhcp6.domain-search,
Which is the preset, except that I've commented out the dhcp6.name-servers and dhcp6.domain-search.
But at this point I have to mention that grub has loaded sucessfully and the images are mounted an message appears "LSB is configuring" "no time-out 10s" "9s" "8s"
Thus I suspected timeout settings or something similar. Which didn't resolved the issue.
This is the output of systemd-analyze blame currently.
friese@friesenbang:~$ systemd-analyze blame
9.873s networking.service
932ms exim4.service
718ms systemd-modules-load.service
665ms systemd-logind.service
...
seems that I need some guidance here...
Last edited by 1093_3511 (2015-01-02 21:30:00)
Offline
just as a further detail:
An reinstallation of the Network-Manager didn't resolved the issue
friese@friesenbang:~$ systemd-analyze blame
10.412s networking.service
1.295s NetworkManager.service
1.089s exim4.service
738ms systemd-logind.service
724ms systemd-modules-load.service
525ms lm-sensors.service
...
Last edited by 1093_3511 (2015-01-02 22:05:23)
Offline
I got results similar to these with systemd-analyze blame. The other top offender was samba which just got purged. No windows machines running in this house anyway . The third worst offender for me was early-readahead, which is a penalty I am willing to pay in favor of improved load performace later. Strangely networking.service only took 71ms, compared to the whopping 22.787s for NetworkManager.service.
Offline
22.787s is quiet a lot. But I also don't know which network connectivity needs to be established in your case.
In my case it's just the built in ethernet device which should get it's IP from my router. Nothing else. And I don't have a clue why this takes >5secs.
I also tried some other ways to achieve an faster boot time. ( did I mention my OCD already ? 8o ) And found these scripts which are disabling some of the unwanted services launched by debian. Actually, also with the removed if-{up,down}: scripts I'm down to 6.354s for the networking.service. But the boot time seems to vary a lot.
Offline
Anyway,
I just realized that avahi-daemon was still running. I've disabled it via
friese@friesenbang:~$ sudo systemctl disable avahi-daemon
And I have adopted these dhcpclient settings from calomel.org, but without superseeding and prepending.
## Calomel.org dhclient.conf DHCP Client Configuration
backoff-cutoff 2;
initial-interval 1;
link-timeout 10;
reboot 0;
retry 10;
select-timeout 0;
timeout 30;
interface "eth0"
{
request subnet-mask,
broadcast-address,
routers,
domain-name,
domain-name-servers,
host-name;
require routers,
subnet-mask,
domain-name-servers;
}
Most notably - the reboot 0 parameter should call the INIT-REBOOT state, trying to reestablish the last known dhcp-lease.
In general, this resulted in :
friese@friesenbang:~$ systemd-analyze blame
6.632s networking.service
...
274ms network-manager.service <== Why is service still present, even when the networkmanager is removed / purged ?
...
130ms resolvconf.service
I don't have an clue if this could be optimized further. But up so far I've just learned that the services in debian are quite nasty to handle...
Offline
Anyway,
I just realized that avahi-daemon was still running. I've disabled it via
friese@friesenbang:~$ sudo systemctl disable avahi-daemon
And I have adopted these dhcpclient settings from calomel.org, but without superseeding and prepending.
## Calomel.org dhclient.conf DHCP Client Configuration backoff-cutoff 2; initial-interval 1; link-timeout 10; reboot 0; retry 10; select-timeout 0; timeout 30; interface "eth0" { request subnet-mask, broadcast-address, routers, domain-name, domain-name-servers, host-name; require routers, subnet-mask, domain-name-servers; }
Most notably - the reboot 0 parameter should call the INIT-REBOOT state, trying to reestablish the last known dhcp-lease.
In general, this resulted in :
friese@friesenbang:~$ systemd-analyze blame 6.632s networking.service ... 274ms network-manager.service <== Why is service still present, even when the networkmanager is removed / purged ? ... 130ms resolvconf.service
I don't have an clue if this could be optimized further. But up so far I've just learned that the services in debian are quite nasty to handle...
if you mask the service does it break anything?
sudo systemctl mask network-manager.service
Coincidentally, I think a large part of my problem was the crappy wireless router built into my adsl modem. I just put it into bridge mode and setup my netgear router and things seem a ton snappier. Gonna reboot and see if that had anything to do with my slow networking starts.
Offline
I was correct. Now Network manager more closely matches your stats prior to removing it:
10.227s NetworkManager.service
Offline
Just leaving a comment here wrt to DHCP request and boot time. It seems that systemd and networkmanager and not to blame here:
I used several inits (openrc, sysv, systemd) with and without nm, and the boot time was always largely influenced (slowed down) by DHCP request. It often waits for DHCP offers and 7-15 seconds seems quite 'normal' here. You might try to assign a fixed IP for a test boot and check the blame again.
Sweaty lads picking up the soap | I love the new "Ignore user" button
Offline
thanks for that info. Fixed ip brings network manager stats down to:
12.411s NetworkManager.service
Offline
You might try to assign a fixed IP for a test boot and check the blame again.
Well ... for the record. Just minor changes, I've disabled the network manager (another time .. ) and removed the loopback.
With these settings in /etc/network/interfaces
auto eth0
iface eth0 inet dhcp
friese@friesenbang:~$ systemd-analyze blame
5.853s networking.service
...
376ms pppd-dns.service <=== wasn't active prior to disableing the network-manager.service I think
...
118ms resolvconf.service
With a static ip in /etc/network/interfaces
auto eth0
iface eth0 inet static
address 192.168.1.22
netmask 255.255.255.0
gateway 192.168.1.1
friese@friesenbang:~$ systemd-analyze blame
1.376s networking.service
...
384ms pppd-dns.service
...
121ms resolvconf.service
At least in theory. Actually the system has no internet connection then...
Last edited by 1093_3511 (2015-01-03 03:33:06)
Offline
last but not least ... had to enable the dns-nameserver used by my router to get it working again.
auto eth0
iface eth0 inet static
address 192.168.1.81
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameserver 195.185.185.195
dns-nameserver 62.26.26.62
drum roll 8o
8.688s networking.service
...
372ms pppd-dns.service
...
118ms resolvconf.service
That's enough tinkering with my network setup. Also the static IP isn't faster. Also routing between my primary and #! doesn't work anymore. Thus I'm going back to the dhcp method... and hope that it will perform mostly between 5 - 10 secs.
Offline
So *Ahem* how often do you actually boot your computer? Suspend is a magical ability. 8o
/question from an arch user 8o
Last edited by Alad (2015-01-03 04:33:17)
Round off #! Waldorf Part I/II
Scripts | Run new applications | Thunar 1.6.3 | Default soundcard | Settings daemon
On mixing sources :8
Offline
Good question, indeed.
I'm playing around with my old hardware here. I'm just exploring the possibilities of what might be achievable on this old machine (Intel Pentium M Banias 1.3 GHz).
Offline
I had this problem with network-manager and systemd. I suppose it may have been a result of dodgy configuration, but my solution was to replace NM with connman, which is lightning-fast on boot and more reliable at reestablishing connection on wakeup.
Offline
^ I agree, replacing network-manager (with nothing, for example) is actually the most elegant way Simply run 'ceni' (eg. from here: http://mirror.lug.udel.edu/pub/siductio … 2_all.deb) and set up the network connection once. Ceni writes the /etc/network/interfaces entry. For all additional shit like VPNs there are similar scripts (like vpnc, in the repos). Shaves also a few MB RAM off
Sweaty lads picking up the soap | I love the new "Ignore user" button
Offline
I had this problem with network-manager and systemd. I suppose it may have been a result of dodgy configuration, but my solution was to replace NM with connman, which is lightning-fast on boot and more reliable at reestablishing connection on wakeup.
I'm totally satisfied with my current semi-manual configuration which relies on the ordinary networking service and resolvconf.
Recently I just had problems with my jackd connection between my client (#!) and server (MacOSX Yosemite) after an upgrade to the latest liquorix kernel. Currently im using an older revision (3.17_2 or so) which didn't has that issue.
Anyway, might be interessting to see your systemd-analyse blame output 8o
Offline
Copyright © 2012 CrunchBang Linux.
Proudly powered by Debian. Hosted by Linode.
Debian is a registered trademark of Software in the Public Interest, Inc.
Server: acrobat