<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Bill,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>My email was about tty lock files in /var/lock.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>M<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='margin-left:.5in'><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> nos-bbs-bounces@tapr.org [mailto:nos-bbs-bounces@tapr.org] <b>On Behalf Of </b>Wm Lewis<br><b>Sent:</b> Wednesday, February 23, 2011 10:57 AM<br><b>To:</b> nos-bbs@tapr.org<br><b>Subject:</b> Re: [nos-bbs] removing stale tty lock files<o:p></o:p></span></p></div></div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>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<o:p></o:p></span></p></div></body></html>