rickert@CS.NIU.EDU (Neil Rickert) (06/27/90)
Dale Courte <ncrlnk!wright!eve.wright.edu@uunet.uu.net> writes: > >A few strange things have occured since I installed Umax 4.3. I thought >I would post these and see if anyone else has had similar experiences. > >1) Every 15 minutes or so, tftpd (I guess) is creating a zero-length >file in /tmp. The files are named tftp.nnnnn, where nnnnn is an integer, >presumably a process number. I have put an entry in crontab to get rid >of these each night, but this is quite annoying. I can find nothing in >either the tftp, tftpd, or inetd man pages which would explain this >behavior. Is this normal? I would guess not, but I am at a loss as to >what I may have configured incorrectly. > This behaviour is not new to Umax 4.3. I had noticed (and reported it to Encore) in Umax 4.2/nfs. However I don't believe it is anything to be concerned about. Think of it as leaving a record of when 'tftp' was invoked. By all means, run a 'cron' job to clean these up. BUT - ONLY remove the files if they are empty. If they are not empty, you might want to see what is in them. Here at NIU we don't bother, because tftp is only infrequently used, so our regular cleanup of the /tmp directory is adequate. Here is what seems to be happening: When tftp is started up by inetd, it opens the file /tmp/tftp.pid as a log file, in which to record error messages. It then does a 'chroot' to the directory given in the -s option (you do use the -s option, I trust), then it does a 'setuid(-2)'. Usually tftp does not discover any problems, but if there are any they are written to the tftp.pid file in /tmp. One might hope that if there were no error messages, tftp would clean up after itself. But that is impossible, for after the 'chroot' and 'setuid' it can no longer remove that file. Rather more annoying, although also harmless, is the fact that 'catman' leaves behind a bunch of 'whatisxxxxx' files in /tmp. >2) Twice since intalling 4.3 my home directory has been altered so that >it is owned by root. I am the sysadmin, so often I do things in my dir >as root, but I find it hard to believe that twice I inadvertently >executed 'chown root ~dcourte'. Is there some change with 4.3 which >could cause some other event to change the ownership of a directory? I >am quite confused by this. > Are you sure you didn't do some restores from dump tapes to your directory? I certainly have not noticed anything like this. But then when I restore files from old dump tapes, I create a new directory for the 'restore -i'. I also always reply 'n' to the final prompt (change owner/mode of . y/n). =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Sci Dept, Northern Illinois U., DeKalb IL 60115 InterNet, unix: rickert@cs.niu.edu Bitnet, VM: T90NWR1@NIUCS =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
loverso@Xylogics.COM (John Robert LoVerso) (06/27/90)
> >1) Every 15 minutes or so, tftpd (I guess) is creating a zero-length > >file in /tmp. The files are named tftp.nnnnn, where nnnnn is an integer, > >presumably a process number. > > Here is what seems to be happening: > > When tftp is started up by inetd, it opens the file /tmp/tftp.pid > as a log file, in which to record error messages. Since these files are not normally created by any other tftpd, and UMAX's in.tfptd just comes from the Sun NFS3.2 distribution, I originally thought this might just be some debugging that was added but later forgotten about. Why this would be added was odd, because Sun's in.tfptd uses syslogging for extensive debugging and logging of tftpd activity. After checking the in.tftpd binary in UMAX4.3, I found that it had stub versions of the "openlog" and "syslog" functions. These stub versions just open and/or write to a file in /tmp instead of actually using the real syslog calls! A possible explanation for this might be that at the time the code was originally ported, UMAX4.2 was still in production and so they might not have wanted to deal with its old 4.2-style syslogd. Thus, this might just be a loose end that was missed before UMAX4.3 was released. However, in the meantime, instead of getting loggin from in.tftpd in syslog under the auth or daemon facilities, you'll just have to look for non-zero-length /tmp/tftp.$$ files! BTW, I've observed more than one UMAX machine at Encore with hundreds of the /tmp/tftp.$$ sitting around (presumably from X terminals booting). Maybe someone there will eventually notice it! John -- John Robert LoVerso Xylogics, Inc. 617/272-8140 x284 loverso@Xylogics.COM Annex Terminal Server Development Group