On Sat Apr 02, 2011 at 21:32:34 -0700, Eugene Stemple wrote: > 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.
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 [email protected] Lackorzynski http://os.inf.tu-dresden.de/~adam/ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
