[systemd-devel] [PATCH 1/2] bus: use existing macros from def.h
---
src/login/pam-module.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/login/pam-module.c b/src/login/pam-module.c
index c67e677..e76fef8 100644
--- a/src/login/pam-module.c
+++ b/src/login/pam-module.c
@@ -173,7 +173,7 @@ static int export_legacy_dbus_address(
_cleanup_free_ char *s = NULL;
int r;
-if (asprintf(s,
kernel:path=/dev/kdbus/%lu-user/bus;unix:path=%s/bus,
+if (asprintf(s, KERNEL_USER_BUS_FMT ; UNIX_USER_BUS_FMT,
(unsigned long) uid, runtime) 0) {
pam_syslog(handle, LOG_ERR, Failed to set bus variable.);
return PAM_BUF_ERR;
--
1.8.5.1.277.g0e0d235
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] bus: export bus address also when compiled without kdbus
It was removed from user@.service, so it should be added here.
---
src/login/pam-module.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/login/pam-module.c b/src/login/pam-module.c
index e76fef8..ea606b7 100644
--- a/src/login/pam-module.c
+++ b/src/login/pam-module.c
@@ -169,22 +169,28 @@ static int export_legacy_dbus_address(
uid_t uid,
const char *runtime) {
-#ifdef ENABLE_KDBUS
_cleanup_free_ char *s = NULL;
int r;
+#ifdef ENABLE_KDBUS
if (asprintf(s, KERNEL_USER_BUS_FMT ; UNIX_USER_BUS_FMT,
(unsigned long) uid, runtime) 0) {
pam_syslog(handle, LOG_ERR, Failed to set bus variable.);
return PAM_BUF_ERR;
}
+#else
+if (asprintf(s, UNIX_USER_BUS_FMT, runtime) 0) {
+pam_syslog(handle, LOG_ERR, Failed to set bus variable.);
+return PAM_BUF_ERR;
+}
+#endif
r = pam_misc_setenv(handle, DBUS_SESSION_BUS_ADDRESS, s, 0);
if (r != PAM_SUCCESS) {
pam_syslog(handle, LOG_ERR, Failed to set bus variable.);
return r;
}
-#endif
+
return PAM_SUCCESS;
}
--
1.8.5.1.277.g0e0d235
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] bus: use existing macros from def.h
On Wed, Jan 8, 2014 at 8:08 PM, Mantas Mikulėnas graw...@gmail.com wrote: --- src/login/pam-module.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] bus: export bus address also when compiled without kdbus
On Wed, Jan 8, 2014 at 8:08 PM, Mantas Mikulėnas graw...@gmail.com wrote: It was removed from user@.service, so it should be added here. --- src/login/pam-module.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/4] bus: driverd: don't attempt to remove from empty list
On Sun, Jan 5, 2014 at 10:56 PM, Kay Sievers k...@vrfy.org wrote: On Sun, Jan 5, 2014 at 11:37 AM, Kay Sievers k...@vrfy.org wrote: On Sat, Dec 28, 2013 at 8:54 AM, Marc-Antoine Perennou marc-anto...@perennou.com wrote: --- src/bus-driverd/bus-driverd.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Applied. And reverted it again, we need to find out what's really going wrong here, not avoid the symptoms. This seems to work for me: http://cgit.freedesktop.org/systemd/systemd/commit/?id=234e28aa1cd37dee597c719ac5ca004c6215d28c Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Create a new logind session from a systemd --user unit
[ I'm going to trim the CC, I'm pretty sure everyone who has commented so far is on systemd-devel ] On Wed, 2014-01-08 at 13:55 +0100, David Herrmann wrote: This basically defeats the whole purpose of a session. A lot of it, yes. The session becomes: * A refcount on the user@.service * A claim of particular devices (tty, X server) If you now do session.kill(), you kill both logins. That's not intentional, I guess. No. The only process actually in the session cgroup would be a stub. Asking logind to kill it would cause it to release the fd and hence drop a ref on the user@.service. Only once all sessions are closed would the user@.service terminate. * If two logins (of the same user) are associated with different seats, this is not really supported at the moment, so we could ban it, or we could simply allow it and temporarily merge the two seats and let the session controller (window manager) deal with how that should be presented to the user. This would probably mean that we want logind's interfaces for getting hardware devices should be per-user, and not per-session. Yeah...this bit is tricky. For the case of GNOME where it's simply not supported to log in multiple times, all we need is a mechanism to discover the X server that gdm spawned (not as part of the session or user@.service). The way that works in my prototype patches is that GDM sets the x11-display property via PAM, and then systemd writes that to $XDG_RUNTIME_DIR. From there, libX11 can pick it up automatically. Now, for session controllers that want to support multiple logins, it gets far more complex. I think they'd have to do something like what you were saying with double templating (somecontroller@num.service). Or as I say below, these controllers just stay as they are today. I talked to Jasper about this shortly. I really think we need to discuss this at FOSDEM. What he said is that they try to ditch sessions entirely and move to user-based sessions instead. So if you login multiple times as the same user, you always join the same session (or are rejected, whatever your policy is). A lot hinges on the precise meaning of join here. Presently, gdm will just VT-switch you to your original X server if you try to log in again. * Multi-seat: You cannot login as the same user on two seats simultaneously. This would require running systemd --user twice for the same user. I'm not sure whether that is possible? Same requirement would be given for the user-bus, etc.. We could use unit-templates, something like systemd-consoled@num.seat.service. However, multi-layer templates seem cumbersome. Or session controllers that want to do this simply don't run per user; they just continue to have all of their processes in the session cgroup and work just as they do today. I can't think of a problem with that. * Session-assignment: This is the bigger problem, imho. If we run processes as systemd --user units, these services are childs of systemd, not of gnome-session or else. As systemd does not run in a session, the units itself cannot inherit a session. So we really destroy the session concept then for anything that runs for the whole user. Yes, as I said; I think we'll all have to come to grips with the idea that a session is just a refcount on user@.service with some metadata; it no longer holds the process tree. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Patch 0/2] logind: make sure that closed sessions will be cleaned
ping?
(Please if I'm missing something let me know)
On Fri, Jan 03, 2014 at 02:19:19PM +0100, Djalal Harouni wrote:
On logout pam_systemd should ensures the following:
If the last concurrent session of a user ends, the $XDG_RUNTIME_DIR
directory and all its contents are removed, too. from manpage.
Using git HEAD, and a simple systemd-nspawn test will show that the
above is not ensured and the sessions will stay!
A simple systemd-nspawn test:
1) login as user X
2) logout
3) login as user Y
4) loginctl (will list session of user X)
In this example we are session c4:
-bash-4.2# loginctl list-sessions
SESSIONUID USER SEAT
1 1000 tixxdz seat0
c1 1000 tixxdz seat0
c2 0 root seat0
c3 1000 tixxdz seat0
c4 0 root seat0
-bash-4.2# loginctl show-session --property=State 1 c1 c2 c3 c4
State=closing
State=closing
State=closing
State=closing
State=active
As shown only session c4 is active, all the others are dead sessions.
To close the dead sessions and clean things up, a dbus
TerminateSession()=session_stop() must be issued...
Please note that I'm running without pam_loginuid.so, due to another
bug related to audit: https://bugzilla.redhat.com/show_bug.cgi?id=966807
Anyway, after some debugging:
It seems that after ReleaseSession() which is called by pam_systemd,
the user,session and seat state files will also still be available.
The garbage-collector will miss them!
In src/login/logind.c:manager_gc() the while loops will never be entered.
The user slice units will start, then the match_job_removed() and co
signals on these units will call session_add_to_gc_queue() and
user_add_to_gc_queue() to push to gc_queue when done, in the mean time
the manager_gc() will consume the gc_queue and remove them
IOW *just* before and after the ReleaseSession() the manager
{session|user}_gc_queue queues might be empty, hence session, users
and seats will never be cleaned! the user's slice will still be alive...
To fix this, I'm attaching two patches and I can say that they are
related to each other from the perspective of the described bug, and at
the same time they are independent of each other from a general
perspective!
1) Make method_release_session() call session_add_to_gc_queue()
This will ensure that the released session is in the gc_queue.
This change gives the garbage collector a chance to collect sessions,
and should not affect the logind behaviour and other display managers,
the session_check_gc() is able to detect if the session is still valid.
The thing is that from a quick git log the method_release_session()
never called session_add_to_gc_queue(), so this bug was introduced or
made *visible* by another change... (not sure)
2) As in commit 63966da86d8e, in function session_check_gc() the session
manager will always be around so don't check it in order to
garbage-collect the session.
Thanks!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Djalal Harouni
http://opendz.org
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Patch 0/2] logind: make sure that closed sessions will be cleaned
On Wed, Jan 08, 2014 at 05:12:23PM +0100, Djalal Harouni wrote: ping? (Please if I'm missing something let me know) No. I think that nobody had time to review this. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journal: how to query journal to see ALL output of given unit?
On 07/01/14 22:35, Zbigniew Jędrzejewski-Szmek wrote: That's what I'd guess too. Does is get fixed if you insert 'sleep 1' in mysql-check.sh before it exits? This seems likely because the output suggests that the script is short-lived. Yes. It helps. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Patch 0/2] logind: make sure that closed sessions will be cleaned
On Wed, Jan 08, 2014 at 05:29:05PM +0100, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Jan 08, 2014 at 05:12:23PM +0100, Djalal Harouni wrote: ping? (Please if I'm missing something let me know) No. I think that nobody had time to review this. Zbyszek Ok, thank you Zbyszek! -- Djalal Harouni http://opendz.org ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] TTY ownership and systemd user session
Hi, I am bringing up systemd user session in Tizen, I am using v208. We run into a small issue that if a user session service file claims TTY, systemd user session will fail to chown_terminal() for it: Failed at step STDIN spawning /usr/bin/xorg-launch-helper: Permission denied My testing service file has something like this: [Service] StandardInput=tty TTYPath=/dev/tty1 ExecStart=/usr/bin/xxx I tried to look into the code... The failure seems happen after systemd --user forked and about the exec into the new process, in execute.c:exec_spawn(), when calling chown_terminal(). So my question is: * does systemd depend on other (e.g. udev) to set the /dev/tty1 permission beforehand? Or * should we do the chown_terminal() stuff in PAM/pam_systemd after we got the PAM_TTY? since otherwise it's too late to do it in exec_spawn(), it's already running as normal user, you can't chown /dev/tty1 etc. Please help me to understand this, and anything I am missing. Thanks. Regards, Kangkai ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
