<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
Michael:<BR>
<BR>
In my STARTNOS file, I run the following commands "before" executing JNOS.<BR>
-------------------------------------------------------------<BR>
rm -f /jnos/spool/mqueue/*.lck 2> /dev/null<BR>
rm -f /jnos/spool/mail/*.lck 2> /dev/null<BR>
-------------------------------------------------------------<BR><BR>
This releases any locks that might be there. <BR>
<BR>
Here in snow country, I can get (and do get) power outages that cause a lock state to happen when the power fails.<BR>
<BR>
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.<BR>
<BR>
This should help you. <BR>
<BR>
Bill<BR>
<BR>
<BR>
<BR>
> From: n6mef@mefox.org<BR>> To: nos-bbs@tapr.org<BR>> Date: Wed, 23 Feb 2011 08:51:36 -0800<BR>> Subject: Re: [nos-bbs] removing stale tty lock files<BR>> <BR>> Hi Skip,<BR>> <BR>> Fair points and good question.<BR>> <BR>> Like you, we've found that if you plug in the USB-to-serial adapters one at<BR>> a time, and leave them alone after that, then the numbers don't change, even<BR>> across repeated reboots.<BR>> <BR>> RE the rm command in the startup script: Since JNOS already detects and<BR>> removed lock files, the question is why did that fail? If we don't<BR>> understand that, then other rm commands might also fail for the same reason.<BR>> <BR>> <BR>> Some call me anal. I'm not the typical linux hack who, from my experience,<BR>> throws solutions at problems like so much spaghetti against a wall. In my<BR>> experience, that leads to patches upon patches and a tangled mess that is<BR>> not supportable by anyone other than the hacker himself. I like to first<BR>> understand the problem I solve. This results in solutions and/or workaround<BR>> which are much easier to support down the road. And with multiple sysops<BR>> handling our network, it leads to less confusion and head scratching from<BR>> anyone who didn't write the patch.<BR>> <BR>> So, since JNOS already detects and removes lock files, I'm trying to<BR>> understand why it didn't in this situation. It may be that we need the<BR>> additional brute force rm command, or not.<BR>> <BR>> RE putting the rm command in the OS script: we have several machines in our<BR>> network and they don't all have the same tty port numbers. So, again, for<BR>> manageability, we like to keep the startup scripts the same across all<BR>> machines. If it turns out that an additional rm command is needed, a better<BR>> solution for us might be to put the command in autoexec.nos. Something like<BR>> "shell rm -f file" would get it done and fail silently if the file doesn't<BR>> exist. But the question remains why this would be needed at all, or if it<BR>> would even work under whatever conditions caused JNOS to not detect and/or<BR>> remove the lock file itself. That's why understanding the failure mode is<BR>> so important.<BR>> <BR>> Michael<BR>> N6MEF<BR>> <BR>> -----Original Message-----<BR>> From: nos-bbs-bounces@tapr.org [mailto:nos-bbs-bounces@tapr.org] On Behalf<BR>> Of George [ham] VerDuin<BR>> Sent: Wednesday, February 23, 2011 8:03 AM<BR>> To: TAPR xNOS Mailing List<BR>> Subject: Re: [nos-bbs] removing stale tty lock files<BR>> <BR>> I wonder Michael...<BR>> <BR>> <BR>> On 02/23/2011 10:03 AM, Michael Fox - N6MEF wrote:<BR>> ><BR>> > >>SNIP<< I stopped JNOS, manually removed the lock files, and then <BR>> > restarted JNOS. All was well.<BR>> ><BR>> Referring to many examples on the web [including Maiko's posting], I see <BR>> stale lock files removed prior to starting jnos. I do expect you have <BR>> also seen this in your own work. We might see a series of statements in <BR>> the OS start-up script like:<BR>> if [ -a file ]; then rm file; fi<BR>> where file is the whole path to the lock file that the upcoming jnos <BR>> will establish as it opens new I/O paths. This makes the jnos feature <BR>> redundant, and I suspect maybe it was a work-around for whatever answer <BR>> Maiko has for your question. I'm glad you ask. I do wonder why you chose <BR>> to skip the OS approach to removal... But that is not why I answer...<BR>> <BR>> > >>SNIP<<<BR>> ><BR>> > I've been trying to duplicate the problem on a different machine <BR>> > (which I have better access to) which uses USB-to-serial converters <BR>> > (ttyUSB0, ttyUSB1, ttyUSB2).<BR>> ><BR>> RS-232 interfaces serviced by ttyS# are fully hardware dependent with <BR>> stable numbers. USB technology is intentionally "hot pluggable" and the <BR>> service by ttyUSB# is situational. If the devices are plugged in prior <BR>> to OS boot time, then the # is set by the hardware service sequence and <BR>> the same socket gets the same # each boot. But if the device is plugged <BR>> in after boot time, then the # is assigned by the plug-in sequence <BR>> selected by the operator no matter which socket is used. I wonder if you <BR>> have discovered a way to sort this difference out so the ttyUSB# becomes <BR>> stable?<BR>> <BR>> In my case, I've written a document with a formula that says: "Plug the <BR>> adapters in using the following sequence ..." where I specify BOTH the <BR>> order of TNC/radio link and the computer socket to use. It is overly <BR>> restrictive, but I have no better way now to set the jnos internal <BR>> "attach" to the specific radio. It becomes hard to teach when the <BR>> station hardware is modified from one configuration to another with a <BR>> different radio lineup. This question IS why I answered your post.<BR>> <BR>> THANKS!<BR>> Skip<BR>> <BR>> _______________________________________________<BR>> nos-bbs mailing list<BR>> nos-bbs@tapr.org<BR>> https://www.tapr.org/cgi-bin/mailman/listinfo/nos-bbs<BR>> <BR>> <BR>> _______________________________________________<BR>> nos-bbs mailing list<BR>> nos-bbs@tapr.org<BR>> https://www.tapr.org/cgi-bin/mailman/listinfo/nos-bbs<BR> </body>
</html>