Devuan bug report logs - #227
nbd-client: At shutdown nbd-client disabled before file-systems could be cleanly unmounted

Package: sysvinit-utils; Maintainer for sysvinit-utils is Devuan Developers <devuan-dev@lists.dyne.org>; Source for sysvinit-utils is src:sysvinit.

Affects: nbd-client

Reported by: David Kuehling <dvdkhlng@posteo.de>

Date: Mon, 16 Jul 2018 00:03:01 UTC

Severity: normal

Tags: upstream

Fixed in version 3.07-1

Done: Mark Hindley <mark@hindley.org.uk>

Full log

🔗 View this message in rfc822 format

X-Loop: owner@bugs.devuan.org
Subject: bug#227: nbd-client: At shutdown nbd-client disabled before file-systems could be cleanly unmounted
Reply-To: Jesse Smith <jessefrgsmith@yahoo.ca>, 227@bugs.devuan.org
Resent-From: Jesse Smith <jessefrgsmith@yahoo.ca>
Resent-To: devuan-bugs@lists.dyne.org
Resent-CC: Devuan Developers <devuan-dev@lists.dyne.org>
X-Loop: owner@bugs.devuan.org
Resent-Date: Sun, 19 Feb 2023 05:06:01 +0000
Resent-Message-ID: <handler.227.B227.167678307222892@bugs.devuan.org>
Resent-Sender: owner@bugs.devuan.org
X-Devuan-PR-Message: followup 227
X-Devuan-PR-Package: sysvinit-utils
X-Devuan-PR-Keywords: upstream
References: <87r2k4njjg.fsf@snail.snail.pool> <Y+5KRGlB5crallrj@hindley.org.uk> <e4623351-4e7c-3623-926d-1d08a0965278@resonatingmedia.com> <Y+5XMAODvbjKHf/k@hindley.org.uk> <87r2k4njjg.fsf@snail.snail.pool>
X-Devuan-PR-Source: sysvinit
Received: via spool by 227-submit@bugs.devuan.org id=B227.167678307222892
          (code B ref 227); Sun, 19 Feb 2023 05:06:01 +0000
Received: (at 227) by bugs.devuan.org; 19 Feb 2023 05:04:32 +0000
Delivered-To: bugs@devuan.org
Received: from email.devuan.org [2001:41d0:2:d06e::5c4:2612]
	by doc.devuan.org with IMAP (fetchmail-6.4.16)
	for <debbugs@localhost> (single-drop); Sun, 19 Feb 2023 05:04:32 +0000 (UTC)
Received: from email.devuan.org
	by email.devuan.org with LMTP
	id SlGRGaat8WPWTwAAmSBk0A
	(envelope-from <jessefrgsmith@yahoo.ca>)
	for <bugs@devuan.org>; Sun, 19 Feb 2023 05:03:34 +0000
Received: by email.devuan.org (Postfix, from userid 109)
	id 5654EB11; Sun, 19 Feb 2023 05:03:34 +0000 (UTC)
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on email.devuan.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,
	RCVD_IN_MSPIKE_H2,SPF_PASS autolearn=ham autolearn_force=no
	version=3.4.6
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=74.6.133.125; helo=sonic313-15.consmr.mail.bf2.yahoo.com; envelope-from=jessefrgsmith@yahoo.ca; receiver=<UNKNOWN> 
Received: from sonic313-15.consmr.mail.bf2.yahoo.com (sonic313-15.consmr.mail.bf2.yahoo.com [74.6.133.125])
	by email.devuan.org (Postfix) with ESMTPS id 6AB1F34
	for <227@bugs.devuan.org>; Sun, 19 Feb 2023 05:03:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s2048; t=1676783004; bh=w1I/jzM5VQP+HjN9uwgLMnGWlgnpN8JSZyOHbWuYpd8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject:Reply-To; b=jZGTmgTc7Vk8UyR2Mlwf3RXJFHpE1/1IGy6qIgoc+dWiLo11bk5RI8My3AGiOQdvbgqfAtsB1hgfCIIIRV8o+fz+tCVV4DGkuIKj34hEs9RiByshQQCxr3bL5/k603nAan8t7oiDV5RORP8gRcdDLr4DdcR4LA3It6ApzTD+NKbh1plkYxaEFG3fbrREqTrk0GQtAaZuazQzDx5RD/P/vyjyRZ9+LZ323Va/gMVKU/PoicRXC5lg//CjRgdfRC53gckXKhxnE6NWzbZbNY2Z/jyHV1sZOwPb6m0FfhBB8llIDY6S1qc64Pa3JiCwhPxfvQR5QifjtbNKHLRK90867Q==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676783004; bh=mBfxGik79OJst7RW6bHLrVAaDMMMpSyvVdsAA1DD3P9=; h=X-Sonic-MF:Subject:To:From:Date:From:Subject; b=EVDbmPyYK3eOdYPmTNl6jk8CU6zDhZq53CPHXrRBDq7fRGzXds2VZ27Y+L36cVCwhyuAR+8WyybKLOamptKLfSLB32vrpstrar7LM7zXinxuAe5se9/FE7gNuyVwwJHbrJmybGYr3wwqvE4yNzwFmAuVolLbFmpo9d/9Hja2vYLSWohvXcJr+jrDYeQqB2WTgMOWbb6gjW/e8OUcKQU2pkZ7wQQ6ZDlFR+bAUM864UgY421/OIJT9CK7AAY7FniKjzgOYmlDskqQLiEP83PvXLlB3kMKvLPsSLVJzEhqxTpSG28DdYP3IQR9TOtZaFar6jhkM4OGhEfwQjSXEHHwuQ==
X-YMail-OSG: Qgc8HqcVM1krSbof00DjWMMVk0IOxacIeiPyJmUZcVn0pIx9SEqcT2KIAfIF9oT
 1XV7aDnyR5IvxWCd8CI757.Fus9VO4zOF1P8z3Npr8llXsau.VjMYQDEkYHt4MX_yVZJVfR8YzbZ
 vm0KnMEHgeeuGo2d2.VtKbj9lc0WkFfC25ZPIARH5I1lznre9eGNw8NCmUbYQHwJ7TAsc9CMW9he
 dTyjW8RcI6iX7j.MdmskJ7am38_3H7tuL_.y5RcY_gF1wQMzvQxYwsY_SwBJ_dOms8XjN7GqmeK.
 dkL_QnwuqpdaXo13TGlNyg12VurxZCdcGIvBW7HoZA9HbYop3h2F_rvZX2Ib7rTcVBWujalvuTxS
 qDS5dj2dnPspzWCTKNcycVOtEiY.WM1jQi9XbB3DZbLRtxXGD5IPBpcc441FlqgHxNkhD_n.6Vse
 u_SiW_6Pu9pbkw7OgnM1CIWcnAx1RPmJI6mIVnbEOGfq9x0hOJXBM1kg2YR4U7IVyU86DPENIcOH
 03GWcMtfL.iH4aoFJIt6EXdeBc4ca8mIprwLeK7piAXmMKshww6Bewf4572P5iLtvRXn7qrrvv9i
 VxebBFr4GRpuWMeW1Lo8MUnwzrqd6UUj6KvyauyUkjFcs4QZmfmoquuu8KO3xvx_QO3aBf.Wktim
 6syri20vVb0CamZVlX.1S95JnQC5_Z9RZsOpvYjTu7EY7zAohY48LMUukW7G_QqLO6yIFVt3VQfy
 KnK7QrbLikqgZaOZ84m3PxLbcCW3WmB2H95_mTkfMxhAdwwmHUh6QBRt21lDBNbHZIBwGsW7RP7j
 Bsn6Du0kkusq4oHyV8wK24MyiT9.Bxs71EsBOKFMNn37FcQnMI.UMXcq9xAPtVbAu6_dXy6GJPOA
 cPQDg068ffH5q3ras0UyU1wHUIA4xCZ13hNP.l_dsW71O3q.0LbGbtSuwPSX_66JkozmFxikQajz
 CUy8GoBY1UMtNa53fbJ3LW8GgCY.ZUU5TDTYuLHdgUmF60wQuOrrtXYv4htYgSFGaSzo6BC3UzLp
 p2zT6pkMDQCU1HfsxWECYSlOhnPUEdxgN8FCRsEOX.NPhFCcc1n2GDK3WzMTnw.cR6G.qS52EOK3
 Q6zIP1ntv_MUGvZIfWYxyZ0CgxNQC0aSojE.MkkvaQPJQqhvW6dZRUnBpy5OqW7ZLyiHMWs9OhwQ
 78OcUv8CDw5.iv0BOPiy5GViSZcEUqsVKQ_VF3xj46kz8xn1bhlXdtoWMESR2oVk_x26s9g3J7gD
 BaUxXbUU7ynN.TvDhBT5ac0rdWBGbsYXH_hWYCiP3fNQHMCyaY8wD3D1GlS_raSFGjshM66MBKJS
 Oehd7Zb6cQJC2ThebsyklbNvTgjD7DaPQzbpCnBdzLQuW4arOP4CZlyGXduSIAUwrAP.JBqGQyif
 7hiOVIBeUkOQfa3ms.rj1QgX.d3Pz0DdRxVX1CXysaG5t6WQcyThNd4n42HEabqo3_QnloCEimAp
 HP7Q9B6VDWK0_43NpIZ2rD.WCY_W7n3SXRjd_0IsFWTIEn7DqMMYPJVtqhfOvwTDkzuSt6bsSDAr
 MvXB2PrhxT8qWzPCs6ki0JCKH64rK2WLTnwii1NjAZZFOvT_JHEKr.kCmIbOX8GS4ECd8dvIzEfF
 OGTC3eFbgz7Jy9GZlXLsXPUyy48EltP.T9PwkOUdiNhCulwnatcYXptV.bNxLCcekjUs54HKYQvl
 POYSiLsMt2qOj7Jbi3vcWBbVk3EpQPJxejaroKNvfmDjY8HBnh1mKKAh65dQfqiiTSb5hWIvgYjT
 CQfTNXwTH4fGPkJxZFq82v_SUvXUp4TU75sNboeIu0g.BKDawrbKAmFV4bM8YCgW5Wrnv3AepGOK
 regVfposlFkGgUhr4SOYHHw9Stl8o0DsygRSPmCE5IloFEmzIJ9GTTGvyLCxHFjyasE1e1WUn0Oc
 WuKjCZ99kS.JWtaQepmcV13jCGE4_pXW.r1bC.zaGGjDxm0wUKupQ4J66B4Rw2xgy22oJc_13ccA
 o_KfVPnicxygzO.tTpbzUv4KDOr2Hgl9RIi9x7HuHEmxZNyL.FEymkxPFcUNbDBkezISG4KQagi.
 2g9VgpAEk2vBJ0y6u2CELPZbnf93Oo8FyvhtShzD1OYX5wZsU9w0xF0lT_nnka9BUT0vWuFhUE__
 3MmVL55oh_ixICbdK.k5OK9cL7YBkHOSQbR3F_j2aEq_fEx3b5tyGcsqwJ6rVa6Adc2k.hCweVAj
 wSH1aIYX1rFmTIInMzSJMrid8S4.diwDrYB2j9vyeD0dbGdy2B5GW8A--
X-Sonic-MF: <jessefrgsmith@yahoo.ca>
Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Sun, 19 Feb 2023 05:03:24 +0000
Received: by hermes--production-gq1-655ddccc9-zfzhj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9c275a2ca59a61c8d63dd7c8c2b9c24e;
          Sun, 19 Feb 2023 05:03:18 +0000 (UTC)
To: Mark Hindley <mark@hindley.org.uk>
Cc: David Kuehling <dvdkhlng@posteo.de>, 227@bugs.devuan.org
From: Jesse Smith <jessefrgsmith@yahoo.ca>
Message-ID: <b354bc67-69fe-5d54-7ef1-eca9912d0eb5@yahoo.ca>
Date: Sun, 19 Feb 2023 01:03:16 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <Y+5XMAODvbjKHf/k@hindley.org.uk>
Content-Type: multipart/mixed;
 boundary="------------F0E8AD74D4D601E640AF11BB"
Content-Language: en-CA
X-Mailer: WebService/1.1.21183 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo

[Message part 1 (text/plain, inline)]

On 2023-02-16 12:17 p.m., Mark Hindley wrote:
> Control: reassign -1 sysvinit-utils
> Control: affects -1 nbd-client
>
> Jesse,
>
> Thanks for you quick reply.
>
> On Thu, Feb 16, 2023 at 11:54:32AM -0400, Jesse Smith wrote:
>> I see two possible ways we could fix this:
>>
>> 1. Create a command line flag which disables the SIGSTOP and SIGCONT
>> signals being sent. This is an easy fix, quick and dirty. The potential
>> downside is if someone disables the STOP signal then maybe processes
>> terminate, move groups, or are replaced before we get around to sending
>> them the KILL signal. This probably won't happen, but it means killall5
>> is working with a "moving target".
>>
>> 2. We can run SIGSTOP on all processes _except_ those in the omit list.
>> This will be a lot slower than the existing "kill(-1, SIGSTOP)" call we
>> currently make. But I think it's more correct.
>>
>> Basically the new work flow would look like this:
>>
>> 1. Send all processes except those omitted the SIGSTOP command.
>> 2. Send all processes except those omitted the SIGKILL command.
>> 3. Send all processes except those omitted the SIGCONT command.
>>
>> Option #2 is slow and ugly, but seems "correct" from a behaviour point
>> of view.
> I don't really like #1: it will mean patching callers to get the (more?) correct
> behaviour. So #2 seems better. Will it be significantly slower?. You could only
> use it when omitpid is specified? If there are no omitpids, the current
> behaviour seems fine.
>

I looked at this issue some more and it turns out option #2 doesn't
really makes sense with the way killall5 works. The SIGSTOP signal is
sent out to basically pause everything on the system so we can sort
through what is available to be terminated and what should be spared. If
we want to go through the whole process tree to see what should or
should not be stopped first, then it removes the point of sending
SIGSTOP to give us a fixed collection of processes.

In other words, sending SIGSTOP only makes sense if we later want to
freeze everything and then sort processes into what we will terminate
and what will be omitted. If we are going to go through all the
processes and send some the SIGSTOP signal and not others, then we might
as well just skip the STOP and move straight on to terminating
appropriate processes.

I've tried to work in a reasonable middle ground. Now, if no processes
are in the "omit" list, we stick to the original behaviour. We stop
everything, sort through which processes we will terminate, then send
everything the SIGCONT signal. Just like before.

However, if there are any processes in the "omit" list, then we err on
the side of caution. Nothing is sent STOP or CONT, we just sort through
the processes we know about quickly and try to terminate everything
we're supposed to kill. And ignore anything in the process list.

It's not perfect, we could conceivably miss a process that was created
while we were sorting through the list after the point we'd normally
send SIGSTOP. However, this approach makes certain we do not damage any
process that can't handle receiving SIGSTOP.

The downside is that a process could get created after killall5 is run
and before it is terminated. However, this is always going to be the
case when we allow some programs to be in the "omit" list. Any of the
omitted programs could spawn a new process, so that risk already
existed. This doesn't really make the situation (much) worse.

I've tested this change and it seems to work. I'm attaching a new copy
of killall5 for testing. It's also available on GitHub in the 3.07
branch of sysvinit.

Also, as a bonus, a bunch of the killall5 code didn't initialize
variables, seeming to assume a specific code path or that the compiler
would initialize variables to zero/NULL. Since this isn't always true,
I've initialized variables we might now use in unexpected order or which
should be NULL/false at the start of the program.

- Jesse

[killall5.c (text/x-csrc, attachment)]

Send a report that this bug log contains spam.

Devuan bug report logs - #227 nbd-client: At shutdown nbd-client disabled before file-systems could be cleanly unmounted

Devuan bug report logs - #227
nbd-client: At shutdown nbd-client disabled before file-systems could be cleanly unmounted