Take this, for example:
https://codeberg.org/dwl/dwl/src/branch/main/Makefile#L64
The
install target of a Wayland compositor uses cp to copy the compiled binary to your bin directory. So, as of Linux 6.11, when you recompile this compositor and reinstall it, it will crash your entire Wayland session. 🧟💀🧟One way to avoid this crash is to use install instead of
cp. install calls unlink() before copying the data, thus avoiding this situation entirely. Not all Makefiles do that, though.
Take this, for example:
https://codeberg.org/dwl/dwl/src/branch/main/Makefile#L64
The
install target of a Wayland compositor uses cp to copy the compiled binary to your bin directory. So, as of Linux 6.11, when you recompile this compositor and reinstall it, it will crash your entire Wayland session. 🧟💀🧟One way to avoid this crash is to use install instead of
cp. install calls unlink() before copying the data, thus avoiding this situation entirely. Not all Makefiles do that, though.
Take this, for example:
https://codeberg.org/dwl/dwl/src/branch/main/Makefile#L64
The
install target of a Wayland compositor uses cp to copy the compiled binary to your bin directory. So, as of Linux 6.11, when you recompile this compositor and reinstall it, it will crash your entire Wayland session. 🧟💀🧟One way to avoid this crash is to use install instead of
cp. install calls unlink() before copying the data, thus avoiding this situation entirely. Not all Makefiles do that, though.
Take this, for example:
https://codeberg.org/dwl/dwl/src/branch/main/Makefile#L64
The
install target of a Wayland compositor uses cp to copy the compiled binary to your bin directory. So, as of Linux 6.11, when you recompile this compositor and reinstall it, it will crash your entire Wayland session. 🧟💀🧟One way to avoid this crash is to use install instead of
cp. install calls unlink() before copying the data, thus avoiding this situation entirely. Not all Makefiles do that, though.
- https://lwn.net/Articles/982034/
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a010c412853
> Matching the behavior of most Unix systems, the Linux kernel has traditionally prevented writes to an executable file that is in use by a process somewhere in the system; that is the source of the "text file busy" message that some readers may have seen. This restriction is intended to prevent unpleasant surprises in running programs. Kernel developers have been phasing out this restriction for a few years, mostly because it does not really protect anything. As of 6.11, the kernel will no longer prevent writes to busy executable files; see this changelog for a lot more details.
Hm.
- https://lwn.net/Articles/982034/
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a010c412853
> Matching the behavior of most Unix systems, the Linux kernel has traditionally prevented writes to an executable file that is in use by a process somewhere in the system; that is the source of the "text file busy" message that some readers may have seen. This restriction is intended to prevent unpleasant surprises in running programs. Kernel developers have been phasing out this restriction for a few years, mostly because it does not really protect anything. As of 6.11, the kernel will no longer prevent writes to busy executable files; see this changelog for a lot more details.
Hm.
- https://lwn.net/Articles/982034/
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a010c412853
> Matching the behavior of most Unix systems, the Linux kernel has traditionally prevented writes to an executable file that is in use by a process somewhere in the system; that is the source of the "text file busy" message that some readers may have seen. This restriction is intended to prevent unpleasant surprises in running programs. Kernel developers have been phasing out this restriction for a few years, mostly because it does not really protect anything. As of 6.11, the kernel will no longer prevent writes to busy executable files; see this changelog for a lot more details.
Hm.
- https://lwn.net/Articles/982034/
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a010c412853
> Matching the behavior of most Unix systems, the Linux kernel has traditionally prevented writes to an executable file that is in use by a process somewhere in the system; that is the source of the "text file busy" message that some readers may have seen. This restriction is intended to prevent unpleasant surprises in running programs. Kernel developers have been phasing out this restriction for a few years, mostly because it does not really protect anything. As of 6.11, the kernel will no longer prevent writes to busy executable files; see this changelog for a lot more details.
Hm.
text file busy. Example:First terminal:
$ cc -Wall -Wextra -o test test.c
$ cp test run
$ ./run
Second terminal:
$ cp test run
cp: cannot create regular file 'run': Text file busy
But on my machines today, it *crashes* the running program. 🤨 As soon as I run the
cp, I get a coredump:$ ./run
... time passes, I do "cp test run" in a second terminal ...
Bus error (core dumped)
How odd. Another mystery to solve …
text file busy. Example:First terminal:
$ cc -Wall -Wextra -o test test.c
$ cp test run
$ ./run
Second terminal:
$ cp test run
cp: cannot create regular file 'run': Text file busy
But on my machines today, it *crashes* the running program. 🤨 As soon as I run the
cp, I get a coredump:$ ./run
... time passes, I do "cp test run" in a second terminal ...
Bus error (core dumped)
How odd. Another mystery to solve …
text file busy. Example:First terminal:
$ cc -Wall -Wextra -o test test.c
$ cp test run
$ ./run
Second terminal:
$ cp test run
cp: cannot create regular file 'run': Text file busy
But on my machines today, it *crashes* the running program. 🤨 As soon as I run the
cp, I get a coredump:$ ./run
... time passes, I do "cp test run" in a second terminal ...
Bus error (core dumped)
How odd. Another mystery to solve …
text file busy. Example:First terminal:
$ cc -Wall -Wextra -o test test.c
$ cp test run
$ ./run
Second terminal:
$ cp test run
cp: cannot create regular file 'run': Text file busy
But on my machines today, it *crashes* the running program. 🤨 As soon as I run the
cp, I get a coredump:$ ./run
... time passes, I do "cp test run" in a second terminal ...
Bus error (core dumped)
How odd. Another mystery to solve …
@prologic I know that problem. 😃
@prologic I know that problem. 😃
@prologic I know that problem. 😃
@prologic I know that problem. 😃
https://www.youtube.com/watch?v=m4C58lmv1J4
https://www.youtube.com/watch?v=dlFrI8_Orys
https://www.youtube.com/watch?v=m4C58lmv1J4
https://www.youtube.com/watch?v=dlFrI8_Orys
https://www.youtube.com/watch?v=m4C58lmv1J4
https://www.youtube.com/watch?v=dlFrI8_Orys
https://www.youtube.com/watch?v=m4C58lmv1J4
https://www.youtube.com/watch?v=dlFrI8_Orys
This is the twt of @asquare I’m referring to:
> (#4w3ilsa) @prologic Actually, my twts from the last two days aren't showing up on
yarnd does a one-off fetch of any feed -mentioned by a pod member. Comments in the code suggest that this is the case, see internal/server.go, commit 7dcec70e, line 468. As the author of that code, can you confirm/deny?
This is the twt of @asquare I’m referring to:
> (#4w3ilsa) @prologic Actually, my twts from the last two days aren't showing up on
yarnd does a one-off fetch of any feed -mentioned by a pod member. Comments in the code suggest that this is the case, see internal/server.go, commit 7dcec70e, line 468. As the author of that code, can you confirm/deny?
This is the twt of @asquare I’m referring to:
> (#4w3ilsa) @prologic Actually, my twts from the last two days aren't showing up on
yarnd does a one-off fetch of any feed -mentioned by a pod member. Comments in the code suggest that this is the case, see internal/server.go, commit 7dcec70e, line 468. As the author of that code, can you confirm/deny?
This is the twt of @asquare I’m referring to:
> (#4w3ilsa) @prologic Actually, my twts from the last two days aren't showing up on
yarnd does a one-off fetch of any feed -mentioned by a pod member. Comments in the code suggest that this is the case, see internal/server.go, commit 7dcec70e, line 468. As the author of that code, can you confirm/deny?