[nos-bbs] removing stale tty lock files

[Michael Fox - N6MEF]

I recently had a situation where JNOS failed to start up correctly due to
some stale tty lock files.  As JNOS executed the various commands in the
autoexec.nos file, it kept reporting that the port(s) did not exist.  After
JNOS came up (with no ports), I issued the attach command at the console
prompt and got a message that the tty was locked.  This led me to check
/var/lock/ and I found lock files for each of my serial interfaces
(LCK..ttyS0, LCK..ttyS2, LCK..ttyS3).  I stopped JNOS, manually removed the
lock files, and then restarted JNOS.  All was well.

 

I'm pretty sure that I had previously unplugged power from that machine
(without shutting down JNOS or Linux) before this occurred.  

 

I've been trying to duplicate the problem on a different machine (which I
have better access to) which uses USB-to-serial converters (ttyUSB0,
ttyUSB1, ttyUSB2).  If I startup JNOS, then Kill -9 the jnos process, the
lock files are left in the /var/lock directory.  But a subsequent startup of
JNOS removes them.  On the console, one can observe the copyright message,
followed by:

 

Removing stale lockfile for ttyUSB0

Removing stale lockfile for ttyUSB1

Removing stale lockfile for ttyUSB2

 

Followed by the usual display of the KISS parameters being set for each of
the TNCs.  

 

So, it seems that JNOS is smart enough to remove lock files.  Except it
didn't do it in the case above.  I can't imagine that JNOS would care
whether it's a real serial port (such as the case above where it didn't
remove the lock files) or a usb-to-serial converter (such as the case above
where it DID remove the lock files).  But stranger things have happened.
But clearly there are conditions under which JNOS does not try to or is not
able to remove the lock files.

So, I'm trying to figure out what those conditions are and how to remedy
that so it doesn't happen again.  

 

Maiko:  can you determine when an existing lock file would NOT be removed by
JNOS?  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/nos-bbs_lists.tapr.org/attachments/20110223/47dc3e1f/attachment.html>