Re: [systemd-devel] User sessions, session buses, user buses
On 01/30/2015 09:30 AM, Simon McVittie wrote: Remaining issue: environment variables == […] As a short-term solution, I'm tempted to write that tool, but make it only upload a whitelisted set of variables automatically, and say if you install dbus-user-bus, you are expected to run this tool from your ~/.xsession if you need it. IMHO, env variables are something we should get rid of in the long term. It might be fine for now to provide some legacy-compatibility mechanisms (like your not-yet-written tool), but to me environment variables are something straight out of the dark ages. The long-term goal (also in a world where a graphical session is managed as a systemd user-session), the information provided until now by an environment variable should be queried dynamically by e.g. a D-Bus call to the component responsible for providing the relevant information. I know that there are huge numbers of applications/toolkits/… out there making use of environment variables for various use cases, but this shouldn't keep us from looking into the distant future where environment variables are a thing of the past. - Elias signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 11/12] Add man page and references to it.
On Thu, Jan 29, 2015 at 06:46:40PM +0100, Didier Roche wrote: This is very detailed too, but it is OK, we don't really have a good place for this kind of documentation. Yeah, some API for plymouth theme authors. I didn't find a better place (or the systemd wiki?) The wiki tends to get outdated... This text is not too long and it'll be easier to find and maintain here. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 04/12] Add some plymouth functionality to connect and send, messages
On Thu, Jan 29, 2015 at 06:42:42PM +0100, Didier Roche wrote:
Le 28/01/2015 15:44, Zbigniew Jędrzejewski-Szmek a écrit :
On Wed, Jan 28, 2015 at 02:22:04PM +0100, Didier Roche wrote:
bool plymouth_running(void) {
return access(/run/plymouth/pid, F_OK) = 0;
}
+
+#ifdef HAVE_PLYMOUTH
+bool plymouth_connect(void) {
Is there a particular reason why this cannot return a normal int code?
No reason, I changed to 0 for connected, -1 for can't connect.
No, please return a real return code (-ENOMEM on the allocation failure
in this case). -1 is EPERM.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 04/12] Add some plymouth functionality to connect and send, messages
On Thu, Jan 29, 2015 at 06:43:22PM +0100, Didier Roche wrote: Le 28/01/2015 21:22, Lennart Poettering a écrit : On Wed, 28.01.15 14:22, Didier Roche (didro...@ubuntu.com) wrote: # -- +have_plymouth=no +AC_ARG_ENABLE(plymouth, AS_HELP_STRING([--disable-plymouth], [disable plymouth integration])) +if test x$enable_plymouth != xno; then +PKG_CHECK_MODULES([PLYMOUTH], [ply-boot-client = 0.8.0], +[AC_DEFINE(HAVE_PLYMOUTH, 1, [Define if plymouth is available]) have_plymouth=yes], have_plymouth=no) +if test x$have_plymouth = xno -a x$enable_plymouth = xyes; then +AC_MSG_ERROR([*** plymouth integration requested but libraries not found]) +fi +fi +AM_CONDITIONAL(HAVE_PLYMOUTH, [test $have_plymouth = yes]) Hmm, I am bit concerned about adding this dependency. So far we managed to talk to plymouth without using its library, and I am really not sure we should start doing so now. So far the messages to send were so simply that it really wasn't worth the effort to use the full library. This is doable for the first part, similar to what src/tty-ask-password-agent/tty-ask-password-agent.c is doing (using the socket directly to send update and message to it). I'm quite unsure watch and get key events part as looking at libplymouth code, this seems quite more complex as a protocol to achieve. If you feel that needs to be done anyway, I can look deeper at this if you really feel we should reimplement libplymouth protocol rathen than having an optional dep on it. plymouth-core-libs are 200kb in Fedora. I wouldn't sweat it too much. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 06/12] Support cancellation of fsck in progress
On Thu, Jan 29, 2015 at 06:44:23PM +0100, Didier Roche wrote: Le 28/01/2015 15:53, Zbigniew Jędrzejewski-Szmek a écrit : On Wed, Jan 28, 2015 at 02:22:54PM +0100, Didier Roche wrote: From 104cf82ba28941e907f277a713f834ceb3d909f0 Mon Sep 17 00:00:00 2001 From: Didier Roche didro...@ubuntu.com Date: Mon, 26 Jan 2015 16:40:52 +0100 Subject: [PATCH 06/12] Support cancellation of fsck in progress Grab in fsckd plymouth watch key for C or c, and propagate this cancel request to systemd-fsck which will terminate fsck. Could we bind to ^c or if this is not possible, three c's in three seconds instead? I'm worried that before you could press anything to little effect in plymouth, and now a single key will have significant consequences. I tried to have a look at libplymouth, and if I'm correct, it's not possible to listen and get events for compose keys, so no way to get something like Control+C. As Dimitri told, it's been quite some years we are doing that in ubuntu, and that's the reason why we show a message to ensure the user is aware about that key (and that's why this patch is doing). Is it good for you this way? I think so. We can always improve the interface later on if it's confusing for users. (If plymouth forwards the key to us, we could detect triple c within two seconds ourselves. But if you think that a single key is fine, than that's fine for me.) Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add usernames as arguments to tmpfiles ignore directives.
On Mon, Jan 12, 2015 at 06:03:31PM +0100, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Jan 12, 2015 at 03:11:08PM +0100, Thomas Blume wrote: On Donnerstag 2015-01-08 21:29, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Jan 08, 2015 at 01:37:57PM +0100, Thomas Blume wrote: Currently, systemd can only ignore files specified by their path, during tmpdir cleanup. This patch adds the feature to give usernames as argument. During cleanup the file ownership is checked and files that match the specified usernames are ignored. For example, you could give: X /tmp/* - - - - testuser3,testuser2 I think the patch is useful, but the syntax is wrong. We already have a field for user name - it is the 4th column. The advantage is that it would be natually possible to extend it to groups. I was looking at the UID column, but it seems that only one username can be passed that way. For a list of usernames, I'd have to tweak the get_user_creds function, which seemed too intrusive to me. In addition i-uid_set is set when UID is present, and I didn't want to have some undesired side effects from this. I started refactoring the code because I want to add ACL setting functionality. I tried to add new functionality to the current code, but it was very messy. I'm maybe halfway done, so you can expect an update to this code within a week. One of the changes I'm doing is to allow multiple Items for the same path. This should make it very easy to support multiple UIDs (and GIDs) by simply parsing multiple lines, each specifying a single UID. This part has now been merged. I also fixed a fairly interesting bug where tmpfiles would bump the access time of the directories it was looking at and prevent their cleanup. Now there are also debug statements attached to all operations, so it is possible to follow what tmpfiles is doing more easily. I think it should be fairly easy to rebase your patch on top of that. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 01/12] fsckd daemon for inter-fsckd communication
On Thu, Jan 29, 2015 at 06:37:53PM +0100, Didier Roche wrote:
Le 28/01/2015 15:37, Zbigniew Jędrzejewski-Szmek a écrit :
On Wed, Jan 28, 2015 at 02:20:40PM +0100, Didier Roche wrote:
Hey Zbigniew,
Thanks for the quick feedbacks! Integrated your changes in the
incoming patches. Just answered to some comments here:
From d0f49b4e0994b9a1dd2738da18c5a2a6708b444f Mon Sep 17 00:00:00 2001
From: Didier Roche didro...@ubuntu.com
Date: Mon, 26 Jan 2015 15:35:50 +0100
Subject: [PATCH 01/12] fsckd daemon for inter-fsckd communication
+fsckd_fd = socket(AF_UNIX, SOCK_STREAM | SOCK_NONBLOCK, 0);
+if (fsckd_fd 0) {
+log_warning_errno(errno, Cannot open fsckd socket, we
won't report fsck progress: %m);
+return -errno;
+}
+if (connect(fsckd_fd, sa.sa, offsetof(struct sockaddr_un,
sun_path) + strlen(sa.un.sun_path)) 0) {
+log_warning_errno(errno, Cannot connect to fsckd socket,
we won't report fsck progress: %m);
+return -errno;
+}
f = fdopen(fd, r);
if (!f) {
-safe_close(fd);
+log_warning_errno(errno, Cannot connect to fsck, we won't
report fsck progress: %m);
return -errno;
}
There's a double close now, since both f and fsckd_fd refer to the same fd.
Actually no, fd is the fd from the pipe between fsck - systemd-fsck
and fsckd_fd is the fd from the socket between systemd-fsck -
systemd-fsckd.
You're right. Seems to be fine.
Or am I missing something?
\ No newline at end of file
diff --git a/src/fsckd/fsckd.c b/src/fsckd/fsckd.c
new file mode 100644
index 000..3059c68
--- /dev/null
+++ b/src/fsckd/fsckd.c
@@ -0,0 +1,295 @@
+/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
+
+}
+
+static int handle_requests(int socket_fd) {
+Clients *first = NULL;
+usec_t last_activity = 0;
+int numdevices = 0, clear = 0;
+double percent = 100;
+_cleanup_fclose_ FILE *console = NULL;
NULL not necessary (and you don't have it in similar circumstances above ;))
So, after the discussion on the mailing list and to be more future
proof, I went to recheck, but I'm afraid that I didn't find any
place where I have some _cleanup_* without initializing to NULL? Did
I get it wrong?
fsckd_fd variable.
+log_error_errno(errno, Socket read error,
disconnecting fd %d: %m, current-fd);
+current-fd = 0;
0 is a valid file descriptor number. You must use -1. This also means that
some initialization
to -1 is missing.
The clients are always initialized when we get a valid fd
(current-fd = new_client_fd;), so no need to initiliaze to -1, I'm
using now -1 though to invalidate the fd.
OK.
+static int create_socket(void) {
Can you base this on make_socket_fd() instead?
Oh nice, didn't find it when I looked for a generic utility. Using it :)
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Support for staged startup
Hi,
What you have figured out is so far the only way if you want to have
dynamic targets.
If you do not use --no-block to start your second target, first
target will never finish.
Other caveat of your way is that systemd doesn't know about your final
target until it receives systemctl start destination.target. Since
it doesn't know about the target, units that are requested by
destination.target will not have the default dependencies applied.
For example, if your destination target WANTS hello.socket (which has
DefaultDependencies=yes), hello.socket will not be started before
socket.target.
Umut
On Fri, Jan 30, 2015 at 7:06 AM, Hoyer, Marko (ADITG/SW2)
mho...@de.adit-jv.com wrote:
Hi Alison,
-Original Message-
From: Alison Chaiken [mailto:ali...@she-devel.com]
Sent: Thursday, January 29, 2015 8:17 PM
To: systemd-devel@lists.freedesktop.org
Cc: Hoyer, Marko (ADITG/SW2)
Subject: Re: Support for staged startup
Marko Hoyer asks:
I'd like to realize a staged startup with systemd which is mainly
about:
- starting up a static tree up to a final service
- the only job of the final service is to kick off the start of an
additional sub tree of units This kind of startup could be realized
simply by adding an additional one shot service which executes:
systemctl start xxx.target
Marko, one target can already be specified as After another. If
B.target is present in one of the appropriate directories and specifies
After=A.target
and all the services of the final sub-tree are symlinked in a
B.target.wants directory, doesn't the behavior you need result? What
is missing?Of course, some of the units linked in B.target.wants
may already be started by the time A.target completes if they are part
of a earlier target or if they are needed by an earlier unit. To
suppress that behavior, you'd have to edit the individual units.
I don't know of any use case for one unit to start another directly.
Is there one?
1.) Coming up with a small tree first reduces the loading time of the unit
set (not so much important in my case)
2.) If you wanna create some dynamics between target A and target B so that
depending on the startup situation services are already started before A or
in another round they are delayed until A is done, you probably need to
disconnect them from the static startup tree and pull them in dynamically at
the desired time.
-- Alison
--
Alison Chaiken ali...@she-devel.com
650-279-5600
http://{she-devel.com,exerciseforthereader.org}
Never underestimate the cleverness of advertisers, or mischief makers,
or criminals. -- Don Norman
Best regards
Marko Hoyer
Software Group II (ADITG/SW2)
Tel. +49 5121 49 6948
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Docker vs PrivateTmp
On fre, 2015-01-23 at 11:31 -0500, Daniel J Walsh wrote:
On 01/22/2015 10:02 PM, Lennart Poettering wrote:
On Sat, 17.01.15 23:02, Lars Kellogg-Stedman (l...@redhat.com) wrote:
See the `devicemapper` mountpoint created by Docker for the container:
# grep devicemapper/mnt /proc/mounts
/dev/mapper/docker-253:6-98310-e68df3f45d6151259ce84a0e467a3117840084e99ef3bbc654b33f08d2d6dd62
/var/lib/docker/devicemapper/mnt/e68df3f45d6151259ce84a0e467a3117840084e99ef3bbc654b33f08d2d6dd62
ext4
rw,context=system_u:object_r:svirt_sandbox_file_t:s0:c261,c1018,relatime,discard,stripe=16,data=ordered
0 0
I am not sure why docker makes these mounts visible in the host
namespace at all. This smells like a bug.
They need to at least be visible to the docker daemon, because it needs
to look into it to do diffs between images when e.g. commiting. It
doesn't necessarily have to be in the host namespace though, it could be
in a different namespace owned only by the docker daemon. I wanted to do
that, but for reasons that escape me at the moment that was problematic
and I never got to it.
Watch Docker fail to destroy the container because it is unable to remove
the mountpoint directory:
Jan 17 22:43:03 pk115wp-lkellogg docker-1.4.1-dev[18239]:
time=2015-01-17T22:43:03-05:00 level=error msg=Handler for DELETE
/containers/{name:.*} returned error: Cannot destroy container
e68df3f45d61:
Driver devicemapper failed to remove root filesystem
e68df3f45d6151259ce84a0e467a3117840084e99ef3bbc654b33f08d2d6dd62:
Device is
Busy
This smells as if Docker incorrectly sets the mount propagation bits
on its own mounts.
It would be good checking /proc/self/mountinfo inside and outside of
docker's own namespace, and checking how the propagation bits are set
for the individual mounts. It's a bit hard to read, but the
interesting bits are in the 7th column of that file.
In general: docker should do the equivalent of mount --make-rslave /
as first thing after opening its mount namespace, so that from that
point on mounts and especiall *un*mounts propagate from the host into
the container, but not vice versa.
If they do not invoke that, then the propagation will stay at
shared, which means the mounts will appear in the host and vice
versa, which is certainly undesired.
Also, they should not use mount --make-rprivate /, as that means
anything the host mounted will stay mounted in the container forever,
which is a problem.
Also, they really need to make this recursive, so that all mount
points they have access too are detached from the host!
It was a while since I looked at this, but i believe that the docker
containers run as MS_PRIVATE, and they explicitly unmount all the host
filesystems exept the ones specifically mounted in as volumes.
I think the problem is that docker daemon makes
/var/lib/docker/devicemapper private in the host namespace to handle
some scalability issues we found in the kernel. This causes problem not
with docker containers (because they unmount all other mounts as per the
above), but with other namespace-using apps. For instance, if a service
with PrivateTmp is launched, it will inherit the existing mounts
in /var/lib/docker/devicemapper at the point of startup, but when these
are eventually unmounted in the host namespace this is not propagated
into the service (due to it being a private mount, not a slave mount).
We could try making this slave instead, but I don't know if that then
fixes the scalability issues we had, because they were related to
stupidities in the kernel wrt propagating mounts. If it doesn't work,
then we have to put docker-daemon in its own namespace.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexander.lars...@gmail.com
He's an impetuous amnesiac hairdresser who dotes on his loving old ma.
She's an elegant Bolivian single mother from out of town. They fight
crime!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What's the correct way to configure encrypted volume and mount point?
John Lane systemd at jelmail.com writes: $ mount /home/myuser/data mount: special device /dev/mapper/keyring does not exist Your crypttab entry uses noauto as an option. This means that it won't get activated and no plain text device is created. Hence your manual mount can only fail. I'm guessing that mount doesn't effect systemd and, therefore, the dependency isn't actioned. But the docs for systemd.mount state that configuring mount points through /etc/fstab is the preferred approach so I'm wondering if there's something I missed from my crypttab or fstab entries? Thanks. But really: why not use automounting logic in fstab?: /dev/mapper/data /home/myuser/data ext4 noauto,x-systemd.automount 0 0 No need to manually trigger a mount. And you can even use noauto in crypttab so that the encrypted device is only opened once the mount point is accessed the first time. Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Programmatically setting udev properties
Peter Hutterer [2015-01-30 8:12 +1000]: Because of uinput, the test suite runs as root. One solution would be to drop a custom test rule, reload, create the uinput device, run the test, rm the rule again. Not pretty though, I was hoping there was something nicer. I'm not aware of anything nicer either, apart from completely faking everything (cf. umockdef in the other part of the thread). Your test suite can create/use /run/udev/rules.d/ to at least ensure that the custom rule at least won't be around forever if your test fails without being able to clean up after itself. That's the approach that e. g. the gvfs tests use (see test/gvfs-testbed in the source tree). Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Programmatically setting udev properties
Tomasz Torcz [2015-01-29 23:42 +0100]: Have you seen umockdev? https://github.com/martinpitt/umockdev/ Right, with that you can run your tests as normal user, completely isolated from the actual system, and you can set up/change devices, attributes and properties at any time without restrictions. umockdev supports its own device and ioctl dump/restore format, but it can also read and write the evemu format (that might be useful for you). https://github.com/martinpitt/umockdev has a summary of what this does and how to use it. I'm happy to discuss that further with you (perhaps on PM/IRC/etc.) if you are interested. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] crash after commit core: make setting the shutdown watchdog configuration via dbus work
On Thu, Jan 29, 2015 at 6:35 PM, Cristian Rodríguez crrodrig...@opensuse.org wrote: systemd crashes after that commit with gdb --args ./systemd Failed to create root cgroup hierarchy: Permission denied Failed to allocate manager object: Permission denied Program received signal SIGSEGV, Segmentation fault. 0x55574ec4 in main (argc=1, argv=0x7fffdac8) at src/core/main.c:1832 1832arg_shutdown_watchdog = m-shutdown_watchdog; gdb) p m $3 = (Manager *) 0x0 Reverted. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] config_parse_set_status: put signals in the correct set
This was broken when the code was rearranged in 1e2fd62d70ff
core/load-fragment.c: correct argument sign and split up long lines
---
src/core/load-fragment.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/core/load-fragment.c b/src/core/load-fragment.c
index 516731aba26c..571bb64b7824 100644
--- a/src/core/load-fragment.c
+++ b/src/core/load-fragment.c
@@ -3150,6 +3150,7 @@ int config_parse_set_status(
FOREACH_WORD(word, l, rvalue, state) {
_cleanup_free_ char *temp;
int val;
+Set **set;
temp = strndup(word, l);
if (!temp)
@@ -3162,21 +3163,23 @@ int config_parse_set_status(
if (val = 0) {
log_syntax(unit, LOG_ERR, filename, line, -val,
Failed to parse value, ignoring:
%s, word);
-return 0;
+continue;
}
+set = status_set-signal;
} else {
if (val 0 || val 255) {
log_syntax(unit, LOG_ERR, filename, line,
ERANGE,
Value %d is outside range 0-255,
ignoring, val);
continue;
}
+set = status_set-status;
}
-r = set_ensure_allocated(status_set-status, NULL);
+r = set_ensure_allocated(set, NULL);
if (r 0)
return log_oom();
-r = set_put(status_set-status, INT_TO_PTR(val));
+r = set_put(*set, INT_TO_PTR(val));
if (r 0) {
log_syntax(unit, LOG_ERR, filename, line, -r,
Unable to store: %s, word);
--
2.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] User sessions, session buses, user buses
[For those who are there, I'll be at the system hackfest today and at FOSDEM this weekend, so if you are interested in these topics, please talk to me about them; I'll try to summarize discussion to these lists. For those not there, I'll try to keep up with responses via email and raise any interesting points in person.] I've recently been looking into D-Bus' interaction with X session startup, systemd --user, upstart --user, and the definition of a session. Every few months or years there is an attempt to sort out whether D-Bus has a user bus or a session bus or what. Here is another, with particular reference to systemd and potentially kdbus. Terminology === login session - A *login session* is as follows: when you log in to *dm, that starts a *graphical login session* which lasts until you log out. When you log in on a virtual console or via ssh or something, that starts a *non-graphical login session*. Background processes like cron or screen might also be non-graphical login sessions. A non-graphical login session might become graphical by running startx or similar. In a systemd-logind environment, login sessions have an ID which is made available to in-session processes in the XDG_SESSION_ID environment variable. If the Linux auditing feature is enabled, the XDG_SESSION_ID equals the audit session ID (/proc/self/sessionid). If not, there is no audit session ID, so systemd-logind makes up a sequential XDG_SESSION_ID and uses that. seat A seat is a set of displays, input devices etc. attached to a machine. Most machines have one seat seat0, which occupies all the devices. By attaching additional devices via something like http://plugable.com/products/ud-160-m you can construct a multi-seat machine. user-session I don't think there is a standard term for this so I'm making one up. The XDG_RUNTIME_DIR specification says that there is at most one XDG_RUNTIME_DIR per uid per machine, that it is created at the beginning of the user's first login session, and that it is removed at the end of a login session if no other login sessions remain for that uid. systemd-logind implements those semantics, and also runs a `systemd --user` for the lifetime of the user-session. Ubuntu previously used libpam-xdg-runtime to provide compatible semantics without systemd. The resulting situation looks something like this (assume all the sessions shown are under the same uid): \ \\ login | user- || session | \ session || - overlapping login session c42 23 | login | ||shares the user-session with 23 / session | || - 23 ends but c42 keeps u.-session c42 | ||alive \ | || - 57 begins, shares u.-sess. login | / || - c42 ends, 57 keeps user-session session | ||alive 57 | || / // no more l.sessions, u.-session ends \ \\ new l.session, u.-session starts login | user- || session | session || ... . ... .. user-sessions do not have any meaningful identifier apart from their owner's uid (strictly speaking, the owner's loginuid, i.e. the user who initially logged in, even if they su). They do not need another identifier, because by definition there is only one per uid at a time. Impact on D-Bus === There are two models for how the D-Bus session bus, which is designed to be per high-level session (whatever that means), can work in a world with user-sessions. Last time this was discussed, Havoc had the useful insight that this is not really a question about D-Bus, it's a question about how you build OSs, and in particular how you model sessions. (Up to) one high-level session per login The first model, which is how it traditionally worked (before there was such a thing as a user-session), is that each graphical login session is declared to be a session, and non-graphical login sessions are pretty much swept under the carpet and forgotten about. In graphical sessions, vaguely modern Unix OSs typically know how to start up a dbus-daemon during the creation of a graphical session (e.g. in Debian and derivatives it's started by /etc/X11/Xsession.d, and Fedora derivatives have a similar setup under a different name). If they don't, modern desktop environments also know how to start a dbus-daemon if they need one (e.g. gnome-session does this for GNOME), and if *that* doesn't start one (the I use Firefox under fvwm use-case), we have a slightly shaky but functional autolaunch mechanism based on X11 properties. In principle, a PAM module or something could ensure that we have a dbus-daemon per login session, even tty/ssh/cron login sessions (which all go through
