Problem: Application with redirected stderr & stdout crashes
when target output files are found “busy”.
We are debugging an app that normally has stderr and stdout
redirected to /dev/null. We redirected stderr and stdout to files,
appending them (since a reset of our (embedded) PC is possible
in these overnight tests.
Here’s how we start our application, with redirection:
our_application >>/tmp/lznet_stdout.txt 2>>/tmp/lznet_stderr.txt &
Questions:
Is there any way to prevent these files from being “busy” after
a less-than-gracefull shutdown?
Is there any way to prevent the application from crashing if
the file we’re redirecting the output to is “busy” and so
unavailable?
There was a command in QNX 4 that could be used to reset
the “Busy” bit on files. I cannot find it under QNX 6. Where is it?
Problem: Application with redirected stderr & stdout crashes
when target output files are found “busy”.
Shooting in the dark:
Are you properly shutting down?
Things like abrupt poweroff can leave the files in “busy” state.
Try running chkfsys before other programs are run.
(for embedded devices, you may need to rebuild the ifs image)
Problem: Application with redirected stderr & stdout crashes
when target output files are found “busy”.
I guess the open on a busy file fails, and something is not checking for
errors and goes ahead and using a NULL FILE* (whereas a -1 fd would just
EBADF all the time without crashing).
Here’s how we start our application, with redirection:
our_application >>/tmp/lznet_stdout.txt 2>>/tmp/lznet_stderr.txt &
I am suprised the shell runs the application if it has an error on the
IO redirection; I just tried this and I get “sh: cannot create file:
Corrupted filesystem detected” and the application does not launch.
So I don’t understand how you redirecting to a busy file this way?
Is there any way to prevent these files from being “busy” after
a less-than-gracefull shutdown?
A file is marked busy when it is extended, as a hint that there may be
inode inconsistencies; the busy is cleared when the file is closed
(over-allocated space is trimmed back then) or when set to a smaller
size (via ftruncate) or when it is fsync()d. So an application which is
concerned can take any of these steps after growing a file; you don’t
necessarily have that sort of control in generic IO redirection.
Is there any way to prevent the application from crashing if
the file we’re redirecting the output to is “busy” and so
unavailable?
Checking for errors from any open/fopen? As I said I am suprised the
shell launched your application in the first place. From QNX6.2.1
onwards there is a filesystem mount option “unbusy”, which will let
fs-qnx4 just truncate a busy file (back to last known size) when you try
to open it, which is useful for this sort of application (default is to
EBADFSYS it to prompt the user to run chkfsys which may be able to do a
less drastic repair).
There was a command in QNX 4 that could be used to reset
the “Busy” bit on files. I cannot find it under QNX 6. Where is it?
I am not really aware of such a thing. I recall QNX2 had “chattr -b”,
but that was never in QNX4. There is a “zap” command for deleting files
without going through the filesystem (which is probably what you refer
to, but I think it may have been buggy for 6.1). “chkfsys” (a full
filesystem check) is the traditional way to un-busy files.
Appending to files that were being written during a crash
is never going to work very well.
We do logging by starting a new file every time, using
a file name like “log-YYYYMMDD-HHMMSS.txt”. That way,
if you crash, you start a new file on the next reboot.
which we use for logging. We print to a circular buffer but
never block. If there’s an overrun, data is lost, and “…”
appears in the log.
John Nagle
Team Overbot
Jeff Maass wrote:
Environment: QNX 6.1 on an embedded PC
Problem: Application with redirected stderr & stdout crashes
when target output files are found “busy”.
We are debugging an app that normally has stderr and stdout
redirected to /dev/null. We redirected stderr and stdout to files,
appending them (since a reset of our (embedded) PC is possible
in these overnight tests.
Here’s how we start our application, with redirection:
our_application >>/tmp/lznet_stdout.txt 2>>/tmp/lznet_stderr.txt &
Questions:
Is there any way to prevent these files from being “busy” after
a less-than-gracefull shutdown?
Is there any way to prevent the application from crashing if
the file we’re redirecting the output to is “busy” and so
unavailable?
There was a command in QNX 4 that could be used to reset
the “Busy” bit on files. I cannot find it under QNX 6. Where is it?