bdf doesn't work

[Jeff Hagstrom]

I ran out of space on "/" and now my bdf doesn't work. I'm pretty sure I have space back on "/", but the bdf still doesn't work.

[OFC_EDM · Accepted solution]

Try df -k

[Pete Randall]

Hmmmm. . . ."doesn't work". . . . .do you mean it just hangs without producing any output? Does it produce some output and then hang? Do you get a prompt back?

Usually bdf hangs because of a failed NFS mount point that it can no longer contact.

Try du -kx in the meantime.


Pete

[Ganesan R]

Hi,

Stale NFS should be the cause on most situations of bdf hang issue. reboot is the only solution since hp-ux does not have force unmount for NFS mounts.

du will be the alternate to know the filesystem usage.

[Steven Schweda]

> Hmmmm. . . ."doesn't work". . . . .do you
> mean [...]

Here's a novel idea. Why don't you simply
tell us what "doesn't work" means in this
situation, and spare us all having to read
everyone's attempts to guess what you mean.
You might even get better answers sooner from
non-psychics if you reveal what the actual
problem is.

[Pete Randall]

> Why don't you simply tell us what "doesn't work" means in this situation

And how often does that happen? Really?

I thought half the fun was supposed to be in figuring out what the user actually meant. Like the time one of my programmers called me to tell me that his keyboard didn't work. When I got to his empty office, I discovered that he had dumped a cup of coffee into the keyboard! That wouldn't have been anywhere near as much fun if he'd just told me that up front.

;^)


Pete

[Steven Schweda]

> And how often does that happen? Really?

Hey. I said that it was a novel idea.

In this forum, it seems to happen with
astounding infrequency. Perhaps I'm easily
astounded. I'd continue ranting but the ITRC
Thought Police would probably just throw it
all into the memory hole on the grounds of
personal abuse (or authoritative whim). (If,
that is, the Forum software happens to be
working when they try to do it, which seems
to be increasingly unlikely of late.)

[V. Nyga]

BTW - You have assigned points to 681 of 1026 responses to your questions.

Please honour the efforts here and work through:
http://forums11.itrc.hp.com/service/forums/pageList.do?userId=CA557645&listType=unassigned&forumId=1

And as said - the quickest way to get a solution is as many informations as possible.

V.

[Jeff Hagstrom]

And I thought you were all physics. If it makes you feel better to flex your obvious superior intellect, then you just keep ranting and no one will tell the Thought Police. When I first started asking questions on the forum, I did not understand the point system, I didnâ t realize it was important and Iâ ve tried to keep up with it since.

When I said BDF didnâ t work, it would drop straight to a prompt, as if the enter key was pushed with no command typed in. â /â ran out of space just before this happened. The command df â k didnâ t work. The du command works: du -kx / | sort -k1,1rn
.

[Pete Randall]

So, can you tell from the du command whether / is still full or not? I don't think I've ever seen an instance where bdf stopped working because a file system filled up. Are you using /usr/bin/bdf or some alias to bdf like bdfmegs or something?


Pete

[Steven Schweda]

> And I thought you were all physics. [...]

I was a physics major in college, but even
then I was not "all physics". Graduation
required several courses outside one's major.

[Steven Schweda]

One conjecture (and only a conjecture):

bdf looks at /etc/mnttab, and because "/"
was full, /etc/mnttab couldn't get created
(or populated).

If that were the problem, then perhaps
running "mount -a" again (after making some
space in "/") might get /etc/mnttab
reconstuituted with real data.

I wouldn't bet a nickel on it, but it does
sound plausible. And "cat /etc/mnttab"
should be a pretty easy and harmless test.

[Steven Schweda]

"man bdf" does mention /etc/mnttab.

Around here:

dy # echo '' > /etc/mnttab
dy # cat /etc/mnttab

dy # bdf
dy # bdf
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol3 524288 161456 360056 31% /
/dev/vg00/lvol1 298928 55624 213408 21% /stand
/dev/vg00/lvol8 4710400 1165936 3517440 25% /var
/dev/vg00/lvol7 20971520 19915136 1056384 95% /usr
/dev/vg00/lvol4 524288 5296 516928 1% /tmp
/dev/vg00/lvol6 3244032 2969432 272496 92% /opt
/dev/vg00/lvol5 24576 2952 21584 12% /home

It didn't last long, but an empty /etc/mnttab
does seem to fool bdf. "man mnttab" suggests
that "syncer" refreshes it:

syncer also updates the /etc/mnttab file if it does not match current
kernel mount information.

I can believe that.

[Dennis Handly]

Does "/usr/bin/bdf /" work?

[Jeff Hagstrom]

mntab was "0" bytes, not enought space to create it. That is why my BDF didn't work.

I have printers that are creating device files in /dev that grew very large, which I delete and touched them off to create the file. I also got rid of core files, *.prev, some old files that had date on them. What ever we could safely remove. Each time I removed something, I tried to do a bdf and it would come straight back to the promp(0 byte file). At some time later, something triggered the system to generate a new mntab file and then around 5:30pm eastern the bdf started working again.

[Patrick Wallek]

>>I have printers that are creating device files in /dev that grew very large,

What would that be? A large printer device file seems very abnormal.

[Jeff Hagstrom]

I wish I knew the answer. My printers get created by a script from company called Milan technology Corp. In some of mine it showed in error, sometimes it would have been bad host name entry error or a path error. I was working with SMS and they weren't sure either? It didn't hurt the printing if I delete them and generated a new "0" byte file, the printer had to be re-enabled and then it worked fine.

[candlejack]

This thread is exactly why I don't post here. Ridiculous.