RE: {bb} BBOUT extremely large on bb16e1

["Strandell, Ralf" <Ralf.Strandell@silja.com>]

Hi

This problem is more true in a busy system writing *huge* amounts of
system log, printer log etc. but stopping even BB before moving its log
file is safe and good practice (because we don't know exactly how BB has
been designed to support log rotating).

I don't really have an answer to how to find these "lost" files.

You can list the processes that use BBOUT by using the "fuser BBOUT"
command. Go ahead and list those processes, then move BBOUT to
BBOUT.old, create a new BBOUT and check again what processes use BBOUT
and BBOUT.old ...

You can use "fuser -k BBOUT.old" to get rid of those processes
uncleanly, but better to stop them nicely with "runbb.sh stop" and then
waiting for the processes to terminate. You might want to add a stop
command, a sleep and then a fuser -k for example. You won't have
monitoring during that time and the down time causes "bbd didn't
respond" messages to each clients log and alerts might go undetected. A
safe practice is thus to do this log rotating during some quiet time and
relatively rarely. I have chosen to do it monthly, but once a week could
be equally good.

The lsof command lists open files.

In reality you would need to find the actual inode used by the bb
processes writing to log, compare it to the BBOUT and if they don't
match then restart those processes and get rid of the inode...

Debugfs is an interactive tool that lets you use "kill_file inodenumber"
to deallocate an inode (to free diskspace). Use rm instead if the file
is shown in the directory structure. I haven't tried this. I'm not a
filesystem specialist. Don't blame me, when you have shredded you file
system. I favor standard file system checks, reboots etc. because those
are SAFE. But, well, sometimes its exciting to do something dangerous
and have a little of that guru feel. Better not try this on production
systems, though.

Just restart the app and make a filesystem check...


-----Original Message-----
From: owner-bb@bb4.com [mailto:owner-bb@bb4.com] On Behalf Of Joshua Au
Sent: Friday, March 24, 2006 2:29 AM
To: bb@bb4.com
Cc: Joshua Au
Subject: Re: {bb} BBOUT extremely large on bb16e1

Hi

    Thanks for your advice. I think I shall back up the file and stop bb
from running before clearing it.
However, is there a way to check if any process is indeed writing to the
inode in the situation that you mentioned, and if so, is there a way to
salvage it?

regards

----- Original Message -----
From: "Strandell, Ralf" <Ralf.Strandell@silja.com>
To: <bb@bb4.com>
Sent: Wednesday, March 22, 2006 11:48 PM
Subject: RE: {bb} BBOUT extremely large on bb16e1


> Hi,
>
> BBOUT is basically an error file. How about removing the errors that
> cause the messages?
> What kind of messages do you see in BBOUT?
>
> A "/bin/mv /home/bb/BBOUT /home/bb/BBOUT.old" in crontab is better
than
> "cat /dev/null > BBOUT".
> You will then allways have some error messages left, in case you would
> need them.
> You could start by moving the file once a month.
>
> If you move the file at the same time that some process has it opened
> for writing, then "fun things" might happen: The process continues to
> write to the same inode (disk area) that now has the name BBOUT.old.
If,
> on the other hand, you choose to "rm BBOUT" then the file name is
> removed from the directory structure, but if some process has the file
> (inode) open for writing during that rm, you will end up in a
situation
> where the file is not visible anywhere, but the process is unaware of
> that and continues to write to the inode. This ghost file consumes
disk
> space and continues to grow as usual... I'm sure that any trouble will
> be gone by next reboot, though. This happens on the vxfs file system.
> Might also be true in other file systems, so beware. Having some
process
> write data to disk without creating a visible file feels real bad
> (especially if you are the sysadmin). So avoid deleting files that are
> opened for writing. Moving is safer. Shutting down bb (and ALL its
child
> processes) prior to working with BBOUT is even more safe.
>
> -----Original Message-----
> From: owner-bb@bb4.com [mailto:owner-bb@bb4.com] On Behalf Of Joshua
Au
> Sent: Thursday, March 23, 2006 9:57 PM
> To: bb@bb4.com
> Subject: {bb} BBOUT extremely large on bb16e1
>
> Hi,
>
>    I noticed that even for the clients that bb is monitoring, the
BBOUT
> in
> bb/bb16e1 is extremely large. Is it advisable to cat /dev/null > BBOUT
> the file or is there some other way to minimise the hard disk usage of
> BB as the partition that bb is installed on is rather small.
>
> regards, Josh
>
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=
> To unsubscribe from this list, or to subscribe to the bb-digest list
> send e-mail to mailto:majordomo@bb4.com with unsubscribe bb -and/or-
> subscribe bb-digest in the BODY of the message.
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=
> To unsubscribe from this list, or to subscribe to the bb-digest list
> send e-mail to mailto:majordomo@bb4.com with unsubscribe bb -and/or-
> subscribe bb-digest in the BODY of the message.
> 


--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=
To unsubscribe from this list, or to subscribe to the bb-digest list
send e-mail to mailto:majordomo@bb4.com with unsubscribe bb -and/or-
subscribe bb-digest in the BODY of the message.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=
To unsubscribe from this list, or to subscribe to the bb-digest list
send e-mail to mailto:majordomo@bb4.com with unsubscribe bb -and/or-
subscribe bb-digest in the BODY of the message.