Re: Fwd: [leaf:bering-uclibc] New commit [d479db] by Andrew Denisenko

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============6795253715627907377==
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="Q8ymUvCP6d8DnSsFjCMqIWxoiMNYNABBa"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Q8ymUvCP6d8DnSsFjCMqIWxoiMNYNABBa
From: Erich Titl <[email protected]>
To: [email protected]
Message-ID: <[email protected]>
Subject: Re: [leaf-devel] Fwd: [leaf:bering-uclibc] New commit [d479db] by
 Andrew Denisenko
References: <499a28667afff96caebc8b799cb51b7e8adf5a75.bering-uclibc@leaf.p.sourceforge.net>
 <[email protected]>
 <[email protected]>
In-Reply-To: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Andrew

Am 24.02.2021 um 12:26 schrieb Andrew:
> Hi.
>=20
> Unmounting may fail if happened too early (fs still used),

Yes that is the case with umount and with umount_modules.

  so it's good
> to retry umounting.

No, umount fails and why should umount_modules be different.

  I noticed this in accel-ppp. In that case modules
> remains mounted.

Yes unfortunately, but this needs to be resolved in accel-ppp.

There are multiple ways to do this without lobotomizing umount_modules.

I looked at the init script and as I expected the service is started=20
using start-stop-daemon. As I understand start-stop-daemon just launches =

the respective service and returns immediately without asserting that=20
the service is fully running. So this explains why we still may have fs=20
access at that time. Needless to say I don't like it.

In these circumstances the init script needs to verify that the service=20
process is fully started and all modules are loaded _before_ we call=20
umount_modules. Not knowing how to request status information from the=20
various service processes makes it impossible for me to guess how=20
difficult this may be.

One way would be to check if a process still needs the file system.

Another method is to add a loop in the init script for umount_modules, a =

bit alike as in the suggested init. This is closer to the original=20
umount tool and would correspond closer to *X standards. If a timeout is =

used then this is non deterministic. Some fine tuning would allow to=20
better handle fs access.

The most simple way is to just insert a timeout in the init script just=20
before unmounting the modules. Again, this is non deterministic.

Both methods above would result in the same way as the proposed change=20
to umount_modules.

We should leave umount_mdule as is. It is supposed to be a one-shot=20
attempt to unmount the modules and should not be overfraught with retry=20
logic. It returns an error in the case of failure and provides some=20
logging.

I believe Andrew is the only one ever using accel-ppp. We should not=20
adapt our tools to corner cases but to adapt the corner cases to our tool=
s.

cheers

ET

--Q8ymUvCP6d8DnSsFjCMqIWxoiMNYNABBa
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEE8XDmYcnNZQgR6jLcCIn0YaS9udoFAmA3rGYFAwAAAAAACgkQCIn0YaS9udoY
Pw/+MxDrZFwPQFcpJL754uUKfW3L0h9ZI7os2BTutLVRc9djYC32/eDEBubeuISgGq5RMq93ews1
D2285i5i+S/abtbTqj2qd5zx1rf0HAuXAoikuglxqeKzJk9ph2B62aeaXnW6H6hENT1uEuEXi2Yu
glRz6b7L1Tl1Vku94rykk3tbMKu9AvimzyjbCzq4ypuVNcGokIUC2aU7Wk1ScuFHePc6dVYH5d1t
pHzgZQZ32BKX+PtVGnBBSLsb4Rhwiga8mDiCveQVKc3K5aLkgMe2Ki2OkNToYxUHmJ8uiLlJdC7/
2wJyvDTcGcvcV8eqgb/4y06/Pqgp3Okphw67HINx9ctbrljFXTkC2OI15nwSqWIbM9JZimQV0NWJ
diyXtvy56UqrMRZNetOgQIhPruhs4d+yzem2kO65tPFEGk32CEVjYcdehOfYElFsTGvAHPfIuu0o
im9z4G3DcWQByqsUOVgfLvnrjvNLkawgkQipY9kO4nxKDR/vTyoXOXNYhNNbG1nHwy7iPHAQpZk8
VKpe1+pXWNaZCKPBL4HJINCSKeZOTrq9ubpz/n7dEdo+pdyuPH5asSpjTO2AKmh2C0BkneUKxhou
sXAgcD31wWQhY0F2OHKlKbcB3mUWIKDzea50WBQ4pBnGDscD/u9KhZBJ1r0sdJUPZWFK+/7HUhZh
p2Y=
=bTS+
-----END PGP SIGNATURE-----

--Q8ymUvCP6d8DnSsFjCMqIWxoiMNYNABBa--


--===============6795253715627907377==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============6795253715627907377==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


_______________________________________________
leaf-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

--===============6795253715627907377==--