Question about isatty/read usage in dbus-launch
hp at redhat.com
Fri Dec 1 18:41:35 PST 2006
The reason I haven't come out and said "let's make changes a, b, and c"
is that they will cause some churn/disruption and there should be a
well-thought-through master plan so we don't go in circles changing it
back and forth.
There are also some larger-scope partly-related changes:
(Those last proposed changes at least make dbus-launch pretty
configurable in what it does; perhaps in that spirit, if we split
--exit-with-session into --exit-with-x-session / --exit-with-tty-session
then that would be a plausible solution to the problem at hand, though
it still wouldn't _fix_ --exit-with-tty-session to work right)
We could have an --exit-with-launched-program also though I do think
it's a little silly; it's called "inter-process communication" because
there are at least two processes ;-) but it could be useful for
debugging and such.
If you do something like "dbus-launch firefox" then as dbus is more
heavily used, effectively what will happen is that firefox gets its
whole own private desktop session, where all kinds of services might get
launched. If you were already logged in, you'd get second copies of
everything vs. your main desktop session.
An example of what could go wrong; we might have an "open a single
instance app" service on the bus, so say I do "dbus-launch firefox" and
it uses this service to open a document in OpenOffice, then I close
firefox, I am *not* expecting my OpenOffice to exit. But that's what
would happen with --exit-with-launched-program.
(Remember that dbus-daemon defines the session lifecycle, normal apps
are supposed to exit when disconnected from it and assume anything
sharing their session is on the same session bus.)
Anyhow... more reasonable uses of dbus-launch might include:
- running one daemon per X display/session
- one per ssh or console session
- it's used internally by libdbus to do the autolaunch
work (though whenever autolaunch happens, your setup is
incorrect or at least suboptimal)
- doing a "dbus-launch bash" in order to get a debugging
session with everything you run in the bash sharing a
- probably some other debugging-type usages
Given the use cases of an X session or an ssh session, offhand it seems
reasonable to split up --exit-with-session into --exit-with-x-session /
--exit-with-tty-session (with current --exit-with-session equivalent to
specifying both flags).
Regarding the double fork/exec, it makes sense to me in the case of
starting the bus for a session; I don't think exiting when the child
exits is right in that case, so we don't care about the child's return
code or exit status and we can just reap it.
When doing a debug thing like "dbus-launch bash" then
--exit-with-launched-program (presumably implemented by not reaping the
child right away) sounds handy.
It might be nice to write up a short list of use-cases, then a patch for
the man page documenting new options we should have, including the
various --exit-with plus those discussed here or improvements on them:
Then we'll have a sort of "dbus-launch roadmap" in the form of the use
cases plus man page changes. It'd also be nice to figure out the bug Ray
Of course, it's pretty academic unless someone has time to work on
sorting this out...
More information about the dbus