?? LCK..tty1a: 25371 ??

[bfloyd]

The following message is sent to the root mailbox a couple of times every day. What does it mean?

LCK..tty1a: 25371
F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY
TIME CMD

 

[apeasecpc]

I get messages similar to this when uucp dials out over a modem to transmit a file. You have a user or a cron process that is doing a uucico call at the times the messages are posted.

The LCKs are identifying which modems were locked at the time of the uucp connection, and the process IDs for those locks.

The line below the LCKs is a header line for some kind of status printout. The absence of any status data below that line means that there was no information to report.

 

[joen]

What are you using tty1a for? Is a modem attach to it?

 

[bfloyd]

The modem is on tty1A. I don't think anything is on tty1a; I am not sure how to check. But if this message is not an error message, I imagine I could just ignore it, right?

 

[apeasecpc]

It probably isn't an error, but you shouldn't ignore it until you figure out why it is happening. Do you have any processes or crons running which do a uucp connection over your modem?

 

[drtrinidad]

The message is the output of 'uustat -p' and it's probably being called from /usr/lib/uucp/uudemon.admin - if you look at uucp's crontab entry ( crontab -l -u uucp ) I expect you'll see something like

48 10,14 * * 1-5 /usr/lib/uucp/uudemon.admin > /dev/null

The same lock file is used for tty1A and tty1a, so it probably does refer to your modem. As apeasecpc mentioned, the number after the LCK..tty1a is the process ID - you could look at that to see what it trying to talk to your modem.

 

[bfloyd]

crontab -l -u uucp produces the following:

39,9 * * * * /usr/lib/uucp/uudemon.hour > /dev/null
10 * * * * /usr/lib/uucp/uudemon.poll > /dev/null
45 23 * * * ulimit 5000; /usr/lib/uucp/uudemon.clean > /dev/null
48 10,14 * * 1-5 /usr/lib/uucp/uudemon.admin > /dev/null

Do I need to do anything about this?

 

[drtrinidad]

It occurs to me now that since there is no actual process info listed below the column headings, the lock file is probably orphaned. If you do

ls -l /usr/spool/uucp/LCK..tty1a

you'll probably see it's quite old. The file just contains the PID of the process which created the lock, and since that process is no longer active you should be able to remove the file. I'd remove it without hesitation if it's days old.

This should get rid of the recurring email, unless you have some modem problem that keeps recreating the lock.

 

[bfloyd]

Here is what I get:

#ls -l /usr/spool/uucp/LCK..tty1a
ls: /usr/spool/uucp/LCK..tty1a not found: No such file or directory (error 2)
#

We have 2 SCO servers: one 5.0.5, the other 5.0.6, with the same entry in the crontab files.
(48 10,14 * * 1-5 /usr/lib/uucp/uudemon.admin > /dev/null)
The 5.0.5 server doesn't get the LCK message. 5.0.6 gets the message at (surprise) 10:48 am and 2:48 pm.

 

[apeasecpc]

No the lock file is not an orphaned process. When uucp dials out over the modem it is normal for a lock file to be created, and then later removed when the call is complete.

uucico is being called by the "10 * * * * /usr/lib/uucp/uudemon.poll > /dev/null" cron entry, which is was created as part of the uucp configuration. This is an expected normal cron entry that you should leave alone. Uucp is used for a wide variety of file transfers including e-mail. Uucp works similar to printing in that a program or user sends a job to the uucp queue, which is then processed by uucp. The uucp cron entries are simply there for managing the queue, they are not the cause of the uucp job you are trying to identify. See the uudemon man page.

To look for clues as to the source of the uucp call, check the /usr/lib/uucp/Systems and /usr/lib/uucp/Permissions files. Hopefully you will recognize one of the listings as the reason for your uucp jobs.

 

[bfloyd]

The file /usr/lib/uucp/Systems has all the lines commented out (# is the first character).
What should I be looking for in Permissions?

MACHINE=samplesite LOGNAME=uucp COMMANDS=rmail:rnews:uucp READ=/usr/spool/uucppublic:/usr/tmp WRITE=/usr/spool/uucppublic:/usr/tmp SENDFILES=yes REQUEST=no
# The following entry is for the Santa Cruz Operation Technical Support
# bulletin board.
MACHINE=sosco LOGNAME=uusls COMMANDS=rmail:rnews:uucp READ=/usr/spool/uucppublic:/usr/tmp:/tmp WRITE=/usr/spool/uucppublic:/usr/tmp:/tmp SENDFILES=yes REQUEST=no
# The following entry is for the Santa Cruz Operation Technical Support
# bulletin board in Europe.
MACHINE=scolon LOGNAME=uusls COMMANDS=rmail:rnews:uucp READ=/usr/spool/uucppublic:/usr/tmp:/tmp WRITE=/usr/spool/uucppublic:/usr/tmp:/tmp SENDFILES=yes REQUEST=no
#

 

[apeasecpc]

I am a little confused now because Systems file doesn't contain any dialup scripts, and your Permissions file only has permissions for the basic SCO default settings.

What result do you get when you run the command "uustat -m"?
What result do you get when you run the command "uulog"?

 

[drtrinidad]

Don't forget, the LCK..xx files are used not just by uucp, but by cu, ct, getty, Morningstar PPP... normally the output of uustat -p would use the PID to show the process which created it, and the absence of that is what made me think some process terminated abnormally and left it there.

But if the file doesn't exist when you look for it, but does exist at 10:48 am and 2:48 pm I don't know where it's coming from. Technically it's in /var/spool/uucp but /usr/spool should be a symbolic link to /var/spool.

If you feel like typing more commands after uustat -m, etc. I'd be interested in seeing the output of:

uustat -a
ls -li /*/spool/uucp/LCK*
uustat -p
grep 1[aA] /etc/inittab

FWIW, while typing this post I had to remove an orphaned lock file, but for a system name, not a device name - it happens sometimes when our ISP drops the connection (we do uucp over tcpip). I've only had to remove LCK..tty1a after doing kill -9 on a modem process.

Details:
# uustat -p
LCK..akron: 19334
F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD

# ls -l /usr/spool/uucp/LCK..akron
-r--r--r-- 1 uucp uucp 11 Jan 23 08:07 /usr/spool/uucp/LCK..akron

#date
Thu Jan 23 10:37:27 EST 2003

 

[bfloyd]

I typed in all the commands suggested by apeasecpc and drtrinidad (below)
I get this message in mail to root; I have never seen an actual file. (Never looked for it.) This is the most recent one:
From sco2!uucp Mon Jan 13 10:48:01 2003
From: UUCP administrator <uucp@sco2>
X-Mailer: SCO OpenServer Mail Release 5.0
To: uucp@sco2
Subject: uu-status
Date: Mon, 13 Jan 2003 10:48:01 -0500 (EST)
Message-ID: <200301131048.aa25900@sco2.>
Status: RO

LCK..tty1a: 25566
F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY
TIME CMD

apeasecpc's commands:
sco2 #uustat -m
sco2 #uulog
sco2 #

drtrinidad's commands:
sco2 #uustat -a
sco2 #

sco2 #ls -li /*/spool/uucp/LCK*
ls: /*/spool/uucp/LCK* not found: No such file or directory (error 2)

sco2 #grep 1[aA] /etc/inittab
Se1a:234ff:/etc/getty tty1a m
Se1A:234:respawn:/etc/getty -t60 tty1A q

sco2 #uustat -p
sco2 #

sco2 #pwd
/var/spool/uucp
sco2 #ls -l LCK*
ls: LCK* not found: No such file or directory (error 2)
sco2 #

 

[apeasecpc]

That confirms that it isn't a uucp process. Your inittab looks like you have the port configured to accept dialins, so probably someone was dialed in at the time the uucp cron process ran. According to your root mail this was at 10:48 a.m. on a Monday morning. Do you have users who sometimes dial in to your server during normal business hours?

 

[drtrinidad]

Given that the last time the email showed up was ten days ago, I'm less surprised the file doesn't exist ;-)

I'm guessing the computer has been rebooted since Jan 13 - the lock files are removed by /etc/rc2.d/P70uucp (at least in 5.0.5).

I'd say that just as you said on Jan 15, you can ignore this message. As long as your modem is working for whatever you need it for, it should be no problem.

 

[bfloyd]

Some of our major software is still being &quot;tweaked&quot; and the company dials in frequently (daily) to fix bugs.
It is possible that the server was rebooted since Jan. 13. I seem to remember rebooting not too long ago.........

Thanks for all the help, apeasecpc and drtrinidad. I am glad someone knows more about this than I do!

 

[mightyscotchpine]

Don't forget that there could be LCK files in /usr/spool/locks as well.