Logging errors in apps running as Application.Daemon

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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!


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Logging errors in apps running as Application.Daemon

adamnt42@gmail.com
On Wed, 21 Jun 2017 02:17:27 -0700 (MST)
alexchernoff <[hidden email]> wrote:

> 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



--
B Bruen <[hidden email] (sort of)>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Logging errors in apps running as Application.Daemon

adamnt42@gmail.com
In reply to this post by alexchernoff
On Wed, 21 Jun 2017 02:17:27 -0700 (MST)
alexchernoff <[hidden email]> wrote:

> 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

--
B Bruen <[hidden email] (sort of)>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Logging errors in apps running as Application.Daemon

Tobias Boege-2
On Wed, 21 Jun 2017, [hidden email] wrote:

> On Wed, 21 Jun 2017 02:17:27 -0700 (MST)
> alexchernoff <[hidden email]> wrote:
>
> > 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
>

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

--
"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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Logging errors in apps running as Application.Daemon

Tobias Boege-2
On Wed, 21 Jun 2017, Tobias Boege wrote:
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-user

daemon1.gbs3 (162 bytes) Download Attachment
daemon2.gbs3 (324 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Logging errors in apps running as Application.Daemon

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

2017-06-21 7:26 GMT-04:30 Tobias Boege <[hidden email]>:

> On Wed, 21 Jun 2017, Tobias Boege wrote:
> > 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gambas-user
>
>
------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Logging errors in apps running as Application.Daemon

adamnt42@gmail.com
In reply to this post by Tobias Boege-2
On Wed, 21 Jun 2017 13:51:11 +0200
Tobias Boege <[hidden email]> wrote:

> On Wed, 21 Jun 2017, [hidden email] wrote:
> > On Wed, 21 Jun 2017 02:17:27 -0700 (MST)
> > alexchernoff <[hidden email]> wrote:
> >
> > > 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
> >
>
> 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)
--
B Bruen <[hidden email] (sort of)>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Logging errors in apps running as Application.Daemon

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!

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Logging errors in apps running as Application.Daemon

gambas-user mailing list
Le 22/06/2017 à 13:56, alexchernoff a écrit :
> Peace!
>
> Well, Public Sub Application_Error() does fire upon a fatal error, but is it
> possible to know what the last error was?
>
> cheers!
>
>

At the moment, no.

--
Benoît Minisini

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Logging errors in apps running as Application.Daemon

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!

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Logging errors in apps running as Application.Daemon

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!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Logging errors in apps running as Application.Daemon

Tobias Boege-2
On Thu, 22 Jun 2017, alexchernoff wrote:
> 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

--
"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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Logging errors in apps running as Application.Daemon

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Logging errors in apps running as Application.Daemon

alexchernoff
Peace,

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

Thanks!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Logging errors in apps running as Application.Daemon

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

2017-06-28 10:22 GMT-04:00 alexchernoff <[hidden email]>:

> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gambas-user
>
------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-user
Loading...