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
D
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 dbus
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 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 ope
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
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
> wrote:
> > On 8 January 2015 at 17:24, Simon McVittie
> > wrote:
> >> On 08/01/15 16:03, Dimitri John Ledkov wrote:
> >> * I'm in an X11 session and my GUI locks up. I
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 pe
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-Bu
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 wrote:
> > В Thu, 8 Jan 2015 16:03:43 +
> > Dimitri John Ledkov пишет:
> >
> >> On 8 January 2015 at 15:37, Simon McVittie
> >> wrote:
> >> > On 08/01/15 14:36, Col
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 Poetteri
On Fri, Jan 9, 2015 at 2:18 AM, Colin Guthrie wrote:
> Cameron Norman wrote on 09/01/15 02:24:
>> On Thu, Jan 8, 2015 at 9:42 AM, Dimitri John Ledkov
>> wrote:
>>> On 8 January 2015 at 17:24, Simon McVittie
>>> wrote:
On 08/01/15 16:03, Dimitri John Ledkov wrote:
* I'm in an X11 sessio
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 tha
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 dbu
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 th
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
Cameron Norman wrote on 09/01/15 02:24:
> On Thu, Jan 8, 2015 at 9:42 AM, Dimitri John Ledkov
> wrote:
>> On 8 January 2015 at 17:24, Simon McVittie
>> 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 t
Dimitri John Ledkov wrote on 08/01/15 17:48:
> On 8 January 2015 at 17:15, Andrei Borzenkov wrote:
>> В Thu, 8 Jan 2015 16:03:43 +
>> Dimitri John Ledkov пишет:
>>
>>> On 8 January 2015 at 15:37, Simon McVittie
>>> wrote:
On 08/01/15 14:36, Colin Guthrie wrote:
> Lennart Poettering
On Thu, Jan 8, 2015 at 9:42 AM, Dimitri John Ledkov
wrote:
> On 8 January 2015 at 17:24, Simon McVittie
> 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 the getty. How do I communicate with X11 session t
On 08/01/15 17:42, Dimitri John Ledkov wrote:
> On 8 January 2015 at 17:24, Simon McVittie
> 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 does not try to impose iso
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 8 January 2015 at 17:24, Simon McVittie
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 cgroups as needed for con
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,
On 8 January 2015 at 17:15, Andrei Borzenkov wrote:
> В Thu, 8 Jan 2015 16:03:43 +
> Dimitri John Ledkov пишет:
>
>> On 8 January 2015 at 15:37, Simon McVittie
>> wrote:
>> > On 08/01/15 14:36, Colin Guthrie wrote:
>> >> Lennart Poettering wrote on 08/01/15 13:19:
>> Thus my expectation woul
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 sessio
В Thu, 8 Jan 2015 16:03:43 +
Dimitri John Ledkov пишет:
> On 8 January 2015 at 15:37, Simon McVittie
> 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 become singleton services of the
> >>> user, a
Hi Simon,
Hope my reply gets through to both lists (can't remember if I sub'ed to
dbus in the past - I always read via gmane but am allowed to post on
most of the lists...)
Simon McVittie wrote on 08/01/15 12:39:
> Adding D-Bus mailing list to Cc; questions about the user bus are
> significant fo
On 8 January 2015 at 15:37, Simon McVittie
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 become singleton services of the
>>> user, and the sessions ultimately only retain a "stub" process
>>
>> But dbus-dae
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 mod
Lennart Poettering wrote on 08/01/15 13:19:
> 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 tea
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 launchi
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 bett
31 matches
Mail list logo
