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

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

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--eoF4U89tlW7S374QdO2eMsJjbeTviBVqK
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]>
 <[email protected]>
 <[email protected]>
In-Reply-To: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable



Am 24.02.2021 um 15:50 schrieb Andrew:
> 24.02.2021 16:09, Erich Titl =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
>> Hi Andrew
>>
>> Am 24.02.2021 um 12:26 schrieb Andrew:
>>> Hi.
>>>
>>> Unmounting may fail if happened too early (fs still used), so it's=20
>>> good to retry umounting. I noticed this in accel-ppp. In that case=20
>>> modules remains mounted.
>>
>> I have never experienced such behaviour and I _guess_ it must be=20
>> related to accel-ppp then. I was always assuming that modprobe=20
>> returned clean.
>=20
> modules are loaded at daemon start/iptables rule loading.=20

Yes as it is in shorewall.

this may be
> happened after startup of any daemon that may load kernel modules (ppp,=
=20
> etc) which have mount_modules call in init script.

Yes but I believe it is the responsibility of the init script to check=20
that module loading is terminated and then call umount_modules maybe=20
even in a loop, but outside the uount_modules proper.

The way it is implemented right now in init is that umount_modules is=20
always recursively called until it returns sucess on the _second_ run.

>=20
> so I think that it's good to try to unmount modules squashfs and storag=
e=20
> till it'll be unmounted - or till it'll fail by timeout.

This is not really deterministic and may take quite a while.

  In other case
> we may have persistently mounted files storage in /tmp - whicn may be=20
> suddenly cleaned by rm -rf /tmp/*

I understand this very well and if the timeout is reached we may still=20
see this. We should check that module loading is over _before_ we call=20
umount_modules. There must be a way to do this even in accel-ppp.

cheers

ET

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

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

wsF5BAABCAAjFiEE8XDmYcnNZQgR6jLcCIn0YaS9udoFAmA2bbwFAwAAAAAACgkQCIn0YaS9udpb
aQ/+MUhAO2ACb3RHAvWKwdU8MV1J7BRVpdZIiN/SMQcXS6vEQ+31IQ+igegT7NMwL/K72FBHgYRv
iyAgKWmeuXdniEp9HBqM/ehPaWB4DymHrseuJHckjEqN5Lc6b1MTfb6hwaLYV7sG6pmTrHCTgPDV
LlSH/sf89YdAYkWn0dOktFnWRmjWh/r4PEobWuX7yuL1c1QMNUCBggVebCEbJSU/edmhmMzdT+oD
5/KPsBHBj+0feKbjIJNY4c37AFWm5i5zHRCHJSRD7CxDIhsIBJwtitq7OKosp7PfZ6btNtJsOSAX
ubTRNVxLwrWyDYgqEP4/udc36G7qstA8P4IAas8VzTRtpFFo4T8hxxsxBJF/kRr/qLmNhOyS1z3M
EGIi53ZCj/5pTq3Tsw56CX87EcMd54kyQ8deePMsYCvh4i7xVoDvyHtsLTB7V9lSPSKl40wGy0Zo
yJaTHxX/Lgnbg2mqxEb4V5U1IyLpFiaBylPBvq+DZ1dBHxHZy4k8g5hpuGqBW3G3hoUC/MJMS6zq
7oePPCfb83vTFlF6MWcDfH7R7a2RpoAm/htELffhWrIDx8Q2W1YGtvvkxJOvyuhyoNKPG+bw1Xes
FMNFCTsyYAcZeCb6gF5HBqd1pWtwOjJLxEDfrk+Ajypar9aYt0YxFKnswwxv8jb4a8rYAFKti2hm
Lqo=
=8bH2
-----END PGP SIGNATURE-----

--eoF4U89tlW7S374QdO2eMsJjbeTviBVqK--


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


--===============6685524157242623074==
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

--===============6685524157242623074==--