ddrescue: no status screen, no mapfile, no logfile

[address@hidden]

Dear All,

Every few years or so (I have only a few machines to maintain), I have
occasion to use ddrescue, Today I see something
that I cannot explain from the docu. Do you have any advice? I numbered
parts of my text for easier reference.
Thank you,
Jan

Problem title: no status screen, no mapfile, no logfile

Brief description: (details below):

  ddrescue <some other options --log-events=<file> <input partition>
  <outputfile> <mapfile>

(1) does not produce any output to screen (no "Gnu ddrescue 1.23 \nPress Ctrl-C
to interrupt", no progress display with bytes read/written etc.). Nothing.

(2) Moreover, there is no trace of the mapfile or the logfile
(in the current working directory) and "lsof ddresc" shows
(besides some glibc files) only the <input partition>
and <outputfile> as open files for ddrescue (and file descriptors
0, 1, 2 to /dev/tty1, which is the termninal where I am logged in.)

(3) The <outputfile> is slowly growing (now about 300GB, after 16 hours, i.e. 
7MB/s),
but without mapfile it is not possible to have a next run for scraping. And
I have no information how many bad sectors were encountered.

(4) I am running as root under the systemd-"sulogin" rescue shell.
When I am experimenting with the same command (other, smaller <inputfile> and
<outputfile>) on another (healthy ) machine, everything works as expected.
But that is a machine in multiuser state (run level 5), with a desktop
pts-terminal, not a /dev/tty, even though that should not matter (?)

Details:
(5) version:   ddrescue v1.23 on ubuntu linux 20.04.6

(6) full cmd line, the below script is invoked from bash shell:

#!/usr/bin/bash
fn=m16homecopy1
echo ddrescue --idirect --no-scrape --retry=passes=0 --preallocate 
--synchronous \
  --log-events=$fn.log \
  /dev/sdb1 /media/ikke/EB1/$fn.bin $fn.map
#end of script

(7) the input is the /home partition, which has its own disk; the output is
to a file on an USB 3.0 HDD, which flashes its LED a few times /sec.

(8) considerations:
the --preallocate was applied to verify whether the "huge file" extended
file attribute of the ext2 file system of <outputfile> disk was working
I checked with ps -f that the script was expanded as I had intended.
I did not use absolute paths for mapfile and logfile, but the process has 
a "normal" current working directiry.

(9) I am not inclined to disconnect the "whacky drive" and bring it to another
computer. I can restart, using a live USB linux distro, if the sulogin-shell
is the problem, but first I would like to know whatś wrong.