SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
The recently applied patch for dhcpcd did not solve the problem.
Between 9.4.0 and the current development tree, there are at least 10 or 12 patches applied.
I am currently discussing with R. Marples to find a solution
On the other hand, he confirmed me that the patch series will soon be released in a 9.4.1 version
Code:
[...] as that will be released as dhcpcd-9.4.1 "soon"
After that, I think we can deal with the zombie processes until the NM patch is merged in the stable tree
Should I mark this one as solved, or would that be too soon?
It's up to you ;-)
Since it's not really resolved, I think it's better to leave it open.
I will continue to communicate the evolutions here in any case
Roy is working on it
Code:
If you can test the dhcpcd-9 branch (which currently builds as version 9.4.0 still) it will hopefully work for you.
Can you test this please?
The latest NM patch provided by Mr. Volkderding solves the "zombie" issue. :-)
Nice !
Code:
n/NetworkManager-1.32.10-x86_64-4.txz: Rebuilt.
Patched to shut down dhcpcd gracefully, and restored dhcpcd as the default
client when using NetworkManager on Slackware. In this case I'll swim
upstream if it means better security. Who knows what your DHCP server might
attempt when it comes to public WiFi? :-)
Thanks to Roy Marples and marav.
After the last NM patch & our dhcpcd v9.4.0 (but this is the same with the dev branch dhcpcd-9)
previous dhcpcd processes are not killed, after NM restart
Distribution: Slackware64 {15.0,-current}, FreeBSD, stuff on QEMU
Posts: 447
Original Poster
Rep:
Quote:
Originally Posted by marav
After the last NM patch & our dhcpcd v9.4.0 (but this is the same with the dev branch dhcpcd-9)
previous dhcpcd processes are not killed, after NM restart
I thought I might be able to cherry-pick that patch on top of the dhcpcd-9 branch, but that's when I noticed that it just is a correction of the most notable change in master, i.e., process management. I guess that, to find the original issue, a better approach might be to revert to a previous version of NetworkManager that works with older, working versions of dhcpcd, and then see if the bug occurs with the dhcpcd-9 branch. If so, then we can actually bisect between dhcpcd-9.4.0 and older versions to find where the bug was introduced, instead of what I did, i.e., bisecting to find where it was resolved. Don't know whether I'll find time for that, but just in case: where was that cumulative slackware tree again?
I thought I might be able to cherry-pick that patch on top of the dhcpcd-9 branch, but that's when I noticed that it just is a correction of the most notable change in master, i.e., process management. I guess that, to find the original issue, a better approach might be to revert to a previous version of NetworkManager that works with older, working versions of dhcpcd, and then see if the bug occurs with the dhcpcd-9 branch. If so, then we can actually bisect between dhcpcd-9.4.0 and older versions to find where the bug was introduced, instead of what I did, i.e., bisecting to find where it was resolved. Don't know whether I'll find time for that, but just in case: where was that cumulative slackware tree again?
But ...
during my discussion with Roy Marples, he said :
Code:
OK, so the only difference between dhcpcd-9 branch and master is process management.
If you can test the dhcpcd-9 branch (which currently builds as version 9.4.0 still) it will hopefully work for you.
Can you test this please?
and after my tests :
Code:
Hmmmmmmm. And yet it works with the master branch of dhcpcd? I really don't understand why.
@marav I think I found something. However, now I'm left without default route or ip4 nameserver. Anyway.
I reverted to NetworkManager-1.28 and bisected from dhcpcd-9.3.0 to dhcpcd-9.4.0:
Code:
git bisect start
# good: [e2b4e65aa0730c5e8d46c0a5d9fa11b9818520a6] Release dhcpcd-9.3.0
git bisect good e2b4e65aa0730c5e8d46c0a5d9fa11b9818520a6
# bad: [dbb8e334c9feb222352538f7d078c07a7ba2001d] Release dhcpcd-9.4.0
git bisect bad dbb8e334c9feb222352538f7d078c07a7ba2001d
# good: [e9dfc2416bc5ff97166905cbb69e71dd2be6411a] Add --noconfigure option
git bisect good e9dfc2416bc5ff97166905cbb69e71dd2be6411a
# bad: [7c08f3777a69c69e87a149bb35681ce2ed2f0490] Linux: Fix privsep build by including sys/termios.h for all platforms
git bisect bad 7c08f3777a69c69e87a149bb35681ce2ed2f0490
# bad: [f8771a152f6e6fb2ac04027c22712a9ac12a606f] DHCP6: Fix segfault introduced in dhcpcd-9.3.3
git bisect bad f8771a152f6e6fb2ac04027c22712a9ac12a606f
# bad: [12a91777bd8126056518c8cc9edeb933f451afa8] privsep: Allow fcntl64 and fstat64 to fix ARM32 talking to the controller
git bisect bad 12a91777bd8126056518c8cc9edeb933f451afa8
# good: [040561d61e157e7fb371f1311f0cee3536dee0d2] control: create an unpriv socket for non master mode
git bisect good 040561d61e157e7fb371f1311f0cee3536dee0d2
# bad: [7ece8ef526fee000068d49ba8d1f8ae7d79e30de] route: Correct prior logic
git bisect bad 7ece8ef526fee000068d49ba8d1f8ae7d79e30de
# bad: [77260559dd3896fca1fc415ba57a01a71aedbc57] dhcpcd: Don't create launcher process if keeping in foreground
git bisect bad 77260559dd3896fca1fc415ba57a01a71aedbc57
# first bad commit: [77260559dd3896fca1fc415ba57a01a71aedbc57] dhcpcd: Don't create launcher process if keeping in foreground
... and I was able to revert that last commit on the dhcpcd-9 branch:
Code:
diff --git a/src/dhcpcd.c b/src/dhcpcd.c
index 6a4c9723..9b86aa5a 100644
--- a/src/dhcpcd.c
+++ b/src/dhcpcd.c
@@ -2283,9 +2283,6 @@ printpidfile:
logwarn("freopen stdin");
#if defined(USE_SIGNALS) && !defined(THERE_IS_NO_FORK)
- if (!(ctx.options & DHCPCD_DAEMONISE))
- goto start_manager;
-
if (xsocketpair(AF_UNIX, SOCK_DGRAM | SOCK_CXNB, 0, fork_fd) == -1 ||
(ctx.stderr_valid &&
xsocketpair(AF_UNIX, SOCK_DGRAM | SOCK_CXNB, 0, stderr_fd) == -1))
@@ -2376,9 +2373,8 @@ printpidfile:
/* We have now forked, setsid, forked once more.
* From this point on, we are the controlling daemon. */
- logdebugx("spawned manager process on PID %d", getpid());
-start_manager:
ctx.options |= DHCPCD_STARTED;
+ logdebugx("spawned manager process on PID %d", getpid());
if ((pid = pidfile_lock(ctx.pidfile)) != 0) {
logerr("%s: pidfile_lock %d", __func__, pid);
#ifdef PRIVSEP
diff --git a/src/privsep.c b/src/privsep.c
index d574a2bc..7da3ce8d 100644
--- a/src/privsep.c
+++ b/src/privsep.c
@@ -172,13 +172,12 @@ ps_dropprivs(struct dhcpcd_ctx *ctx)
#endif
}
-#define DHC_NOCHKIO (DHCPCD_STARTED | DHCPCD_DAEMONISE)
/* Prohibit writing to files.
* Obviously this won't work if we are using a logfile
* or redirecting stderr to a file. */
- if ((ctx->options & DHC_NOCHKIO) == DHC_NOCHKIO ||
- (ctx->logfile == NULL &&
- (!ctx->stderr_valid || isatty(STDERR_FILENO) == 1)))
+ if (ctx->logfile == NULL &&
+ (ctx->options & DHCPCD_STARTED ||
+ !ctx->stderr_valid || isatty(STDERR_FILENO) == 1))
{
if (setrlimit(RLIMIT_FSIZE, &rzero) == -1)
logerr("setrlimit RLIMIT_FSIZE");
Now, after resume I don't get all those leftover dhcpcd processes. However, with that default route and nameserver issue, it's not much of a solution.
on this resume-network-upon-suspend saga, both, wifi or wired nm connections seem plague w/ instability upon resume at my end.
not all the time, but enough time to be inconvenient.
doing some charity work on some linux mint 20.2 laptops, they can also be plagued with network manager wired-network-disconnect upon resume. i don't know why.
at least, using rcinet1conf has no network-issues while resuming.
Quote:
Oct 10 09:05:08 ds NetworkManager[1028]: <info> [1633849508.4594] device (eth0): carrier: link connected
Oct 10 09:05:08 ds NetworkManager[1028]: <info> [1633849508.4597] device (eth0): state change: unavailable -> disconnected (reason 'carrier-changed', sys-iface-state: 'managed')
Oct 10 09:05:08 ds NetworkManager[1028]: <info> [1633849508.4610] policy: auto-activating connection 'Wired connection 1' (12ffee55ce-ab22-2eff-e124-219ad4aebb12)
Oct 10 09:05:08 ds NetworkManager[1028]: <info> [1633849508.4616] device (eth0): Activation: starting connection 'Wired connection 1' (12ffee55ce-ab22-2eff-e124-219ad4aebb12)
Oct 10 09:05:08 ds NetworkManager[1028]: <info> [1633849508.4617] device (eth0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Oct 10 09:05:08 ds NetworkManager[1028]: <info> [1633849508.4623] manager: NetworkManager state is now CONNECTING
Oct 10 09:05:08 ds NetworkManager[1028]: <info> [1633849508.4625] device (eth0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Oct 10 09:05:08 ds NetworkManager[1028]: <info> [1633849508.4630] device (eth0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Oct 10 09:05:08 ds NetworkManager[1028]: <info> [1633849508.4633] dhcp4 (eth0): activation: beginning transaction (timeout in 45 seconds)
Oct 10 09:05:08 ds NetworkManager[1028]: <info> [1633849508.4653] dhcp4 (eth0): dhcpcd started with pid 7570
Oct 10 09:05:08 ds dhcpcd[7570]: dhcpcd-9.4.0 starting
Oct 10 09:05:08 ds dhcpcd[7571]: DUID alongnumber
Oct 10 09:05:08 ds dhcpcd[7571]: eth0: IAID anotherlongnumber
Oct 10 09:05:09 ds dhcpcd[7571]: eth0: rebinding lease of 192.168.1.32 Oct 10 09:05:14 ds NetworkManager[1028]: <info> [1633849514.1043] dhcp4 (eth0): state changed unknown -> expire Oct 10 09:05:14 ds dhcpcd[7571]: eth0: soliciting a DHCP lease
Oct 10 09:05:48 ds acpid: client 1118[0:0] has disconnected
Oct 10 09:05:48 ds /usr/sbin/gpm[1104]: *** info [mice.c(1990)]:
Oct 10 09:05:48 ds /usr/sbin/gpm[1104]: imps2: Auto-detected intellimouse PS/2
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.