FW: Service activation and file descriptors

[Kimmo.Hamalainen at nokia.com]

Hi,

Could someone commit this patch? I find it quite useful, because by defining
the variable you can see what your service outputs to stdout when debugging.

BR, Kimmo

-----Original Message-----
From: dbus-bounces at freedesktop.org
[mailto:dbus-bounces at freedesktop.org]On Behalf Of ext 
Sent: 18 August, 2004 15:31
To: dbus at freedesktop.org
Subject: FW: Service activation and file descriptors


Hi,

Here is a simple patch for stdout - there is already similar solution
for stderr in the code (which I copied).

As the code suggest, when DBUS_DONT_CLOSE_STDOUT is defined, stdout
is not closed nor redirected to /dev/null.

BR, Kimmo

-----Original Message-----
From: dbus-bounces at freedesktop.org
[mailto:dbus-bounces at freedesktop.org]On Behalf Of ext Havoc Pennington
Sent: 23 July, 2004 00:32
To: Laporte Philippe (Nokia-M/Helsinki)
Cc: dbus at freedesktop.org
Subject: Re: Service activation and file descriptors


On Thu, 2004-07-22 at 12:07, Philippe Laporte wrote:
> Hi,
>      About the preservation of file descriptors for launched services.
> 
> As far as I understand, the DBUS daemon redirects stderr and stdout to 
> /dev/null.
> 
> But suppose, you have a framework where all application/processes are 
> DBUS services, and that framework is started via the command-line. Then 
> one might be interested in having stdout and stderr go to that same 
> command line.
> 
> So how about this idea: Having an option so that before redirecting all 
> to /dev/null, the daemon should dup the stdout and stderr file 
> descriptors to somewhere, then when launching services, after the fork 
> but before the exec, dup the saved FDs back into FD 1 and 2 (stdout and 
> stderr).
> 
> How about it?

I think the solution may be simpler - for the per-session daemon, just
don't redirect to /dev/null, but for the system daemon continue to do
so. In short add a flag to the config file for this.

The reason for the /dev/null is that you don't want a system daemon to
be holding open an fd to some random NFS mount or something, or for that
matter printing things to some random place. For the session daemon, the
rest of the session will have the same stdout/stderr open anyhow so it's
harmless.

There is some possibility of funkiness (e.g. daemon is blocking on
stderr writing to a terminal while the terminal is trying to use the
daemon and so also blocking) but probably that won't happen.

Havoc


-- 
dbus mailing list
dbus at freedesktop.org
http://freedesktop.org/mailman/listinfo/dbus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stdout-patch
Type: application/octet-stream
Size: 559 bytes
Desc: stdout-patch
Url : http://freedesktop.org/pipermail/dbus/attachments/20040920/ba235469/stdout-patch.obj
-------------- next part --------------
-- 
dbus mailing list
dbus at freedesktop.org
http://freedesktop.org/mailman/listinfo/dbus