You are not logged in.
This is in the newbie corner as I'm baffled by this and not even well enough informed to know where to gather information.
Very recently the behavior of dhcpcd changed. Previously, it would daemonize and remain in the background: it would show up in pstree and pgrep output. Now, it still works perfectly, but after it runs, it seems to fully exit without leaving a daemon process - or at least not one that shows up in pstree or pgrep output.
There is no actual problem here, but I'd like to learn about this change if anyone can enlighten me.
Last edited by Trilby (2015-04-25 16:21:29)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
I believe it's because systemd-networkd is acting as the dhcp client. In fact, I just removed dhcpcd from my system and everything stilll works.
Offline
I've been using the stock dhcpcd (with [testing] repos enabled) and I see no change.
Anything interesting in the logs or in systemd's journal? What's the output of
pacman -Q dhcpcd
systemctl status dhcpcd
Offline
I do not (intentionally) use systemd-networkd, and it is not running.
$ pacman -Q dhcpcd
dhcpcd 6.8.1-1
$ systemctl status dhcpcd
● dhcpcd.service - dhcpcd on all interfaces
Loaded: loaded (/usr/lib/systemd/system/dhcpcd.service; disabled; vendor preset: disabled)
Active: inactive (dead)
I don't use the dhcpcd service - I just envoke it manually. I'll double check in a moment, but I don't believe I have a connection until I run dhcpcd on my wireless interface (after wpa_supplicant).
----
So it seems I do need to explicitly run dhcpcd, but I can kill it after it connects, and my connection remains:
# no connection and no active services at start
$ sudo wpa_supplicant -B -i wls1 -c /usr/share/swifer/NETGEAR10
Successfully initialized wpa_supplicant
$ pgrep dhcpcd
$ ping google.com
ping: unknown host google.com
$ sudo dhcpcd wls1
DUID 00:01:00:01:1a:3c:f0:eb:00:26:c6:c9:40:0c
wls1: IAID 6a:76:c9:30
wls1: soliciting an IPv6 router
wls1: rebinding lease of 192.168.1.76
wls1: leased 192.168.1.76 for 86400 seconds
wls1: changing route to 192.168.1.0/24
wls1: changing default route via 192.168.1.1
forked to background, child pid 806
$ ping google.com
PING google.com (74.125.21.101) 56(84) bytes of data.
64 bytes from yv-in-f101.1e100.net (74.125.21.101): icmp_seq=1 ttl=36 time=46.3 ms
^C
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 46.315/46.315/46.315/0.000 ms
$ pgrep dhcpcd
806
$ sudo killall dhcpcd
$ pgrep dhcpcd
$ ping google.com
PING google.com (74.125.21.101) 56(84) bytes of data.
64 bytes from yv-in-f101.1e100.net (74.125.21.101): icmp_seq=1 ttl=36 time=128 ms
64 bytes from yv-in-f101.1e100.net (74.125.21.101): icmp_seq=2 ttl=36 time=100 ms
64 bytes from yv-in-f101.1e100.net (74.125.21.101): icmp_seq=3 ttl=36 time=53.0 ms
64 bytes from yv-in-f101.1e100.net (74.125.21.101): icmp_seq=4 ttl=36 time=47.0 ms
q64 bytes from yv-in-f101.1e100.net (74.125.21.101): icmp_seq=5 ttl=36 time=48.3 ms
^C
--- google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4007ms
rtt min/avg/max/mdev = 47.073/75.519/128.444/33.126 ms
While this time it seems I had to kill dhcpcd myself. But just the same, it is no longer running, yet my connection stays up.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
While this time it seems I had to kill dhcpcd myself. But just the same, it is no longer running, yet my connection stays up.
Clients may solicit an IP address (IP) from a DHCP server when they need one. The DHCP server then offers the "lease" of an IP address to the client, which the client is free to request or ignore. If the client requests it and the server acknowledges it, then the client is permitted to use that IP address for the "lease time" specified by the server. At some point before the lease expires, the client must re-request the same IP address if it wishes to continue to use it.
I guess that after killing dhcpcd you can still use your IP address until the lease expires. After all it's not dhcpcd but the kernel that provides the network functionality.
Offline
Thanks that may be it. But I've had relatively long uptimes without needing to get a new lease. I suppose now I just need to track down why dhcpcd is exiting - it previously would continue running in the background indefinitely.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline