LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 09-17-2021, 03:49 AM   #76
marav
LQ Sage
 
Registered: Sep 2018
Location: Gironde
Distribution: Slackware
Posts: 5,235

Rep: Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949

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 think, this patch alone :
Code:
dhcpcd.2fae4a113c3e736d585dd300ca6c8fddae300503.patch
doesn't help

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

Last edited by marav; 09-17-2021 at 03:52 AM.
 
1 members found this post helpful.
Old 09-17-2021, 04:26 AM   #77
pghvlaans
Member
 
Registered: Jan 2021
Distribution: Slackware64 {15.0,-current}, FreeBSD, stuff on QEMU
Posts: 447

Original Poster
Rep: Reputation: 363Reputation: 363Reputation: 363Reputation: 363
Quote:
Originally Posted by marav View Post
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?
 
Old 09-17-2021, 04:29 AM   #78
marav
LQ Sage
 
Registered: Sep 2018
Location: Gironde
Distribution: Slackware
Posts: 5,235

Rep: Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949
Quote:
Originally Posted by pghvlaans View Post
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?

Last edited by marav; 09-17-2021 at 04:32 AM.
 
Old 09-17-2021, 04:34 AM   #79
pghvlaans
Member
 
Registered: Jan 2021
Distribution: Slackware64 {15.0,-current}, FreeBSD, stuff on QEMU
Posts: 447

Original Poster
Rep: Reputation: 363Reputation: 363Reputation: 363Reputation: 363
Open for now it is.

Sounds great, thanks very much.
 
Old 09-17-2021, 01:09 PM   #80
marav
LQ Sage
 
Registered: Sep 2018
Location: Gironde
Distribution: Slackware
Posts: 5,235

Rep: Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949
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.
 
Old 09-17-2021, 02:21 PM   #81
marav
LQ Sage
 
Registered: Sep 2018
Location: Gironde
Distribution: Slackware
Posts: 5,235

Rep: Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949
Reported upstream:

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
Code:
root      1643  0.0  0.1 286552 15924 ?        Ssl  20:54   0:00 /usr/sbin/NetworkManager
dhcpcd    2839  0.0  0.0   3004  2564 ?        S    20:56   0:00  \_ dhcpcd: wlan0 [ip4]
root      2840  0.0  0.0   3008  1996 ?        S    20:56   0:00      \_ dhcpcd: [privileged actioneer] wlan0 [ip4]
dhcpcd    2865  0.0  0.0   3008   304 ?        S    20:56   0:00      |   \_ dhcpcd: [BPF ARP] wlan0 192.168.111.15
dhcpcd    2871  0.0  0.0   3008   304 ?        S    20:56   0:00      |   \_ dhcpcd: [network proxy] 192.168.111.15
dhcpcd    2841  0.0  0.0   2996   292 ?        S    20:56   0:00      \_ dhcpcd: [control proxy] wlan0 [ip4]
root      2505  0.0  0.0   3008  2004 ?        S    20:55   0:00 dhcpcd: [privileged actioneer] wlan0 [ip4]
dhcpcd    2513  0.0  0.0   3008   300 ?        S    20:55   0:00  \_ dhcpcd: [BPF ARP] wlan0 192.168.111.15
dhcpcd    2519  0.0  0.0   3008   300 ?        S    20:55   0:00  \_ dhcpcd: [network proxy] 192.168.111.15
this does not happen with dhcpcd-master

Regardless of the version of dhcpcd, the network is always functional in all cases.

Last edited by marav; 09-17-2021 at 02:22 PM.
 
Old 09-17-2021, 11:23 PM   #82
pghvlaans
Member
 
Registered: Jan 2021
Distribution: Slackware64 {15.0,-current}, FreeBSD, stuff on QEMU
Posts: 447

Original Poster
Rep: Reputation: 363Reputation: 363Reputation: 363Reputation: 363
Quote:
Originally Posted by marav View Post
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
Code:
root      1643  0.0  0.1 286552 15924 ?        Ssl  20:54   0:00 /usr/sbin/NetworkManager
dhcpcd    2839  0.0  0.0   3004  2564 ?        S    20:56   0:00  \_ dhcpcd: wlan0 [ip4]
root      2840  0.0  0.0   3008  1996 ?        S    20:56   0:00      \_ dhcpcd: [privileged actioneer] wlan0 [ip4]
dhcpcd    2865  0.0  0.0   3008   304 ?        S    20:56   0:00      |   \_ dhcpcd: [BPF ARP] wlan0 192.168.111.15
dhcpcd    2871  0.0  0.0   3008   304 ?        S    20:56   0:00      |   \_ dhcpcd: [network proxy] 192.168.111.15
dhcpcd    2841  0.0  0.0   2996   292 ?        S    20:56   0:00      \_ dhcpcd: [control proxy] wlan0 [ip4]
root      2505  0.0  0.0   3008  2004 ?        S    20:55   0:00 dhcpcd: [privileged actioneer] wlan0 [ip4]
dhcpcd    2513  0.0  0.0   3008   300 ?        S    20:55   0:00  \_ dhcpcd: [BPF ARP] wlan0 192.168.111.15
dhcpcd    2519  0.0  0.0   3008   300 ?        S    20:55   0:00  \_ dhcpcd: [network proxy] 192.168.111.15
this does not happen with dhcpcd-master

Regardless of the version of dhcpcd, the network is always functional in all cases.
I can confirm that this happens on resume as well. And those old processes are like cockroaches; nothing seems to get rid of 'em except signal 9.

Last edited by pghvlaans; 09-17-2021 at 11:25 PM.
 
Old 09-23-2021, 03:53 PM   #83
PJBrs
Member
 
Registered: Oct 2006
Distribution: Slackware 14.2 / -current
Posts: 76

Rep: Reputation: 33
I tried to bisect between 9.4 and master. The first commit that works as it should, with the addition of

Code:
2fae4a113c3e736d585dd300ca6c8fddae300503
DHCP6: Only send FQDN for SOLICIT, REQUEST, RENEW, or REBIND messages.
is

Code:
7f6825d3db103bb44cca71aa926c5f5fd9f544d2 privsep: Fix Linux support for prior
That's 60 patches beyond dhcpcd-9.4.0. I wasn't able to cherry-pick it though...
 
Old 09-23-2021, 04:02 PM   #84
marav
LQ Sage
 
Registered: Sep 2018
Location: Gironde
Distribution: Slackware
Posts: 5,235

Rep: Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949
Quote:
Originally Posted by PJBrs View Post
I tried to bisect between 9.4 and master. The first commit that works as it should, with the addition of

Code:
2fae4a113c3e736d585dd300ca6c8fddae300503
DHCP6: Only send FQDN for SOLICIT, REQUEST, RENEW, or REBIND messages.
is

Code:
7f6825d3db103bb44cca71aa926c5f5fd9f544d2 privsep: Fix Linux support for prior
That's 60 patches beyond dhcpcd-9.4.0. I wasn't able to cherry-pick it though...
Thank you
Maybe it can be usefull. I reported it
 
Old 09-26-2021, 05:19 AM   #85
PJBrs
Member
 
Registered: Oct 2006
Distribution: Slackware 14.2 / -current
Posts: 76

Rep: Reputation: 33
@marav - I hope it is...

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?

Last edited by PJBrs; 09-26-2021 at 05:20 AM.
 
Old 09-26-2021, 05:32 AM   #86
marav
LQ Sage
 
Registered: Sep 2018
Location: Gironde
Distribution: Slackware
Posts: 5,235

Rep: Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949
Quote:
Originally Posted by PJBrs View Post
@marav - I hope it is...

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?
https://slackware.nl/cumulative/slac...slackware64/n/

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.
hope you have better luck

Last edited by marav; 09-26-2021 at 05:36 AM.
 
Old 09-26-2021, 02:09 PM   #87
PJBrs
Member
 
Registered: Oct 2006
Distribution: Slackware 14.2 / -current
Posts: 76

Rep: Reputation: 33
@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.

Last edited by PJBrs; 09-26-2021 at 02:10 PM.
 
Old 09-26-2021, 03:20 PM   #88
marav
LQ Sage
 
Registered: Sep 2018
Location: Gironde
Distribution: Slackware
Posts: 5,235

Rep: Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949
Quote:
Originally Posted by PJBrs View Post
@marav I think I found something. However, now I'm left without default route or ip4 nameserver. Anyway.

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.
Sounds good
I've reported it upstream

edit :
we have fixed all the things separately, now we just have to shake it all up

Last edited by marav; 09-26-2021 at 03:38 PM.
 
Old 09-28-2021, 06:28 AM   #89
marav
LQ Sage
 
Registered: Sep 2018
Location: Gironde
Distribution: Slackware
Posts: 5,235

Rep: Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949
@PJBrs

Thx for your comment ;-)
 
Old 10-10-2021, 04:39 AM   #90
_peter
Member
 
Registered: Sep 2014
Location: paris
Distribution: slackware
Posts: 314

Rep: Reputation: Disabled
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
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
#WIFI IP Loss - #Ubuntu #Zesty fails to obtain #IP when logged to #Router via WIFI tarant8l Linux - Wireless Networking 1 10-05-2017 08:07 AM
Loss Of Network Connection After Power Loss etpoole60 Linux - Networking 4 11-02-2014 07:55 PM
Loss Of Network Connection After Power Loss etpoole60 Linux - Virtualization and Cloud 2 10-27-2014 03:14 PM
Network Connection Loss And USB Connection Loss. Novatian Linux - Desktop 1 11-07-2008 02:09 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 02:56 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration