On 02/02/15 22:47, Lennart Poettering wrote:
Well, I mean, we only ever put this altogether for kdbus, where
systemd itself is the one setting up the bus. But yeah, if you want to
make this all work with dbus-daemon, then you would have to teach it
bus activation support. Most likely that should
On 03/02/15 12:08, Lennart Poettering wrote:
Do you need more than systemctl import DISPLAY?
That's the main one, but for it to not be a regression on current
general-purpose distributions, the equivalent of `systemctl
import-environment` needs to upload into the dbus-daemon too (so that
On Tue, 03.02.15 11:52, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote:
On 02/02/15 22:47, Lennart Poettering wrote:
Well, I mean, we only ever put this altogether for kdbus, where
systemd itself is the one setting up the bus. But yeah, if you want to
make this all work with
On Thu, 08.01.15 17:48, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote:
On 8 January 2015 at 17:15, Andrei Borzenkov arvidj...@gmail.com wrote:
В Thu, 8 Jan 2015 16:03:43 +
Dimitri John Ledkov dimitri.j.led...@intel.com пишет:
On 8 January 2015 at 15:37, Simon McVittie
On Fri, 09.01.15 12:18, Colin Guthrie (gm...@colin.guthr.ie) wrote:
Mantas Mikulėnas wrote on 09/01/15 10:31:
I guess you could use KillMode= for this?
I don't think so. This would mean the unit would still be alive even
although the main process died and when I next tried to open a
On Thu, 08.01.15 19:01, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote:
On 08/01/15 17:04, Colin Guthrie wrote:
Although when I discussed this on the ML
before, one case which a PAM solution wouldn't address is people running
startx after logging into a tty session
I personally
On Thu, 08.01.15 18:24, Cameron Norman (camerontnor...@gmail.com) wrote:
On Thu, Jan 8, 2015 at 9:42 AM, Dimitri John Ledkov
dimitri.j.led...@intel.com wrote:
On 8 January 2015 at 17:24, Simon McVittie
simon.mcvit...@collabora.co.uk wrote:
On 08/01/15 16:03, Dimitri John Ledkov wrote:
*
On Thu, 08.01.15 14:36, Colin Guthrie (gm...@colin.guthr.ie) wrote:
(Sorry for the late reply. Still busy processing all the queued
mails. I figure half of what this mail was about was already discussed
on the hackfest last friday, but in case something was missing, here
we go)
Lennart
On Thu, 08.01.15 17:42, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote:
It also means you can't use D-Bus names as single-instance mutexes to
avoid last write wins, earlier writes are lost (or worse!) data
corruption in the home directory, because it allows more than one D-Bus
On Fri, 09.01.15 10:26, Colin Guthrie (gm...@colin.guthr.ie) wrote:
Colin Guthrie wrote on 08/01/15 11:55:
I solved this by adding a user unit for gnome-termnial-server and
making dbus use systemd activation for it, but that just moves it to a
different cgroup. I guess it's OK like this.
On Fri, Jan 09, 2015 at 09:56:27AM +, Colin Guthrie wrote:
You don't really need to use abstract sockets here, you can use known
socket paths in $XDG_RUNTIME_DIR these days as we can rely on it.
As pam_systemd will set XDG_RUNTIME_DIR to /run/user/$UID/ we can easily
just mandate that
Dimitri John Ledkov wrote on 08/01/15 17:48:
On 8 January 2015 at 17:15, Andrei Borzenkov arvidj...@gmail.com wrote:
В Thu, 8 Jan 2015 16:03:43 +
Dimitri John Ledkov dimitri.j.led...@intel.com пишет:
On 8 January 2015 at 15:37, Simon McVittie
simon.mcvit...@collabora.co.uk wrote:
On
Colin Guthrie wrote on 08/01/15 11:55:
I solved this by adding a user unit for gnome-termnial-server and
making dbus use systemd activation for it, but that just moves it to a
different cgroup. I guess it's OK like this.
Just as a minor curiosity related to this bit...
I discovered today that
On Fri, Jan 9, 2015 at 2:18 AM, Colin Guthrie gm...@colin.guthr.ie wrote:
Cameron Norman wrote on 09/01/15 02:24:
On Thu, Jan 8, 2015 at 9:42 AM, Dimitri John Ledkov
dimitri.j.led...@intel.com wrote:
On 8 January 2015 at 17:24, Simon McVittie
simon.mcvit...@collabora.co.uk wrote:
On 08/01/15
Cameron Norman wrote on 09/01/15 02:24:
On Thu, Jan 8, 2015 at 9:42 AM, Dimitri John Ledkov
dimitri.j.led...@intel.com wrote:
On 8 January 2015 at 17:24, Simon McVittie
simon.mcvit...@collabora.co.uk wrote:
On 08/01/15 16:03, Dimitri John Ledkov wrote:
* I'm in an X11 session and my GUI
Mantas Mikulėnas wrote on 09/01/15 10:31:
I guess you could use KillMode= for this?
I don't think so. This would mean the unit would still be alive even
although the main process died and when I next tried to open a
gnome-terminal, it would try and speak to the dbus service again and
then dbus
I guess you could use KillMode= for this?
Or, actually, dbus.service doesn't stop on logout, does it?...
For tmux, I have a tmux.service that runs:
ExecStart=/usr/bin/tmux start-server \x3B wait-for systemd
ExecStop=/usr/bin/tmux wait-for -S systemd \x3B kill-server
screen has no equivalent
On Thu, Jan 8, 2015 at 9:42 AM, Dimitri John Ledkov
dimitri.j.led...@intel.com wrote:
On 8 January 2015 at 17:24, Simon McVittie
simon.mcvit...@collabora.co.uk wrote:
On 08/01/15 16:03, Dimitri John Ledkov wrote:
* I'm in an X11 session and my GUI locks up. I use Ctrl+Alt+F1
and log in at
Hi,
I'm just playing around with this and making some progress.
I've got a modified dbus-launch that can be slotted in nicely to poke
dbus activated via systemd and teach it about the environment for
subsequent launching. It also pokes systemd --user with the environment
too. It's pretty simply
Adding D-Bus mailing list to Cc; questions about the user bus are
significant for D-Bus as well as for systemd --user, and modifications
of dbus-launch doubly so.
On 08/01/15 11:55, Colin Guthrie wrote:
I've got a modified dbus-launch that can be slotted in nicely
I'm happy for dbus to get
On Thu, 08.01.15 11:55, Colin Guthrie (co...@mageia.org) wrote:
Hi,
I'm just playing around with this and making some progress.
I've got a modified dbus-launch that can be slotted in nicely to poke
dbus activated via systemd and teach it about the environment for
subsequent launching. It
On 08/01/15 16:03, Dimitri John Ledkov wrote:
There is upstart --user spawned per session, and everything is under
it. The sessions' logind cgroups are parent of all processes within a
session, and there are sub cgroups as needed for contained
jobs/processes. Thus for three graphical sessions,
On 08/01/15 17:24, Simon McVittie wrote:
This is a conversation about the distinction between a per-(uid,machine)
bus (the user bus) and a per-login-session bus (the session bus).
We've had this discussion several times in the past
Some further reading; I knew this conversation was old, I
On 08/01/15 14:36, Colin Guthrie wrote:
Lennart Poettering wrote on 08/01/15 13:19:
Yes, the idea is that these services become singleton services of the
user, and the sessions ultimately only retain a stub process
But dbus-daemon itself might be excluded from that no? I mean the model
is
В Thu, 8 Jan 2015 16:03:43 +
Dimitri John Ledkov dimitri.j.led...@intel.com пишет:
On 8 January 2015 at 15:37, Simon McVittie
simon.mcvit...@collabora.co.uk wrote:
On 08/01/15 14:36, Colin Guthrie wrote:
Lennart Poettering wrote on 08/01/15 13:19:
Yes, the idea is that these services
On 8 January 2015 at 17:24, Simon McVittie
simon.mcvit...@collabora.co.uk wrote:
On 08/01/15 16:03, Dimitri John Ledkov wrote:
There is upstart --user spawned per session, and everything is under
it. The sessions' logind cgroups are parent of all processes within a
session, and there are sub
On 08/01/15 17:04, Colin Guthrie wrote:
Although when I discussed this on the ML
before, one case which a PAM solution wouldn't address is people running
startx after logging into a tty session
I personally am very tempted to say that startx users get to keep both
pieces, and that the *dm
On 08/01/15 17:42, Dimitri John Ledkov wrote:
On 8 January 2015 at 17:24, Simon McVittie
simon.mcvit...@collabora.co.uk wrote:
I personally think having only the user bus (and having
(G_|DBUS_)BUS_TYPE_SESSION connect to it) is the best long-term setup,
because it's easy to understand and
28 matches
Mail list logo
