# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 40
# self = https://watcher.sour.is/conv/d7y2eka
When you try to change a file that’s currently running, it used to say 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 …
When you try to change a file that’s currently running, it used to say 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 …
When you try to change a file that’s currently running, it used to say 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 …
When you try to change a file that’s currently running, it used to say 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 …
@movq Is this on a particular Kernel version? 🤔
@movq Is this on a particular Kernel version? 🤔
@prologic I haven’t narrowed it down yet. I’m running 6.11.4 at the moment.
@prologic I haven’t narrowed it down yet. I’m running 6.11.4 at the moment.
@prologic I haven’t narrowed it down yet. I’m running 6.11.4 at the moment.
@prologic I haven’t narrowed it down yet. I’m running 6.11.4 at the moment.
This changed between linux-6.10.10.arch1-1 and linux-6.11.arch1-1 … Don’t have the time now to do a proper bisect. 🫤
This changed between linux-6.10.10.arch1-1 and linux-6.11.arch1-1 … Don’t have the time now to do a proper bisect. 🫤
This changed between linux-6.10.10.arch1-1 and linux-6.11.arch1-1 … Don’t have the time now to do a proper bisect. 🫤
This changed between linux-6.10.10.arch1-1 and linux-6.11.arch1-1 … Don’t have the time now to do a proper bisect. 🫤
@movq Sounds like you'll be submitting a bug report upstream though at some point when you have time? 🤔
@movq Sounds like you'll be submitting a bug report upstream though at some point when you have time? 🤔
It’s intentional:
- 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.
It’s intentional:
- 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.
It’s intentional:
- 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.
It’s intentional:
- 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.
Not sure I’m happy with this.
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.
Not sure I’m happy with this.
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.
Not sure I’m happy with this.
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.
Not sure I’m happy with this.
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.
Just tried it: It did indeed crash my Wayland session and, since Wayland compositors are sensitive and critical, it froze all input devices. Only way to recover was to SSH into that machine and reboot it. 🤦
Just tried it: It did indeed crash my Wayland session and, since Wayland compositors are sensitive and critical, it froze all input devices. Only way to recover was to SSH into that machine and reboot it. 🤦
Just tried it: It did indeed crash my Wayland session and, since Wayland compositors are sensitive and critical, it froze all input devices. Only way to recover was to SSH into that machine and reboot it. 🤦
Just tried it: It did indeed crash my Wayland session and, since Wayland compositors are sensitive and critical, it froze all input devices. Only way to recover was to SSH into that machine and reboot it. 🤦
I guess the question now becomes;
> Why does it cause the running process to crash?
I guess the question now becomes;
> Why does it cause the running process to crash?
@movq In our case at work the new behavior can indeed be considered an improvement. systemd would then restart the new version automatically if the old one crashed. Still, crashing in the first place is very uncool. We don't have a recent enough kernel version, though.
I *guess* crashing the program with a SIGBUS is intentional. Here’s a blog post that describes this exact thing when running binaries off of NFS:
https://rachelbythebay.com/w/2018/03/15/core/
It’s just that this also happens locally nowadays and, thus, much easier and more often (I bet few people run programs via NFS these days). 🫤
Not a fan of this. (Time will tell if I have the energy to discuss this on the Linux kernel mailing list.)
I *guess* crashing the program with a SIGBUS is intentional. Here’s a blog post that describes this exact thing when running binaries off of NFS:
https://rachelbythebay.com/w/2018/03/15/core/
It’s just that this also happens locally nowadays and, thus, much easier and more often (I bet few people run programs via NFS these days). 🫤
Not a fan of this. (Time will tell if I have the energy to discuss this on the Linux kernel mailing list.)
I *guess* crashing the program with a SIGBUS is intentional. Here’s a blog post that describes this exact thing when running binaries off of NFS:
https://rachelbythebay.com/w/2018/03/15/core/
It’s just that this also happens locally nowadays and, thus, much easier and more often (I bet few people run programs via NFS these days). 🫤
Not a fan of this. (Time will tell if I have the energy to discuss this on the Linux kernel mailing list.)
I *guess* crashing the program with a SIGBUS is intentional. Here’s a blog post that describes this exact thing when running binaries off of NFS:
https://rachelbythebay.com/w/2018/03/15/core/
It’s just that this also happens locally nowadays and, thus, much easier and more often (I bet few people run programs via NFS these days). 🫤
Not a fan of this. (Time will tell if I have the energy to discuss this on the Linux kernel mailing list.)
@movq allow me to stump you! Our Oracle team runs scripts, java, and a few others from NFS shares. That has become a true problem when VMs have moved to Azure, and NFS servers remain on premises. NFS doesn't like latency, especially when laced with high I/O activity.
@bender Consider me stumped! 😅 Yeah, I can imagine this not being super fast. 🥴
@bender Consider me stumped! 😅 Yeah, I can imagine this not being super fast. 🥴
@bender Consider me stumped! 😅 Yeah, I can imagine this not being super fast. 🥴
@bender Consider me stumped! 😅 Yeah, I can imagine this not being super fast. 🥴