Re: tar extract changed since netbsd-8? (extracting sets over running system)
On 13.11.2019 23:34, Christos Zoulas wrote: > In article <20191113222728.ga79...@bec.de>, > Joerg Sonnenberger wrote: >> On Wed, Nov 13, 2019 at 10:24:21PM -, Christos Zoulas wrote: >>> I don't want processes to die of fail to start because I am extracting >>> a tar file and I happen to be overwriting libc. It just does not >>> need to happen and it did not happen before. >> >> This argument is plainly false. It was never safe to do, especially when >> a library changes in incompatible ways. /bin/ls depending on a new >> system call and the extract hasn't reached /lib/libc.so.12 yet? Boom. > > It is always safe to do when building from the same sources. It is > also safe to do when using a new system call and using a new kernel > (the new kernel has it, the new libc can immediately use it). I > extract base.tgz all the time on live systems and never had any > issues. > > The "incompatible ways" argument is not my point. The point is the > lack of atomicity, which we had before and now we lost. It is not > safe anymore to extract libc on a running system because any new > processes trying to start while libc is incomplete/missing will die. > At least it does not kill the current process because it unlinks... :-) > > christos > I observed several times when inappropriate update of my libc.so killed initd and bricked my system as it was no longer bootable.. If the new tar (bsdtar) does not properly overwrite files in /, it is a fatal regression. signature.asc Description: OpenPGP digital signature
Re: tar extract changed since netbsd-8? (extracting sets over running system)
In article <20191113223755.ga79...@bec.de>, Joerg Sonnenberger wrote: >On Wed, Nov 13, 2019 at 10:34:51PM -, Christos Zoulas wrote: > >No, it was never atomic. Please read again what I wrote. /bin/ls and >/lib/libc.so.12 are not updated at the same time. That's the very >definition of non-atomic. In theory we could do a topological sort of >all sets to ensure that the shared libraries are placed first, but we >don't. So please stop pretending that any life update that involves an >API change of shared libraries is safe. It is not. It was atomic per file and now it is not. Let's say I only want to extract libc.so. It was safe before and now it is not. Yes, because some situations were broken before, are we justified to make things worse because of decision choices in upstream software that we might also be able to influence and change? >Anyway, the point is mood. I've reverted MKBSDTAR to no, so that >everyone can be happy. Yes, but how can we make progress like this? There are many things that libarchive does better than our pax? Why can't we have both? christos
Re: tar extract changed since netbsd-8? (extracting sets over running system)
On Wed, Nov 13, 2019 at 10:34:51PM -, Christos Zoulas wrote: > In article <20191113222728.ga79...@bec.de>, > Joerg Sonnenberger wrote: > >On Wed, Nov 13, 2019 at 10:24:21PM -, Christos Zoulas wrote: > >> I don't want processes to die of fail to start because I am extracting > >> a tar file and I happen to be overwriting libc. It just does not > >> need to happen and it did not happen before. > > > >This argument is plainly false. It was never safe to do, especially when > >a library changes in incompatible ways. /bin/ls depending on a new > >system call and the extract hasn't reached /lib/libc.so.12 yet? Boom. > > It is always safe to do when building from the same sources. It is > also safe to do when using a new system call and using a new kernel > (the new kernel has it, the new libc can immediately use it). I > extract base.tgz all the time on live systems and never had any > issues. > > The "incompatible ways" argument is not my point. The point is the > lack of atomicity, which we had before and now we lost. It is not > safe anymore to extract libc on a running system because any new > processes trying to start while libc is incomplete/missing will die. > At least it does not kill the current process because it unlinks... :-) No, it was never atomic. Please read again what I wrote. /bin/ls and /lib/libc.so.12 are not updated at the same time. That's the very definition of non-atomic. In theory we could do a topological sort of all sets to ensure that the shared libraries are placed first, but we don't. So please stop pretending that any life update that involves an API change of shared libraries is safe. It is not. Anyway, the point is mood. I've reverted MKBSDTAR to no, so that everyone can be happy. Joerg
Re: tar extract changed since netbsd-8? (extracting sets over running system)
In article <20191113222728.ga79...@bec.de>, Joerg Sonnenberger wrote: >On Wed, Nov 13, 2019 at 10:24:21PM -, Christos Zoulas wrote: >> I don't want processes to die of fail to start because I am extracting >> a tar file and I happen to be overwriting libc. It just does not >> need to happen and it did not happen before. > >This argument is plainly false. It was never safe to do, especially when >a library changes in incompatible ways. /bin/ls depending on a new >system call and the extract hasn't reached /lib/libc.so.12 yet? Boom. It is always safe to do when building from the same sources. It is also safe to do when using a new system call and using a new kernel (the new kernel has it, the new libc can immediately use it). I extract base.tgz all the time on live systems and never had any issues. The "incompatible ways" argument is not my point. The point is the lack of atomicity, which we had before and now we lost. It is not safe anymore to extract libc on a running system because any new processes trying to start while libc is incomplete/missing will die. At least it does not kill the current process because it unlinks... :-) christos
Re: tar extract changed since netbsd-8? (extracting sets over running system)
On Wed, Nov 13, 2019 at 10:24:21PM -, Christos Zoulas wrote: > I don't want processes to die of fail to start because I am extracting > a tar file and I happen to be overwriting libc. It just does not > need to happen and it did not happen before. This argument is plainly false. It was never safe to do, especially when a library changes in incompatible ways. /bin/ls depending on a new system call and the extract hasn't reached /lib/libc.so.12 yet? Boom. Joerg
Re: tar extract changed since netbsd-8? (extracting sets over running system)
In article <20191113215801.ga113...@bec.de>, Joerg Sonnenberger wrote: >On Wed, Nov 13, 2019 at 07:29:59PM -, Christos Zoulas wrote: >> Yes, but open(O_EXCL) does not protect you against mmapped segments >> (which has the potential to kill running processes that use shared >> libraries/jar/other mapped files) or crashing in the middle of >> writing a file and leaving stuff 1/2 written. For me safety trumps >> speed (after all we don't mount our filesystems async :-), so I >> would prefer that the default is slow and safe as opposed to fast >> and unsafe, like the old pax/tar did: > >O_EXCL|O_CREAT does not allow overwriting mmapped text segments. Always >writing new files and renaming doesn't make live updates safe either. >E.g. consider the case of a new symbol being updates to a shared >library. jars are not text segments. NFS can't know. Libarchive tries O_EXCL|O_CREAT, fails on existing files, unlinks and tries again. This creates a race condition when the file does not exist or the file is incomplete. All this stuff is simpler using rename(2). Yes, it can use double the disk space. Disks are big; remove before hand if you think you don't have space and re-extract. I don't want processes to die of fail to start because I am extracting a tar file and I happen to be overwriting libc. It just does not need to happen and it did not happen before. With tar/libarchive I don't even have an option to use rename, so I wrote one: https://www.netbsd.org:~christos/libarchive-atomic.diff And this is what I will be using locally because I don't like accidents :-) christos
Re: tar extract changed since netbsd-8? (extracting sets over running system)
On Wed, Nov 13, 2019 at 07:29:59PM -, Christos Zoulas wrote: > Yes, but open(O_EXCL) does not protect you against mmapped segments > (which has the potential to kill running processes that use shared > libraries/jar/other mapped files) or crashing in the middle of > writing a file and leaving stuff 1/2 written. For me safety trumps > speed (after all we don't mount our filesystems async :-), so I > would prefer that the default is slow and safe as opposed to fast > and unsafe, like the old pax/tar did: O_EXCL|O_CREAT does not allow overwriting mmapped text segments. Always writing new files and renaming doesn't make live updates safe either. E.g. consider the case of a new symbol being updates to a shared library. Joerg
Re: tar extract changed since netbsd-8? (extracting sets over running system)
On 2019-11-13 20:29, Christos Zoulas wrote: Yes, but open(O_EXCL) does not protect you against mmapped segments (which has the potential to kill running processes that use shared libraries/jar/other mapped files) or crashing in the middle of writing a file and leaving stuff 1/2 written. For me safety trumps speed (after all we don't mount our filesystems async :-), so I would prefer that the default is slow and safe as opposed to fast and unsafe, like the old pax/tar did: https://nxr.netbsd.org/xref/src/bin/pax/file_subs.c#238 But isn't the flow "unlink and extract new file" safe in this regard? I don't like the "temp file" idea, since it potentially (depending on old and new file size) requires double the space on the file system. regards, chris
Re: tar extract changed since netbsd-8? (extracting sets over running system)
In article , matthew sporleder wrote: >On Tue, Nov 12, 2019 at 8:51 AM Joerg Sonnenberger wrote: >> >> On Tue, Nov 12, 2019 at 08:25:46AM -0500, Greg Troxel wrote: >> > David Brownlee writes: >> > >> > > On Tue, 12 Nov 2019 at 11:33, JaromÃr DoleÄek > wrote: >> > >> >> > >> Le mar. 12 nov. 2019 à 12:05, Martin Husemann > a écrit : >> > >>> >> > >>> Not seen this locally, but that would be the switch to >bsd/libarchive tar. >> > >>> Maybe it does not unlink files before extraction and replaces >them in-space? >> > >>> >> > >>> I do the same kind of updates, but usually on a very quiet system. >> > >>> >> > >>> The crashes you see are from other running processes? Joerg would >> > >>> likely >> > >>> say: "don't do that" ;-) >> > >>> >> > >> >> > >> I thought we do unlink by default, I think I remember a commit to >that effect in past. The unlink is very useful default behaviour of GNU >tar. In-place overwrite is very rarely the wanted behaviour. >> > > >> > > Aha thanks! >> > > >> > > I would argue the switch to unlink no longer being the default is a >> > > regression. If its mandated by standards or we're the only outlier >> > > then it probably makes sense to switch, but otherwise its sprinkling >> > > occasional non deterministic breakage across a bunch of scripts which >> > > previously ran fine on NetBSD. >> >> It does not force an unlink first, but will unlink if there is a >> conflict. So the question would be why open(2) with O_CREAT|O_EXCL >> doesn't fail. >> >> > I'm not quite clear on 'unlink by default', but it seems to me the >> > replacement files should be written to a temporary name and then >> > renamed() into place so the file is either the old version or the new >> > version. >> >> That would dramatically increase the time it takes for an untar for >> little to no gain. Yes, but open(O_EXCL) does not protect you against mmapped segments (which has the potential to kill running processes that use shared libraries/jar/other mapped files) or crashing in the middle of writing a file and leaving stuff 1/2 written. For me safety trumps speed (after all we don't mount our filesystems async :-), so I would prefer that the default is slow and safe as opposed to fast and unsafe, like the old pax/tar did: https://nxr.netbsd.org/xref/src/bin/pax/file_subs.c#238 christos
Re: tar extract changed since netbsd-8? (extracting sets over running system)
Le mar. 12 nov. 2019 à 12:05, Martin Husemann a écrit : > Not seen this locally, but that would be the switch to bsd/libarchive tar
Re: tar extract changed since netbsd-8? (extracting sets over running system)
On Tue, Nov 12, 2019 at 8:51 AM Joerg Sonnenberger wrote: > > On Tue, Nov 12, 2019 at 08:25:46AM -0500, Greg Troxel wrote: > > David Brownlee writes: > > > > > On Tue, 12 Nov 2019 at 11:33, Jaromír Doleček > > > wrote: > > >> > > >> Le mar. 12 nov. 2019 à 12:05, Martin Husemann a > > >> écrit : > > >>> > > >>> Not seen this locally, but that would be the switch to bsd/libarchive > > >>> tar. > > >>> Maybe it does not unlink files before extraction and replaces them > > >>> in-space? > > >>> > > >>> I do the same kind of updates, but usually on a very quiet system. > > >>> > > >>> The crashes you see are from other running processes? Joerg would likely > > >>> say: "don't do that" ;-) > > >>> > > >> > > >> I thought we do unlink by default, I think I remember a commit to that > > >> effect in past. The unlink is very useful default behaviour of GNU tar. > > >> In-place overwrite is very rarely the wanted behaviour. > > > > > > Aha thanks! > > > > > > I would argue the switch to unlink no longer being the default is a > > > regression. If its mandated by standards or we're the only outlier > > > then it probably makes sense to switch, but otherwise its sprinkling > > > occasional non deterministic breakage across a bunch of scripts which > > > previously ran fine on NetBSD. > > It does not force an unlink first, but will unlink if there is a > conflict. So the question would be why open(2) with O_CREAT|O_EXCL > doesn't fail. > > > I'm not quite clear on 'unlink by default', but it seems to me the > > replacement files should be written to a temporary name and then > > renamed() into place so the file is either the old version or the new > > version. > > That would dramatically increase the time it takes for an untar for > little to no gain. > > Joerg If you try the same thing on FreeBSD does the same error happen?
Re: tar extract changed since netbsd-8? (extracting sets over running system)
On Tue, Nov 12, 2019 at 08:25:46AM -0500, Greg Troxel wrote: > David Brownlee writes: > > > On Tue, 12 Nov 2019 at 11:33, Jaromír Doleček > > wrote: > >> > >> Le mar. 12 nov. 2019 à 12:05, Martin Husemann a écrit > >> : > >>> > >>> Not seen this locally, but that would be the switch to bsd/libarchive tar. > >>> Maybe it does not unlink files before extraction and replaces them > >>> in-space? > >>> > >>> I do the same kind of updates, but usually on a very quiet system. > >>> > >>> The crashes you see are from other running processes? Joerg would likely > >>> say: "don't do that" ;-) > >>> > >> > >> I thought we do unlink by default, I think I remember a commit to that > >> effect in past. The unlink is very useful default behaviour of GNU tar. > >> In-place overwrite is very rarely the wanted behaviour. > > > > Aha thanks! > > > > I would argue the switch to unlink no longer being the default is a > > regression. If its mandated by standards or we're the only outlier > > then it probably makes sense to switch, but otherwise its sprinkling > > occasional non deterministic breakage across a bunch of scripts which > > previously ran fine on NetBSD. It does not force an unlink first, but will unlink if there is a conflict. So the question would be why open(2) with O_CREAT|O_EXCL doesn't fail. > I'm not quite clear on 'unlink by default', but it seems to me the > replacement files should be written to a temporary name and then > renamed() into place so the file is either the old version or the new > version. That would dramatically increase the time it takes for an untar for little to no gain. Joerg
Re: tar extract changed since netbsd-8? (extracting sets over running system)
David Brownlee writes: > On Tue, 12 Nov 2019 at 11:33, Jaromír Doleček > wrote: >> >> Le mar. 12 nov. 2019 à 12:05, Martin Husemann a écrit : >>> >>> Not seen this locally, but that would be the switch to bsd/libarchive tar. >>> Maybe it does not unlink files before extraction and replaces them in-space? >>> >>> I do the same kind of updates, but usually on a very quiet system. >>> >>> The crashes you see are from other running processes? Joerg would likely >>> say: "don't do that" ;-) >>> >> >> I thought we do unlink by default, I think I remember a commit to that >> effect in past. The unlink is very useful default behaviour of GNU tar. >> In-place overwrite is very rarely the wanted behaviour. > > Aha thanks! > > I would argue the switch to unlink no longer being the default is a > regression. If its mandated by standards or we're the only outlier > then it probably makes sense to switch, but otherwise its sprinkling > occasional non deterministic breakage across a bunch of scripts which > previously ran fine on NetBSD. I'm not quite clear on 'unlink by default', but it seems to me the replacement files should be written to a temporary name and then renamed() into place so the file is either the old version or the new version. Despite it being technically irregular, unpacking sets on a running system is a very normal thing to do. So I'm with abs@ ont this - the old behavior should be default.
Re: tar extract changed since netbsd-8? (extracting sets over running system)
On Tue, 12 Nov 2019 at 11:33, Jaromír Doleček wrote: > > Le mar. 12 nov. 2019 à 12:05, Martin Husemann a écrit : >> >> Not seen this locally, but that would be the switch to bsd/libarchive tar. >> Maybe it does not unlink files before extraction and replaces them in-space? >> >> I do the same kind of updates, but usually on a very quiet system. >> >> The crashes you see are from other running processes? Joerg would likely >> say: "don't do that" ;-) >> > > I thought we do unlink by default, I think I remember a commit to that effect > in past. The unlink is very useful default behaviour of GNU tar. In-place > overwrite is very rarely the wanted behaviour. Aha thanks! I would argue the switch to unlink no longer being the default is a regression. If its mandated by standards or we're the only outlier then it probably makes sense to switch, but otherwise its sprinkling occasional non deterministic breakage across a bunch of scripts which previously ran fine on NetBSD. Thanks David
Re: tar extract changed since netbsd-8? (extracting sets over running system)
On Tue, Nov 12, 2019 at 12:05:14PM +0100, Martin Husemann wrote: > Not seen this locally, but that would be the switch to bsd/libarchive tar. > Maybe it does not unlink files before extraction and replaces them in-space? It doesn't unlink them by default, yes. -U would force that. Joerg
Re: tar extract changed since netbsd-8? (extracting sets over running system)
Not seen this locally, but that would be the switch to bsd/libarchive tar. Maybe it does not unlink files before extraction and replaces them in-space? I do the same kind of updates, but usually on a very quiet system. The crashes you see are from other running processes? Joerg would likely say: "don't do that" ;-) Martin
