Post by firstname.lastname@example.org
On Wed, 21 Jun 2017 02:17:27 -0700 (MST)
Post by alexchernoff
Peace to all,
I have some Gb projects that are in Application.Daemon mode. But sometimes
if process dies for whatever reason, I can't see what the last error was. I
have to run it in a console without daemonizing and wait for it to die and
show last reason (like "#13: Null object" or something).
Can this be logged to a file? So at least the last output the interpreter
spits out is logged...
$ yourdeamonstarter > output.txt 2>&1
(Oh where might I have seen that somewhere before ???)
I doubt this works, because Application.Daemon = True calls daemon(3) which
redirects stdout and stderr (which were previously set by the shell to your
log files) to /dev/null, so you won't find anything in your files.
Output To and Error To should still work because they don't replace stdout
and stderr (which are killed by daemon()) but change the default file the
Print and Error statements operate on, at the Gambas level.
I don't know if it's possible to capture interpreter errors this way though.
Generally the interpreter would use fprintf(stderr, ...) to report errors
(fixed on stderr which, again, is sent to /dev/null after daemon()).
Attached are two scripts which showcase these reflections. Both scripts have
three stages: (1) print something, (2) daemonise and print something, and
(3) raise an error and then print something. daemon1.gbs3 uses normal Print
and relies on the shell redirection:
$ ./daemon1.gbs3 >/tmp/log 2>&1
$ cat /tmp/log
Of course, only the output after the first stage is shown as stdout is
closed after daemonising. The interpreter error is not shown. Curiously
the shell redirection results in an empty file, so not even the first
stage output arrives(?)
Whereas daemon2 creates its own log files (one for stdout and stderr each)
and uses Output To and Error To:
$ cat /tmp/log*
It can at least store its output after the daemonisation (the "b"), but
the interpreter error is not logged. To get this, you could look into
using the global error handler Static Public Sub Application_Error() 
in your startup class or using the C library via Extern to force your
log files into the standard fds again (this latter one would be the
least intrusive for the code you may have already written).
"There's an old saying: Don't change anything... ever!" -- Mr. Monk