On Tue, Jan 13, 2026 at 07:43:08AM -0500, The Wanderer wrote:
> On 2026-01-13 at 02:57, [email protected] wrote:

[...]

> > Now trying to *edit the executable file in place* might get you a
> > -ETXTBSY (Text file busy). Another kettle of fish.
> 
> I don't think I've actually seen a reference to this (signal?) code before.

It is an errno. And it happens whenever the file is mmaped and serves
as backing store for the RAM (typically read-only). The system is lazy
(good for you!) and doesn't allocate anything else to back that RAM,
and it knows it can throw it out when under pressure, since it is
there to be paged in as needed. Happens with program text (and with
shared libs, which is basically the same).

Let's try...

as above: compile, start, then from another xterm:

  tomas@caliban:/tmp$ ls -al foo
  -rwxr-xr-x 1 tomas tomas 16008 Jan 13 14:18 foo

Aha. It's 16k. Let's overwrite its fifth 256B block:

  echo "catbert was here" | dd of=foo bs=256 seek=5
  dd: failed to open 'foo': Text file busy

...as I predicted (oof, sometimes it works out ;-)

To complete things:

  tomas@caliban:/tmp$ ps wwaux | grep foo
  tomas    30319  0.0  0.0   2468   868 pts/8    S+   14:18   0:00 ./foo
  tomas    30673  0.0  0.0   6864  2012 pts/3    S+   14:22   0:00 grep foo

Away with it:

  tomas@caliban:/tmp$ rm foo

  tomas@caliban:/tmp$ ls -alh /proc/30319/exe
  lrwxrwxrwx 1 tomas tomas 0 Jan 13 14:24 /proc/30319/exe -> '/tmp/foo 
(deleted)'

Aha. Can we resucitate it?

  cp /proc/30319/exe ./foo1

(I chose another name just for kicks).
(Note that I have to cp, since across filesystems). Now:

  tomas@caliban:/tmp$ ls -l foo1
  -rwxr-xr-x 1 tomas tomas 16008 Jan 13 14:26 foo1
  tomas@caliban:/tmp$ file foo1
  foo1: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically 
linked,
          interpreter /lib64/ld-linux-x86-64.so.2,
          BuildID[sha1]=33e0c4219a6ae687645c3f648ac478ca9b269f25,
          for GNU/Linux 3.2.0, not stripped

This looks good. Now CTRL-C the proogram, and...

  tomas@caliban:/tmp$ ./foo1
  Hello 0
  Hello 1
  ...

Resucitation successful.

I once heard that story of someone rm -rf-ing /, then stopping in panic, but 
/bin/sh
was gone, then rescueing it this way. Or was it /lib/libc-whatever?

Now I tried it myself :)

Enjoy
-- 
tomás

Attachment: signature.asc
Description: PGP signature

Reply via email to