Lennart Poettering wrote on 27/10/14 18:11:
On Thu, 23.10.14 17:26, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
order it after basic.target (which things are by default anyway)...
My proposal now, (which is the same Damien's as I understood him):
1. pam_systemd should sync on
On Sun, 26.10.14 20:47, Damien Robert (damien.olivier.rob...@gmail.com) wrote:
From Lennart Poettering, Fri 24 Oct 2014 at 01:09:56 (+0200) :
So, I really would prefer if this logic wasn't just a hook, but
actually the primary action of logging in graphically via a display
manager.
Ok,
On Thu, 23.10.14 17:26, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
order it after basic.target (which things are by default anyway)...
My proposal now, (which is the same Damien's as I understood him):
1. pam_systemd should sync on default.target
2. by default
From Lennart Poettering, Fri 24 Oct 2014 at 01:09:56 (+0200) :
So, I really would prefer if this logic wasn't just a hook, but
actually the primary action of logging in graphically via a display
manager.
Ok, and login off would just be something like 'systemctl stop gnome.target'?
Note
On Wed, 22.10.14 12:57, Damien Robert (damien.olivier.robert+gm...@gmail.com)
wrote:
Lennart Poettering wrote in message 20141020173828.GA4509@gardel-login:
They should probably adopt socket activation anyway, otherwise they'd
be quite annoying on multi-user systems if lingering is used.
On Thursday 23 October 2014 at 07:06:18, Mantas Mikulėnas wrote:
On Oct 23, 2014 1:54 AM, Lennart Poettering lenn...@poettering.net
wrote:
On Wed, 22.10.14 12:44, Damien Robert (
damien.olivier.robert+gm...@gmail.com) wrote:
[...]
policykit really should get fixed there. it
From Mantas Mikulėnas, Thu 23 Oct 2014 at 07:06:18 (+0300) :
Wasn't this already fixed in polkit.git recently?
Yes indeed:
commit a68f5dfd7662767b7b9822090b70bc5bd145c50c
sessionmonitor-systemd: prepare for D-Bus user bus model
In the D-Bus user bus model, all sessions of a user share the
Zbigniew Jędrzejewski-Szmek wrote in message
20141019135812.gu29...@in.waw.pl:
PAM creates sessions by calling into systemd's pam-module, which then
uses CreateSession() (internal api!). This call does not return until
the job of user@.service is done. `systemd --user` notifies READY=1
On Thu, 23.10.14 08:09, Damien Robert (damien.olivier.robert+gm...@gmail.com)
wrote:
Zbigniew Jędrzejewski-Szmek wrote in message
20141019135812.gu29...@in.waw.pl:
PAM creates sessions by calling into systemd's pam-module, which then
uses CreateSession() (internal api!). This call does
From Lennart Poettering, Thu 23 Oct 2014 at 11:49:27 (+0200) :
On Thu, 23.10.14 08:09, Damien Robert (damien.olivier.robert+gm...@gmail.com)
wrote:
But isn't using default.target more flexible than basic.target? When
basic.target is activated I expect at least socket.target, timers.target
On Thu, 23.10.14 13:47, Damien Robert (damien.olivier.rob...@gmail.com) wrote:
From Lennart Poettering, Thu 23 Oct 2014 at 11:49:27 (+0200) :
On Thu, 23.10.14 08:09, Damien Robert
(damien.olivier.robert+gm...@gmail.com) wrote:
But isn't using default.target more flexible than
From Lennart Poettering, Thu 23 Oct 2014 at 14:01:22 (+0200) :
Oh indeed, there is not sysinit.target. It sounded so wron in a user
context... I figure if people want to stick something in there they
can just as well use basic.target here...
But I was arguing that basic.target has a well
On Thu, 23.10.14 16:06, Damien Robert (damien.olivier.rob...@gmail.com) wrote:
From Lennart Poettering, Thu 23 Oct 2014 at 14:01:22 (+0200) :
Oh indeed, there is not sysinit.target. It sounded so wron in a user
context... I figure if people want to stick something in there they
can just as
On Thu, 23.10.14 17:52, Mantas Mikulėnas (graw...@gmail.com) wrote:
On Oct 23, 2014 5:48 PM, Lennart Poettering lenn...@poettering.net
wrote:
On Thu, 23.10.14 16:06, Damien Robert (damien.olivier.rob...@gmail.com)
wrote:
From Lennart Poettering, Thu 23 Oct 2014 at 14:01:22 (+0200) :
On Thu, Oct 23, 2014 at 04:59:45PM +0200, Lennart Poettering wrote:
On Thu, 23.10.14 17:52, Mantas Mikulėnas (graw...@gmail.com) wrote:
On Oct 23, 2014 5:48 PM, Lennart Poettering lenn...@poettering.net
wrote:
On Thu, 23.10.14 16:06, Damien Robert (damien.olivier.rob...@gmail.com)
From Zbigniew Jędrzejewski-Szmek, Thu 23 Oct 2014 at 17:26:57 (+0200) :
order it after basic.target (which things are by default anyway)...
My proposal now, (which is the same Damien's as I understood him):
1. pam_systemd should sync on default.target
2. by default default.target should
Colin Guthrie wrote in message m1rf8b$ojg$1...@ger.gmane.org:
I want to rely on systemd --user to handle PulseAudio's activation
(ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE
might start up their own session stuff and spawn some PA consuming
process before systemd
Lennart Poettering wrote in message 20141020173828.GA4509@gardel-login:
They should probably adopt socket activation anyway, otherwise they'd
be quite annoying on multi-user systems if lingering is used.
I am brainstorming here, but would it make sense to add hooks to logind
when a session is
On Wed, 22.10.14 12:44, Damien Robert (damien.olivier.robert+gm...@gmail.com)
wrote:
Colin Guthrie wrote in message m1rf8b$ojg$1...@ger.gmane.org:
I want to rely on systemd --user to handle PulseAudio's activation
(ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE
On Oct 23, 2014 1:54 AM, Lennart Poettering lenn...@poettering.net
wrote:
On Wed, 22.10.14 12:44, Damien Robert (
damien.olivier.robert+gm...@gmail.com) wrote:
Colin Guthrie wrote in message m1rf8b$ojg$1...@ger.gmane.org:
I want to rely on systemd --user to handle PulseAudio's activation
Hi
On Sun, Oct 19, 2014 at 3:58 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Sun, Oct 19, 2014 at 12:43:59PM +0200, Colin Guthrie wrote:
David Herrmann wrote on 19/10/14 12:05:
Hi
On Fri, Oct 17, 2014 at 6:14 PM, Colin Guthrie gm...@colin.guthr.ie
wrote:
Hi,
How
On Mon, Oct 20, 2014 at 1:02 PM, David Herrmann dh.herrm...@gmail.com wrote:
Btw., manager_check_finished() doesn't explicitly wait for
default.target, but instead waits for all jobs to be done. Not sure
why..
Because default.target can be reached long before all jobs that are
part of
On Mon, Oct 20, 2014 at 02:16:30PM +0400, Andrei Borzenkov wrote:
On Mon, Oct 20, 2014 at 1:02 PM, David Herrmann dh.herrm...@gmail.com wrote:
Btw., manager_check_finished() doesn't explicitly wait for
default.target, but instead waits for all jobs to be done. Not sure
why..
Because
On Mon, Oct 20, 2014 at 4:47 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Mon, Oct 20, 2014 at 02:16:30PM +0400, Andrei Borzenkov wrote:
On Mon, Oct 20, 2014 at 1:02 PM, David Herrmann dh.herrm...@gmail.com
wrote:
Btw., manager_check_finished() doesn't explicitly wait for
On Mon, Oct 20, 2014 at 05:01:14PM +0400, Andrei Borzenkov wrote:
On Mon, Oct 20, 2014 at 4:47 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Mon, Oct 20, 2014 at 02:16:30PM +0400, Andrei Borzenkov wrote:
On Mon, Oct 20, 2014 at 1:02 PM, David Herrmann dh.herrm...@gmail.com
On Sun, 19.10.14 15:58, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
PAM creates sessions by calling into systemd's pam-module, which then
uses CreateSession() (internal api!). This call does not return until
the job of user@.service is done. `systemd --user` notifies READY=1
On Sun, 19.10.14 12:05, David Herrmann (dh.herrm...@gmail.com) wrote:
Hi
On Fri, Oct 17, 2014 at 6:14 PM, Colin Guthrie gm...@colin.guthr.ie wrote:
Hi,
How soon after login can I rely on systemd --user having reached
sockets.target?
This feels a bit like a you shouldn't rely on
On Mon, 20.10.14 11:02, David Herrmann (dh.herrm...@gmail.com) wrote:
I want to rely on systemd --user to handle PulseAudio's activation
(ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE
might start up their own session stuff and spawn some PA consuming
process
On Mon, Oct 20, 2014 at 7:59 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Sun, 19.10.14 15:58, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
PAM creates sessions by calling into systemd's pam-module, which then
uses CreateSession() (internal api!). This call does not
On Mon, 20.10.14 20:36, Mantas Mikulėnas (graw...@gmail.com) wrote:
On Mon, Oct 20, 2014 at 7:59 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Sun, 19.10.14 15:58, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl)
wrote:
PAM creates sessions by calling into systemd's
On Mon, Oct 20, 2014 at 07:07:05PM +0200, Lennart Poettering wrote:
On Mon, 20.10.14 11:02, David Herrmann (dh.herrm...@gmail.com) wrote:
I want to rely on systemd --user to handle PulseAudio's activation
(ditching the built in stuff) and but I'm worried that e.g. GNOME or
KDE
Hi
On Fri, Oct 17, 2014 at 6:14 PM, Colin Guthrie gm...@colin.guthr.ie wrote:
Hi,
How soon after login can I rely on systemd --user having reached
sockets.target?
This feels a bit like a you shouldn't rely on that point in time...
type answer is warrented, and when e.g. GNOME or KDE
David Herrmann wrote on 19/10/14 12:05:
Hi
On Fri, Oct 17, 2014 at 6:14 PM, Colin Guthrie gm...@colin.guthr.ie wrote:
Hi,
How soon after login can I rely on systemd --user having reached
sockets.target?
This feels a bit like a you shouldn't rely on that point in time...
type answer is
On Sun, Oct 19, 2014 at 12:43:59PM +0200, Colin Guthrie wrote:
David Herrmann wrote on 19/10/14 12:05:
Hi
On Fri, Oct 17, 2014 at 6:14 PM, Colin Guthrie gm...@colin.guthr.ie wrote:
Hi,
How soon after login can I rely on systemd --user having reached
sockets.target?
This feels a
On Sun, Oct 19, 2014 at 4:58 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Sun, Oct 19, 2014 at 12:43:59PM +0200, Colin Guthrie wrote:
David Herrmann wrote on 19/10/14 12:05:
Hi
On Fri, Oct 17, 2014 at 6:14 PM, Colin Guthrie gm...@colin.guthr.ie
wrote:
Hi,
How soon
Hi,
How soon after login can I rely on systemd --user having reached
sockets.target?
This feels a bit like a you shouldn't rely on that point in time...
type answer is warrented, and when e.g. GNOME or KDE sessions fully use
systemd to bring themselves up it won't be an issue, but right now,
36 matches
Mail list logo
