[nos-bbs] removing stale tty lock files

[Michael Fox - N6MEF]

Hi Skip,

Fair points and good question.

Like you, we've found that if you plug in the USB-to-serial adapters one at
a time, and leave them alone after that, then the numbers don't change, even
across repeated reboots.

RE the rm command in the startup script:  Since JNOS already detects and
removed lock files, the question is why did that fail?  If we don't
understand that, then other rm commands might also fail for the same reason.


Some call me anal.  I'm not the typical linux hack who, from my experience,
throws solutions at problems like so much spaghetti against a wall.  In my
experience, that leads to patches upon patches and a tangled mess that is
not supportable by anyone other than the hacker himself.  I like to first
understand the problem I solve.  This results in solutions and/or workaround
which are much easier to support down the road.  And with multiple sysops
handling our network, it leads to less confusion and head scratching from
anyone who didn't write the patch.

So, since JNOS already detects and removes lock files, I'm trying to
understand why it didn't in this situation.  It may be that we need the
additional brute force rm command, or not.

RE putting the rm command in the OS script:  we have several machines in our
network and they don't all have the same tty port numbers.  So, again, for
manageability, we like to keep the startup scripts the same across all
machines.  If it turns out that an additional rm command is needed, a better
solution for us might be to put the command in autoexec.nos.  Something like
"shell rm -f file" would get it done and fail silently if the file doesn't
exist.  But the question remains why this would be needed at all, or if it
would even work under whatever conditions caused JNOS to not detect and/or
remove the lock file itself.  That's why understanding the failure mode is
so important.

Michael
N6MEF

-----Original Message-----
From: nos-bbs-bounces at tapr.org [mailto:nos-bbs-bounces at tapr.org] On Behalf
Of George [ham] VerDuin
Sent: Wednesday, February 23, 2011 8:03 AM
To: TAPR xNOS Mailing List
Subject: Re: [nos-bbs] removing stale tty lock files

I wonder Michael...


On 02/23/2011 10:03 AM, Michael Fox - N6MEF wrote:
>
> >>SNIP<< I stopped JNOS, manually removed the lock files, and then 
> restarted JNOS. All was well.
>
Referring to many examples on the web [including Maiko's posting], I see 
stale lock files removed prior to starting jnos. I do expect you have 
also seen this in your own work. We might see a series of statements in 
the OS start-up script like:
if [ -a file ]; then rm file; fi
where file is the whole path to the lock file that the upcoming jnos 
will establish as it opens new I/O paths. This makes the jnos feature 
redundant, and I suspect maybe it was a work-around for whatever answer 
Maiko has for your question. I'm glad you ask. I do wonder why you chose 
to skip the OS approach to removal... But that is not why I answer...

> >>SNIP<<
>
> 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).
>
RS-232 interfaces serviced by ttyS# are fully hardware dependent with 
stable numbers. USB technology is intentionally "hot pluggable" and the 
service by ttyUSB# is situational. If the devices are plugged in prior 
to OS boot time, then the # is set by the hardware service sequence and 
the same socket gets the same # each boot. But if the device is plugged 
in after boot time, then the # is assigned by the plug-in sequence 
selected by the operator no matter which socket is used. I wonder if you 
have discovered a way to sort this difference out so the ttyUSB# becomes 
stable?

In my case, I've written a document with a formula that says: "Plug the 
adapters in using the following sequence ..." where I specify BOTH the 
order of TNC/radio link and the computer socket to use. It is overly 
restrictive, but I have no better way now to set the jnos internal 
"attach" to the specific radio. It becomes hard to teach when the 
station hardware is modified from one configuration to another with a 
different radio lineup. This question IS why I answered your post.

THANKS!
Skip

_______________________________________________
nos-bbs mailing list
nos-bbs at tapr.org
https://www.tapr.org/cgi-bin/mailman/listinfo/nos-bbs