burzio@mmlai.UUCP (Tony Burzio) (07/27/90)
Came upon an interesting problem. I am using an HP375 running HP-UX V7.0 X11 hpterms with the ksh shell. The operating system is the pre-loaded variety, with the cute login window and xctl application launcher. Every so often, the .sh_history will start to grow very large. After a while (with the SCSI disk blinking away) the disk will fill up completely. The operator console merrily tells me the disk is full (oh be quiet, I KNOW! :-) To fix the problem, I delete the .sh_history, but the disk usage (from bdf) doesn't drop until a reboot is performed. I didn't see any other processes running, and the file wasn't locked. Has anyone else seen this happen? ********************************************************************* Tony Burzio * Setting sail on the Minnow II... Martin Marietta Labs * mmlai!burzio@uunet.uu.net * *********************************************************************
jack@hpindda.HP.COM (Jack Repenning) (07/29/90)
In comp.sys.hp, burzio@mmlai.UUCP (Tony Burzio) writes: > To fix the problem, I delete the .sh_history, but the disk usage > (from bdf) doesn't drop until a reboot is performed. I didn't see > any other processes running, and the file wasn't locked. > > Has anyone else seen this happen? Haven't seen it, but another question occurs to me: have you tried exiting all ksh's (for example, logging out all sessions, or going to single-user mode and ^D'ing that shell [if root's shell is ksh])? I'm not clear on exactly what you meant by "other processes," but I share your suspicion that some process has the history file open, and hence rm doesn't really remove it, only unlinks it from the directory. ------------------------------------------------------------- Jack Repenning - Information Networks Division, Hewlett Packard Company RFC-822: jack@hptnjar.cup.hp.com uucp: ...!hplabs!hptnjar!jack USMail: 43LN; 19420 Homestead Ave; Cupertino, CA 95014 Phone: 408/447-3380 ------------------------------------------------------------- By the way, netnews is a very slow and capricious way to get questions answered. If you have either HP TeamLine or HP ResponseLine software support services, you can direct questions about supported HP products to your regional HP Response Center. HP people who respond to netnews questions are donating our time. We do not have the full resources of a Response Center at our disposal, and the person who knows the answer to any given question may not be reading news this week, or month, or...
nick@bischeops.UUCP (Nick Bender) (07/30/90)
In article <4@gauss.mmlai.UUCP>, burzio@mmlai.UUCP (Tony Burzio) writes: > > Every so often, the .sh_history will start to grow very large. After > a while (with the SCSI disk blinking away) the disk will fill up > completely. The operator console merrily tells me the disk is full > (oh be quiet, I KNOW! :-) To fix the problem, I delete the .sh_history, > but the disk usage (from bdf) doesn't drop until a reboot is performed. > I didn't see any other processes running, and the file wasn't locked. Disk space allocated to a file is not reclaimed until there are no *references* to the file. What constitutes a reference? A directory entry or a process with an open file descriptor. Thus if you have a program (a shell for example) with an open file (such as .sh_history) deleting the directory entry will not free the allocated disk space. Programs which write log files often cause this confusion as things such as du will give different results than df after someone deletes "that huge log file" - all they have done is removed the directory entry. Of course, there could be something else bizarre going on... nick@bis.com
tomg@hpcvlx.cv.hp.com (Thomas J. Gilg) (07/30/90)
> HP-UX V7.0 X11 hpterms with the ksh shell. The operating system is the > Every so often, the .sh_history will start to grow very large. After I've seen it also now that you mention it. We lost 60 Megs on a disk in no time flat before we discovered the growing .sh_history file and removed it. Feels like a bug report coming on :-) Anyone have better details ? Thomas Gilg tomg@cv.hp.com
burzio@mmlai.UUCP (Tony Burzio) (07/30/90)
>I'm not clear on exactly what you meant by "other processes," but I >share your suspicion that some process has the history file open, and >hence rm doesn't really remove it, only unlinks it from the directory. Interesting. I didn't know that rm'ing a file could leave it behind. Can a file exist without the inode? Anyway, here are some more clues: Aborting out of curses while in cbreak mode seems to cause the .sh_history explosion (at least, this starts the shell ignoring input, and the disk flashing). In addition, exiting the session using the pre-loaded HP-UX xctrl program (instead of the alt-ctrl-reset of the old X) does not seem to hunt down old processes very well at session shutdown. Curious. >By the way, netnews is a very slow and capricious way to get questions >answered. If you have either HP TeamLine or HP ResponseLine software >support services, you can direct questions about supported HP products >to your regional HP Response Center. HP people who respond to netnews >questions are donating our time. We do not have the full resources of >a Response Center at our disposal, and the person who knows the answer >to any given question may not be reading news this week, or month, >or... In general, the Response Center has to track one of the HP Gurus down to answer my questions. Unfortunatly, these esteemed people are usually busy reading the netnews :-). ********************************************************************* Tony Burzio * Gentlemen, this world is impaled on Martin Marietta Labs * a roasting spit... mmlai!burzio@uunet.uu.net * - Voyage to the Bottom of the Sea *********************************************************************
guy@auspex.auspex.com (Guy Harris) (08/01/90)
>Interesting. I didn't know that rm'ing a file could leave it behind. Now you know. >Can a file exist without the inode? No. However, the inode can exist without a directory entry pointing to it, which is what's happening here. Pretty standard UNIX behavior....
defaria@hpclove.HP.COM (Andy DeFaria) (08/01/90)
What I do is: export HISTFILE=/nonexistant/file # make history unique per window Since the HISTFILE is nonexistant ksh will keep the history file in a temporary nameless file (inode only) so I don't have to worry about a .sh_histroy file growing too big. As a side benefit (or problem depending on how you view it) each hpterm window has its own history file so if I type echo "This echo command was entered in my console window" then I go to a regular terminal window and C-p (emacs style for "get last command". Vi style would by ESC then a "k") I will not get the preceeding echo command but whatever was my preceeding command in this hpterm window. There are some advantages with sharing a .sh_history file (the ability to easiliy redo a command that was entered into the wrong window, but I can always cut and paste) but I tend to think of each terminal window as its own entity with its own redo stack. The only other problem I can see it that you won't be able to save your redo stack from login to login but you're really not logging in when your using X. At least the way I view it.
decot@hpisod2.HP.COM (Dave Decot) (08/02/90)
Drifting... > >Can a file exist without the inode? > > No. ...unless the file is a symbolic link, on systems where only the directory entry is needed to implement such files. Dave