On Wed, 21 Jun 2017 13:51:11 +0200
Tobias Boege <tabo...@gmail.com> wrote:
> On Wed, 21 Jun 2017, adamn...@gmail.com wrote:
> > On Wed, 21 Jun 2017 02:17:27 -0700 (MST)
> > alexchernoff <alexchern...@hotmail.com> 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 <adamn...@gnail.com (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
Gambas-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gambas-user
