Re: [systemd-devel] User sessions, session buses, user buses

2015-01-30 Thread Elias Probst
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

Description: OpenPGP digital signature
systemd-devel mailing list

Re: [systemd-devel] [PATCH 11/12] Add man page and references to it.

2015-01-30 Thread Zbigniew Jędrzejewski-Szmek
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.

systemd-devel mailing list

Re: [systemd-devel] [PATCH 04/12] Add some plymouth functionality to connect and send, messages

2015-01-30 Thread Zbigniew Jędrzejewski-Szmek
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;
 +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.

systemd-devel mailing list

Re: [systemd-devel] [PATCH 04/12] Add some plymouth functionality to connect and send, messages

2015-01-30 Thread Zbigniew Jędrzejewski-Szmek
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 ( wrote:
 +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])
 +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
 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.

systemd-devel mailing list

Re: [systemd-devel] [PATCH 06/12] Support cancellation of fsck in progress

2015-01-30 Thread Zbigniew Jędrzejewski-Szmek
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
 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 
 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.)


systemd-devel mailing list

Re: [systemd-devel] [PATCH] Add usernames as arguments to tmpfiles ignore directives.

2015-01-30 Thread Zbigniew Jędrzejewski-Szmek
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 
  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 
  for user name - it is the 4th column. The advantage is that it would be 
  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, 
  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 
 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 
 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.


systemd-devel mailing list

Re: [systemd-devel] [PATCH 01/12] fsckd daemon for inter-fsckd communication

2015-01-30 Thread Zbigniew Jędrzejewski-Szmek
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
 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,, 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) {
 +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 -
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.

 +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 :)

systemd-devel mailing list

Re: [systemd-devel] Support for staged startup

2015-01-30 Thread Umut Tezduyar Lindskog

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 Since
it doesn't know about the target, units that are requested by 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


On Fri, Jan 30, 2015 at 7:06 AM, Hoyer, Marko (ADITG/SW2) wrote:
 Hi Alison,

 -Original Message-
 From: Alison Chaiken []
 Sent: Thursday, January 29, 2015 8:17 PM
 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
  - 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

 Marko, one target can already be specified as After another.   If is present in one of the appropriate directories and specifies

 and all the services of the final sub-tree are symlinked in a directory, doesn't the behavior you need result?   What
 is  missing?Of course, some of the units linked in
 may already be started by the time 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
 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 mailing list

Re: [systemd-devel] Docker vs PrivateTmp

2015-01-30 Thread Alexander Larsson
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 ( wrote:
  See the `devicemapper` mountpoint created by Docker for the container:
  # grep devicemapper/mnt /proc/mounts
  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 
  Driver devicemapper failed to remove root filesystem
  Device is
  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 
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 

systemd-devel mailing list

Re: [systemd-devel] What's the correct way to configure encrypted volume and mount point?

2015-01-30 Thread Jan Janssen
John Lane systemd at 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?

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.


systemd-devel mailing list

Re: [systemd-devel] Programmatically setting udev properties

2015-01-30 Thread Martin Pitt
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

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 Pitt|
Ubuntu Developer (  | Debian Developer  (
systemd-devel mailing list

Re: [systemd-devel] Programmatically setting udev properties

2015-01-30 Thread Martin Pitt
Tomasz Torcz [2015-01-29 23:42 +0100]:
   Have you seen 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). 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 Pitt|
Ubuntu Developer (  | Debian Developer  (
systemd-devel mailing list

Re: [systemd-devel] crash after commit core: make setting the shutdown watchdog configuration via dbus work

2015-01-30 Thread Kay Sievers
On Thu, Jan 29, 2015 at 6:35 PM, Cristian Rodríguez 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
 1832arg_shutdown_watchdog = m-shutdown_watchdog;

 gdb) p m
 $3 = (Manager *) 0x0


systemd-devel mailing list

[systemd-devel] [PATCH] config_parse_set_status: put signals in the correct set

2015-01-30 Thread Michael Olbrich
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;
+set = status_set-signal;
 } else {
 if (val  0 || val  255) {
 log_syntax(unit, LOG_ERR, filename, line, 
Value %d is outside range 0-255, 
ignoring, val);
+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);

systemd-devel mailing list

[systemd-devel] User sessions, session buses, user buses

2015-01-30 Thread Simon McVittie
[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.


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.


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 you can construct a
multi-seat machine.


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

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