Logging errors in apps running as Application.Daemon

[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...

Cheers!






--
View this message in context: http://gambas.8142.n7.nabble.com/Logging-errors-in-apps-running-as-Application-Daemon-tp59450.html
Sent from the gambas-user mailing list archive at Nabble.com.

[a***@gmail.com]

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...
Cheers!

In this case, probably the easiest is to redirect stdout and stderr to a file somewhere.
The commands you should look at are:
OUTPUT TO and
ERROR TO

(and you'll have to write the necessary guff to set up the file, etc etc of course)

hth
bruce

[a***@gmail.com]

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...
Cheers!

or now that I think of it, you could just:

$ yourdeamonstarter > output.txt 2>&1

:-)

(Oh where might I have seen that somewhere before ???)
B

[Tobias Boege]

Post by a***@gmail.com
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...
Cheers!

$ yourdeamonstarter > output.txt 2>&1
:-)
(Oh where might I have seen that somewhere before ???)
B

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
a
$ ./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:

$ ./daemon2.gbs3
$ cat /tmp/log*
a
b

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() [1]
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).

Regards,
Tobi

[1] http://gambaswiki.org/wiki/comp/gb/application

[Tobias Boege]

Post by Tobias Boege
Attached are two scripts

[PICCORO McKAY Lenz]

in the case of deamon redirection, for those using Devuan, Debian and
VenenuX the correct way to always see what happened to their daemons
process it to strting run by the command "start-stop-daemon" as good choice
with proper flags to redirect output...

this will heppl to redirect the ouptu and see what happened... in other
cases, will happened that tobias said...



Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Post by Tobias Boege

Post by Tobias Boege
Attached are two scripts

--
"There's an old saying: Don't change anything... ever!" -- Mr. Monk
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gambas-user mailing list
https://lists.sourceforge.net/lists/listinfo/gambas-user

[a***@gmail.com]

On Wed, 21 Jun 2017 13:51:11 +0200

Post by Tobias Boege

Post by a***@gmail.com
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...
Cheers!

$ yourdeamonstarter > output.txt 2>&1
:-)
(Oh where might I have seen that somewhere before ???)
B

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.

Weird. I just tried it quickly here and it works. Then again, here there is no man 3 daemon, which is weirder. So I looked it up on the web:
" int daemon(int nochdir, int noclose);
...
If noclose is zero, daemon() redirects standard input, standard
output and standard error to /dev/null; otherwise, no changes are
made to these file descriptors."

(So, maybe, I think this might be a distro or kernel scheduling thing, but...)

(Further quick reading... SysV vs systemd )
"New-Style Daemons
Modern services for Linux should be implemented as new-style daemons."
... none of the initialization steps recommended for SysV daemons need to
be implemented. New-style init systems such as systemd make all of them
redundant.
... it is guaranteed that the environment block is sanitized, that the signal
handlers and mask is reset and that no left-over file descriptors are passed.
Daemons will be executed in their own session, with standard input connected
to /dev/null and standard output/error connected to the
systemd-journald.service(8) logging service, unless otherwise...

It's still not clear to me why it works on my machine. But now I'll have to go and check on the others here at paddys-hill and the damned customer VM's* to see if we might run into that problem if I tried it in the future. Well, every day a new thing learned.
But then again, didn't someone say
"There's an old saying: Don't change anything... ever!" -- Mr. Monk

b

(* The VM's cause me grief not the customers)

[alexchernoff]

Peace!

Well, Public Sub Application_Error() does fire upon a fatal error, but is it
possible to know what the last error was?

cheers!





--
View this message in context: http://gambas.8142.n7.nabble.com/Logging-errors-in-apps-running-as-Application-Daemon-tp59450p59502.html
Sent from the gambas-user mailing list archive at Nabble.com.

[alexchernoff]

well, at least system.backtrace[1] (or error.backtrace[0] seem to show the
error line.

But it would be nice to get fatal interpreter errors written to a file.

cheers!





--
View this message in context: http://gambas.8142.n7.nabble.com/Logging-errors-in-apps-running-as-Application-Daemon-tp59450p59504.html
Sent from the gambas-user mailing list archive at Nabble.com.

[alexchernoff]

Anyone know if there is a wrapper to daemonize apps while keeping them in
regular console mode? That way maybe it will be possible to log fatal
interpreter errors?

Peace!




--
View this message in context: http://gambas.8142.n7.nabble.com/Logging-errors-in-apps-running-as-Application-Daemon-tp59450p59515.html
Sent from the gambas-user mailing list archive at Nabble.com.

[Tobias Boege]

Post by alexchernoff
Anyone know if there is a wrapper to daemonize apps while keeping them in
regular console mode? That way maybe it will be possible to log fatal
interpreter errors?

Why do you want to daemonise then? From the manpage of daemon():

The daemon() function is for programs wishing to detach themselves from
the controlling terminal and run in the background as system daemons.

Maybe it's time to ask what you want to accomplish, because it's probably
not running a daemon.

Regards,
Tobi

[alexchernoff]

Peace!

Making apps daemons is exactly what I want to achieve, but couldn't get
interpreter errors to log to file in native daemon mode. So I thought maybe
a wrapper can start a non daemon app, intercept all output including
interpreter errors, and go into background?

This is boot time start "service" apps.

Cheers



--
View this message in context: http://gambas.8142.n7.nabble.com/Logging-errors-in-apps-running-as-Application-Daemon-tp59450p59519.html
Sent from the gambas-user mailing list archive at Nabble.com.

[alexchernoff]

Peace,

Can gbr3 be made to log fatal interpreter errors to file?

Thanks!




--
View this message in context: http://gambas.8142.n7.nabble.com/Logging-errors-in-apps-running-as-Application-Daemon-tp59450p59565.html
Sent from the gambas-user mailing list archive at Nabble.com.

[PICCORO McKAY Lenz]

can you combine that: https://www.gambas-es.org/viewtopic.php?f=5&t=6396
with a combination of some of that tools:
a) recursive programing or exec callback's (i really not expert in this
with gambas)
b) http://cr.yp.to/daemontools.html
c) http://supervisord.org/

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Post by alexchernoff
Peace,
Can gbr3 be made to log fatal interpreter errors to file?
Thanks!
--
View this message in context: http://gambas.8142.n7.nabble.
com/Logging-errors-in-apps-running-as-Application-Daemon-
tp59450p59565.html
Sent from the gambas-user mailing list archive at Nabble.com.
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gambas-user mailing list
https://lists.sourceforge.net/lists/listinfo/gambas-user