Bug#620622: minicom removes its own lockfile
Eugene Stemple
Version: 2.4-3
Severity: normal
When minicom is invoked for a RS-232 serial port, ttyS0, it creates a lockfile
/var/lock/LCK..ttyS0 as expected. However, when a file transfer is initiated
that lockfile is removed! For example, when an ASCII upload is started an
"ascii-xfr" task is started and for the duration of that text file transfer
there is no lockfile at all for the ttyS0 device. When the file transfer is
complete the lockfile returns (owned by minicom). I think this is happening
with the [x|y|z]modem file transfers also.
If the device at the receiving end of the serial path sends back any
character during the file transmission it is (apparently) redirected to
"mgetty" (listening by default for a serial device to connect on that tty
device) and mgetty then establishes a lockfile for the serial port.
When the ASCII file transmission completes, an error message is displayed,
"cannot create lockfile" and control returns to minicom (after pressing any
key, as prompted). minicom can't create a lockfile for the tty device
because mgetty now has it! The lockfile, and ownership, of the serial port
remains with mgetty. "mgetty" then issues a "login" message to the remote
terminal and attempts to get a user/password authentication. Any characters
returned from the remote terminal are randomly(?) directed to either mgetty
or minicom - probably a race since both programs think they own the serial
port.
The straightforward recovery is to exit minicom; then, from the remote
terminal either login and logout (to put mgetty back to sleep) or wait for
the login timeout to cycle. Then, if desired, restart minicom.
It seems like minicom should retain its lockfile when it spawns a file
transfer since the transfer programs don't create their own.
-- System Information:
Debian Release: 6.0
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages minicom depends on:
ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib
ii libncurses5 5.7+20100313-5 shared libraries for terminal hand
Versions of packages minicom recommends:
ii lrzsz 0.12.21-5 Tools for zmodem/xmodem/ymodem fil
minicom suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Adam Lackorzynski
Some do, some not. I think kermit is among those that require to have an
own lock file. I'm unsure how to solve this, even if lockfiles is
removed/not removed depending on the program started by minicom. A race
will be there when minicom removes it until the launched program is up.
Adam
--
Adam ad...@os.inf.tu-dresden.de
Lackorzynski http://os.inf.tu-dresden.de/~adam/