This email is purely to lock this info into the collective memory of the web.
So I cloned a Fedora 18 box yesterday, and the original was quite happy to run minicom, but the copy was not. [root@ttt02 dev]# minicom -D /dev/ttyS0 Device /dev/ttyS0 lock failed: No such file or directory. There was plenty of suggestions saying that there was a stale lock file and to delete it, but that didn't help cos it wasn't the problem. Seems this is the older way of minicom doing lockfiles. |# minicom Device /dev/ttyS0 is locked.|| # rm /var/tmp/LCK..ttyS0| One might take "No such file or directory" to mean there's a problem with the /dev/ entry..... but this also was not the case. All the owner/group and permissions are correct, and we;re running minicom as root anyway [root@ttt02 run]# ls -la /dev/ttyS* crw-rw---- 1 root dialout 4, 64 Feb 12 12:16 /dev/ttyS0 crw-rw---- 1 root dialout 4, 65 Feb 12 09:31 /dev/ttyS1 In the end, it was a "strace minicom | grep lock" that pointed to liblockdev.so.0 being called. It wasn't a lockfile, it was a separate process being called to lock the device. There's a cli command lockdev that does the same thing, so this was before [root@ttt02 dev]# /usr/sbin/lockdev /dev/ttyS0 <-- get the status of the lock on this device [root@ttt02 dev]# echo $? <-- error level shows the actual result 130 <-- man page for lockdev doesn't even show this [root@ttt02 dev]# /usr/sbin/lockdev -u /dev/ttyS0 <-- unlock it [root@ttt02 dev]# echo $? <-- What happen? 0 <-- Success at unlocking [root@ttt02 dev]# /usr/sbin/lockdev /dev/ttyS0 <-- get status again [root@ttt02 dev]# echo $? <-- make speak answer 12 <-- man page says this is EPERM Ah ha! Some lock directory is having a problem. Turns out that these directories were munted and needed recreating /var/run/lock Doesn't need to exist /var/lock Should be a symlink to /run/lock /run/lock The real lockdir drwxr-xr-x 8 root root 160 Feb 12 12:01 /run/lock lrwxrwxrwx 1 root root 12 Feb 12 11:58 /var/lock -> ../run/lock/ And now minicom runs perfectly. The misleading thing is that screen /dev/ttyS0 worked perfectly the whole time, but screen doesn't implement any locking so the problem never appeared. -- Criggie http://criggie.org.nz/
_______________________________________________ Linux-users mailing list Linux-users@lists.canterbury.ac.nz http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
