[nos-bbs] removing stale tty lock files

[Wm Lewis]

Michael:
 
In my STARTNOS file, I run the following commands "before" executing JNOS.
-------------------------------------------------------------
rm -f /jnos/spool/mqueue/*.lck 2> /dev/null
rm -f /jnos/spool/mail/*.lck 2> /dev/null
-------------------------------------------------------------

This releases any locks that might be there. 
 
Here in snow country, I can get (and do get) power outages that cause a lock state to happen when the power fails.
 
After rebooting JNOS after a power failure (using STARTNOS) I watch the bootup and see a report of the locks being there, and being removed.
 
This should help you. 
 
Bill
 
 
 
> From: n6mef at mefox.org
> To: nos-bbs at tapr.org
> Date: Wed, 23 Feb 2011 08:51:36 -0800
> Subject: Re: [nos-bbs] removing stale tty lock files
> 
> 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
> 
> 
> _______________________________________________
> nos-bbs mailing list
> nos-bbs at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/nos-bbs
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/nos-bbs_lists.tapr.org/attachments/20110223/25a75f63/attachment.html>