Description of problem: Minicom has a locking feature that should allow to avoid having multiple sessions accessing a single tty port (normally /dev/ttyS0). The recently made available minicom package evidently does not create such a lock Version-Release number of selected component (if applicable): minicom-2.5-1.mga1 How reproducible: 100% Steps to Reproduce: 1. from a console start minicom 2. from another console try to start minicom 3. that should be rejected with an error message, but is not, I get 2 sessions which disorderly access the tty-port. Doing "Ctrl-A/O -> Serial port setup" displays that the lockfile is /var/lock/tty as the lockfile (i.e the default configuration), but "ls -la /var/lock/tty" shows that no lock file exists in that directory. Background / history -------------------- In past (Mandriva) releases, there was a small bug: minicom created the lock file directly in /var/lock (disregarding the configuration established by minicom ->Ctrl-A/Z ...) - which immediately resulted in the failure of minicom to start since /var/lock belonged to root:uucp (minicom belongs to root:dialout); changing ownership of /var/lock to root:dialout therefore provided a -for me - satisfactory workaround. ( ls -la /var/lock illustrated that minicom created 3 lock-files in that directory) Ugly, but allowing to work with minicom with a safeguard against locking. I did not file a bug since it works perfectly for me and I do not think that minicom has many users. In the new implementation that is now available in mageia, I do not need to modify the ownership of /var/lock any more since minicom does not try to create a lock file at all - a situation which is dangerous: no more locking against accidental multiple access to minicom. Note: minicom may look like a somewhat archaic tool - using Unix tools (avr tool chain) for doing microprocessor software developement, minicom is essential for displaying data sent from the serial port of the microprocessor. Reproducible: Steps to Reproduce:
I have now looked at the SRPM and found a fix - see the patch in the attachment There appear to be 2 problems, both created in the file minicom-2.5/configure 1. Bad lock directory (/var/lock rather than /var/lock/tty) - configure finds the directory for the lock file by serially exploring a list of directory names hardwired into the code of configure - the lock directory is set to the first directory of that list which exists - the list of directory files (line #7720 of configure) does not contain /var/lock/tty. This is fixed by correcting the list of directory names in line #7720 and adding "/var/lock/tty" BEFORE "/var/lock" 2. Bad lock file name - minicom derives the name of the lockfile from the name of the device for serial IO - again, configure does this by scanning a list of device names and deciding on the first one that exists - that list contains /dev/ttyS1 - on my laptop ttyS0 through ttyS3 exist as nodes in /dev - therefore minicom uses ttyS1 - but, physically, my system configures its serial device on /dev/ttyS0 - before creating the lockfile, minicom checks (main.c) for the physical existance of the device and - since there is no physical /dev/ttyS1 on my machine - the creation of the lockfile fails. I patched this by modifying the name in the list of serial devices scanned by configure from /dev/ttyS1 to /dev/ttyS0. This is only a quick fix, the correct solution would be to replace the scan for node names by a scan for existing devices - I doubt whether this is worth while. There appears to be a fundamental problem in the implementation of minicom: the "configure" mechanism is not really compatible with the design of the dynamic configuration mechanism in minicom. But again, probably not worth while to invest time. There is a third thing that needs to be corrected: 3. /var/lock/tty must have ownership root:dialout (and not root:uucp). Again, somewhat problematic in case there is software around that expects the old ownership of the tty directory - but, is uucp still in use? Making these 3 changes, minicom works with locking as it should But I will start looking for another terminal emulator (-
Created attachment 95 [details] patch for fixing the problem as described in the comment I practically never used diff and patch - I used "diff -u". I hope that this is OK
Appears to have been fixed in minicom 2.5-2
tks closing
Status: NEW => RESOLVEDCC: (none) => dmorganecResolution: (none) => FIXEDSource RPM: minicom-2.5-1.mga1 => minicom