Bug#909192: mate-desktop-environment: Installing sysvinit-core removes mate-desktop-environment

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Mike Gabriel writes ("Re: Bug#909192: mate-desktop-environment: Installing sysvinit-core removes mate-desktop-environment"):
> many thanks for all this background info. I might have a potential  
> contract to get this solved in the loop, so, I may probably return to  
> it soon (or not so soon). Let's see...

Can you let us know when you will know whether this is going to
transpire ?

Also, we had an IRC conversation on #debian-devel about pam_systemd
and the dbus user service.  I think it contains a lot of useful
information particularly from smcv.  See below.

This is a transcript of #debian-devel manually edited to remove other
conversations, and also to remove unconstructive comments (of which
unfortunately there were some).

Ian.

15:40 <sunweaver> is it so that desktop envs that depend on DBus user sessions, can't run on SysV systems anymore?
15:40 <sunweaver> see #909192
15:40 -zwiebelbot:#debian-devel- Debian#909192: mate-desktop-environment: Installing sysvinit-core removes mate-desktop-environment - https://bugs.debian.org/909192
15:40 <sunweaver> if people can contribute to finding a solution, I'd be happy for posts sent directly to the bug. Thanks.
15:41 <Diziet> sunweaver: This seems like some kind of mistake.
15:41 <Diziet> What is `dbus-user-session' ?  It sounds like a thing that could be provided without trouble on sysvinit systems.
15:41 <Diziet> I mean, I probably have one right here (although stretch, not buster)
15:42 <wRAR> sunweaver: "It has a dependency on systemd's userspace part, but not on systemd as   PID one."
15:42 <Diziet> I think that is possibly a reference to systemd-logind ?
15:42 <Diziet> I don't see why a dbus user session would depend on that.
15:42 <sunweaver> I guess so, too.
15:43 <Diziet> Also "systemd" is not the pid 1 part.
15:43 <ansgar> Diziet: Because they didn't want to implement their own session management?
15:43 <Diziet> So I don't see why "systemd" and "sysvinit-core" aren't coinstallable.
15:43 <Diziet> I have them both here on my laptop which is using systemd-logind (stretch, again).
15:43 <Diziet> ansgar: I'm not sure what you mean by session management.  This all works in stretch.
15:44 <ansgar> sunweaver: It depends on libpam-systemd which depends on systemd-sysv
15:44 <wRAR> yes, "systemd" is not the pid 1 part
15:44 <wRAR> so the problem is not the chain in the last email
15:44 <ansgar> Diziet: I assume we aren't talking about stretch.
15:44 <Diziet> ansgar: Indeed I think that bug isn't.
15:44 <wRAR> Depends: libc6 (>= 2.26), libpam0g (>= 0.99.7.1), systemd (= 239-9), libpam-runtime (>= 1.0.1-6), dbus, systemd-shim (>= 10-4~) | systemd-sysv
15:45 <Diziet> But knowing how this all works in at least one stretch system is probably helpful because then one can see what has changed and try to make it work like it did in stretch.
15:45 <Diziet> Oh the problem is that systemd-shim is broken.
15:46 <Diziet> TBH I don't really see why dbus-user-session needs libpam-systemd
15:46 <bunk> wRAR: notice the (>= 10-4~), see #903295 and #901405
15:46 -zwiebelbot:#debian-devel- Debian#903295: libpam-systemd: Depends: systemd-shim (>= 10-4~) but it is not going to be installed - https://bugs.debian.org/903295
15:46 <wRAR> systemd : Breaks: systemd-shim (< 10-4~)
15:46 <wRAR> yup
15:46 -zwiebelbot:#debian-devel- Debian#901405: systemd-shim: Please add a sysvinit service to create directories on /run at boot - https://bugs.debian.org/901405
15:46 <wRAR> "systemd-shim is broken" is not something surprising of course
15:46 <Diziet> sunweaver: Do you have time to look at this ?
15:46 <Diziet> wRAR: Indeed but I guess it is fixable.
15:47 <Diziet> sunweaver: I think the most obvious fix is to fix the 3 bugs listed here  https://tracker.debian.org/pkg/systemd-shim
15:47 <Diziet> sunweaver: If someone would prepare a fix I would be happy to sponsor it.
15:50 <Diziet> I think a long term solution is probably to replace the automatic session authorisation stuff with something more simple like membership of a suitable unix group.
15:50 <Diziet> sunweaver: AYT?
15:55 <bigon> oO(systemd-shim should be RM from debian)
15:57 <bunk> bigon: It should not, but due to noone (including me) being willing to spend time on maintaining it that's what will happen in practice (it already got removed from buster).
15:57 <bigon> it's broken
15:57 <bigon> if you want to be able to use login1 D-Bus API without systemd, people should go for elogin IMVHO
15:59 <Diziet> bigon: What is elogin ?
15:59 <bigon> gentoo people have extracted logind from systemd source
15:59 <wouter> Diziet: given that it starts with "e", I suspect something from gentoo
15:59 <wouter> well, there
15:59 <ansgar> elogind is systemd-logind with the cgroup manager merged back in.
15:59 <bigon> (same with eudev where they have extracted udev from systemd)
15:59 <ansgar> And some questionable patches...
16:00 <Diziet> bigon: OK, so can we have that in Debian ?
16:00 <Diziet> If so it could be an alternative dependency to systemd-shim
16:00 <bigon> I've created a pkg to give it some test (yeah to insomnia)
16:00 <Diziet> bigon: Great.
16:00 <themill> #905388
16:00 <wRAR> we can also have xdg-menu in Debian, it seems a lot of people want it
16:00 <bigon> but I've absolutely have 0 plans to mantain it
16:00 -zwiebelbot:#debian-devel- Debian#905388: RFP: elogind -- The systemd project's "logind", extracted to a standalone package - https://bugs.debian.org/905388
16:01 <Diziet> bigon: If you manage to get it working I think it is probably a better bet than systemd-shim
16:01 <bigon> well it's in the console
16:01 <Diziet> bigon: By "maintain" do you mean "fix the bugs that Gentoo don't" or "push new updates from Gentoo" ?
16:01 <bigon> gdm craps itself
16:01 <bigon> didn't try with other DM
16:01 <olasd> I think he means being Maintainer/Uploaders in d/control
16:01 <bigon> Diziet: I mean uploading it to debian
16:02 <Diziet> bigon: OIC.  That's a shame.
16:02 <bigon> something I didn't investigate was, is libsystem working with elogind implementation
16:02 <Diziet> I am not a big fan of gdm.  I would try lightdm.
16:04 <Diziet> bigon: If you make any kind of thing that sort of works, do please share it with the RFP bug at least ?
16:05 <bigon> https://paste.debian.net/1043300/ << didn't touch that for months
16:07 <Diziet> bigon: Can you email that to the bug please ?
16:07 <Diziet> You don't have to take responsibility for it :-)
16:07 <Diziet> It's a lot easier, psychologically at least, for someone else to fix a broken thing than for them to start from scratch.
16:08 <petn-randall> Diziet: Depends on if it's being used in production or not ...
16:11 <bigon> 17:07 < Diziet> You don't have to take responsibility for it :-) << I'm not sure I want to either :p
16:20 <smcv> Diziet: re dbus-user-session: the API provided by dbus-user-session is that you have one D-Bus session bus per what I've been calling a user-session (any sequence of overlapping login sessions under the same uid)
16:20 <smcv> Diziet: which is the same as the lifetime of XDG_RUNTIME_DIR with logind, and formerly pam_xdg in ubuntu
16:21 <smcv> Diziet: with the dbus-daemon listening on a predictable filename relative to XDG_RUNTIME_DIR (it's XDG_RUNTIME_DIR/bus)
16:21 <smcv> Diziet: the only concrete implementation of this that exists is that logind creates XDG_RUNTIME_DIR, and systemd --user starts dbus.socket which listens in the right place, and later starts dbus.service when someone connects to the socket
16:22 <smcv> Diziet: so it needs libpam-systemd because that's how you say "I need a working logind" in dependency syntax, and also needs systemd as pid 1 because that's the only thing that will start a systemd --user for you
16:23 <smcv> Diziet: if someone has a less-systemd-heavy implementation of the same app-facing functionality then dbus-user-session could have that too, and weaken or remove the dependency
16:24 <smcv> Diziet: but dbus-x11 (X11 autolaunching) is not an implementation of the dbus-user-session API, because it starts a different number of dbus-daemons (one per graphical login session, even if they overlap)
16:26 <Diziet> What goes wrong if the dbus user session lives on after the user logs out for the last time ?
16:26 <smcv> I don't think either systemd-shim or elogind starts a `systemd --user` per XDG_RUNTIME_DIR, because systemd --user probably depends on systemd-as-pid-1, and in any case the same people who don't want systemd as pid 1 probably also don't want systemd as a per-user service manager
16:27 <Diziet> Right.
16:27 <smcv> what goes wrong: dbus-daemon --session continues to run, so do any D-Bus-activated services that it started, sysadmins of multi-user systems complain loudly
16:28 <smcv> (that isn't the hard part though, if you have the concept of a user-session then you can presumably kill dbus-daemon at the right time)
16:28 <Diziet> That doesn't sound ideal but it doesn't sound RC to me.
16:29 <smcv> any implementation of the XDG_RUNTIME_DIR spec already needs to do cleanup at the transition from 1 to 0 parallel login sessions, so that's a natural time to kill the dbus-daemon
16:29 <Diziet> Well, killing things at the right time is more fiddly than simply starting them on demand.
16:29 <smcv> (the spec says XDG_RUNTIME_DIR is cleaned up at that transition)
16:30 <Diziet> XDG_RUNTIME_DIR is /var/run/uid ?
16:30 <Diziet> err, whatever it's called
16:30 <Diziet>  /var/run/user/uid
16:31 <Diziet> That seems to be possibly needed by cron jobs and things too.
16:31 <smcv> canonically yes
16:31 <smcv> well, the spec just says it's in an environment variable
16:31 <Diziet> "login session" seems rather narrower than that
16:31 <Diziet> It talks about the user being logged in but not logged in users can run processes
16:32 <smcv> but systemd implements it as /run/user/$uid and there's no reason for a parallel implementation to be gratuitously different
16:32 <Diziet> it = the spec, I mean, which I just found
16:32 <smcv> perhaps this is a wider definition of login session than yours
16:32 <smcv> cron starts a logind login session for the duration of the cron job, I think
16:32 <Diziet> Well if I am allowed to define login session then I can say it never terminates :-)
16:32 <bigon> IIRC cron call pam
16:32 <ansgar> cron doesn't start a  logind session.
16:33 <bigon> and pam contains the pam_systemd module
16:33 <bigon> for user crontab I think it does
16:33 <ansgar> common-session does start logind sessions, common-session-noninteractive doesn't.
16:33 <Diziet> ISTM that in most systems leaving /var/run/user/uid lying about is not going to be a problem.
16:33 <ansgar> Is leaving 1000s of processes around a problem? :>
16:33 <Diziet> So cron jobs can't use XDG_RUNTIME_DIR even though they might well need to
16:34 <bigon> ansgar: oh right
16:34 <Diziet> ansgar: Presumably the number of processes, files, etc., is O(number of users that have ever logged in)
16:34 <smcv> I thought they picked up an existing XDG_RUNTIME_DIR if there happened to be an interactive session that had created it, at least
16:34 <Diziet> As I say, in some installations that would be a problem but certainly not all
16:34 <Diziet> smcv: So your cron jobs work when you are logged in but then when you log out they start failing mysteriously ?  win!
16:35 <smcv> quality-of-implementation: in systemd's implementation, each /run/user/$uid is a separate small tmpfs so that users can't DoS each other by filling up /run/user, or the system by filling up /run
16:35 <Diziet> Right.
16:35 <ansgar> GnuPG tries to guess XDG_RUNTIME_DIR even when not set.  That also explodes in interesting ways (multiple gpg-agents locking the same card and only one working...)
16:35 <Diziet> smcv: Don't get me wrong, I'm grateful for all this explanation and I'm not holding you responsible for any things I think may be wrong...
16:36 <smcv> ansgar: yeah gpg's interpretation of XDG stuff is special and unique
16:36 <Diziet> Don't talk to me abut gnupg
16:36 <Diziet> You wouldn't like me when I talk about gnupg
16:36 <ansgar> Diziet: Oh, I don't like GnuPG either :>
16:37 <Diziet> smcv: I'm going to c&p this conversation into an email somewhere (not sure [where yet])
16:37 <ansgar> There is also another feature of systemd-logind that X uses: access to hardware things...
16:38 <smcv> Diziet: I think I've said this in previous conversations about dbus-user-session: if you want to reimplement dbus-user-session in a non-systemd way, the place to start is probably by forking the libpam_xdg that ubuntu used before switching to systemd
16:38 <smcv> that's the only non-systemd implementation of XDG_RUNTIME_DIR that I'm aware of
16:39 <smcv> and a PAM module that hooks into the stack in approximately the same places as pam_systemd is probably the only reasonable implementation
16:39 <Diziet> smcv: That doesn't sound unreasonable
16:39 <smcv> I would strongly recommend using /run/user/$uid like systemd does
16:39 <Diziet> I don't remember hearing this from you before but my memory is not good at these things...
16:39 <smcv> because apps/daemons shouldn't hard-code that path, but they probably do anyway
16:40 <Diziet> smcv: Right, well, /var/run -> /run anyway
16:40 <bigon> 17:32 < ansgar> cron doesn't start a  logind session. << on RHEL7 it actually does
16:40 <bigon> (just checked)
16:41 <ansgar> bigon: It maybe should, especially if one wanted to use KillUserProcesses=
16:42 <bigon> ansgar: adding the call to pam_systemd and not switch from common-session-noninteractive to common-session, then I guess
16:42 <bigon> ?
16:43 <smcv> I feel as though anything that executes user-specified code should probably be a logind login session
16:43 <ansgar> bigon: Maybe. But people will complain (about log entries as systemd --user will then be started for every cron job if not already running)
16:43 <smcv> perhaps -interactive was the wrong distinction to draw
16:43 <bigon> ansgar: yeah..
16:43 <Diziet> smcv: It does seem so, but bear in mind this was all done by xdg who think everything is a desktop
16:43 <smcv> "executes sysadmin-chosen code" (think imapd) vs. "executes user-chosen code" is subtly different
16:44 <ansgar> Yes, and it will execute code from $HOME which one probably doesn't want for service accounts...
16:44 <smcv> Diziet: where we choose to hook in pam_systemd is on us, not systemd or xdg
16:44 <bigon> you have the (vague) notion of entry point PAM service
16:44 <Diziet> smcv: True but the xdg spec does talk about login and logout which is a very funny way to look at a cron job
16:45 <Diziet> A bit Humpty Dumpty, really
16:45 <smcv> is a cron job more like an interactive login session, or an imapd/etc. login?
16:46 <Diziet> smcv: traditionally a cron job was a thing that ran even if you were logged out
16:46 <ansgar> Just s/login/session start/, s/logout/session end/
16:46 <smcv> Debian's PAM stack split is as though it's more like imapd, but in terms of "executes user code" it's more like the interactive session
16:46 <Diziet> Right, with a wide definition of "session"
16:46 <ansgar> (And now argue which "session" concept that is)
16:46 <ansgar> cron jobs already use multiple sessions :>
16:47 <Diziet> smcv: I think your sysadmin- vs user-chosen distinction is helpful although of course there might well be "sysadmin-chosen" things that end up wanting run/user
16:47 <smcv> "arbitrarily extensible" perhaps?
16:48 <smcv> (for the thing that interactive login sessions definitely are, and imapd probably isn't)
16:48 <Diziet> Mmmm.  But some version of the same interface should be available to a daemon which wants /run/user for its own purposes
16:49 <ansgar> smcv: But what about ssh? Interactive logins and service accounts limited to force_command=.... :>
16:49 <smcv> have a PAM stack, put pam_systemd (or your reimplementation) in it, job done
16:49 <smcv> ansgar: I suppose arguably a force_command is more like the noninteractive case yeah
16:50 <ansgar> smcv: Yes, but there is no difference in PAM config.
16:50 <smcv> I think the rule of thumb is probably, if in doubt, use the one that starts a full-fat login session
16:51 <smcv> which is the heavier but more featureful environment
16:53 <ansgar> smcv: And unsafer (as it runs code from $HOME) :>
16:54 <smcv> Diziet: the other relevant consideration for dbus-user-session is that if it grows support for a non-systemd thing that behaves a bit like a service manager, I don't want to be left perpetually responsible for a fallback path that I don't even use
16:55 <smcv> (see also the number of uploads of sysvinit and systemd-shim made by members of pkg-systemd)
16:56 <smcv> particularly if it adds non-trivial code to dbus(-user-session) itself
16:56 <Diziet> FAOD I take your earlier comments about the old libpam_xdg from ubuntu to not raise that concern ?
16:56 <Diziet> I haven't looked at the code for this.
16:57 <smcv> an alternative dependency and some mostly-declarative glue in dbus-user-session, that is used by code elsewhere, would be ok
16:58 <smcv> similar to the way dbus-user-session contains systemd units, but they're really simple, and the systemd service manager/logind/PAM module are external to dbus
16:59 <smcv> pam_xdg is necessary but not sufficient, it creates XDG_RUNTIME_DIR but doesn't start any dbus-daemons
16:59 <Diziet> Right.
17:00 <smcv> one semantic that the systemd implementation has, that might be hard to replicate otherwise, is that as soon as you start executing arbitrary user code, XDG_RUNTIME_DIR/bus is already ready and listening
17:00 <highvoltage> wouter: cool
17:00 <Diziet> I think the dbus daemons are probably needed for a much smaller proportion of things
17:00 <Diziet> They could probably be started by an X11 session hook even
17:00 <smcv> that ... is dbus-x11
17:00 <Diziet> No, I mean, the dbus user session could be started, if there wasn't one already, alongside the dbus-x11 one
17:01 <Diziet> And maybe never stopped
17:01 <smcv> if someone has depended on dbus-user-session, and not default-dbus-session-bus | dbus-x11, then it's because they want specifically dbus-user-session
17:01 <Diziet> Although obv. it has to not outlive /run/user/uid
17:01 <smcv> if you have a user bus then you must not start the per-login-session bus from dbus-x11
17:01 <smcv> that will break everything
17:01 <Diziet> My point being that it doesn't seem likely that command line programs and cron jobs and so on would want it
17:02 -!- yann|work [~yann@LFbn-1-515-227.w86-245.abo.wanadoo.fr] has quit [Read error: No route to host]
17:02 <Diziet> smcv: I think we are talking at cross purposes
17:02 <smcv> part of the point of dbus-user-session is that the X11 session and the ssh session and the getty session have *the same* session bus
17:02 <smcv> (if they overlap)
17:02 <Diziet> What programs that you might run via ssh would depend on the dbus user sessio ?
17:03 <smcv> rygel -> tracker, for example
17:03 <smcv> (conventionally used in GNOME but it's entirely reasonable to use it headlessly)
17:03 <smcv> dconf
17:04 <smcv> gpg-agent, in an alternate universe where it didn't have its own IPC socket and protocol
17:04 <Diziet> So with my proposed implementation, to make that work, the user might have to put some dbus user session thing in their .profile or .bashrc or something
17:05 <Diziet> Or it wouldn't work until they'd logged in with a gui session
17:05 <Diziet> That would be annoying
17:06 <Diziet> It doesn't sound like it would be a crisis.  It could be made to work with the default dotfiles for interactive sessions, at least.
17:06 <bigon> ansgar: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909200
17:06 -zwiebelbot:#debian-devel- Debian#909200: Please call pam_systemd in the PAM service - https://bugs.debian.org/909200
17:07 <Diziet> Anyway, I have to be departing for a train now.  Thanks for all the info.
17:07 <smcv> Diziet: my concern there is that session services should be entitled to assume that, if they depend on dbus-user-session, then the XRD/bus socket is available "sufficiently early"
17:07 <ansgar> bigon: It's not only cron, but other things using common-session-noninteractive too (e.g. at)
17:07 <Diziet> smcv: Sure, I'm not saying this situation wouldn't leave some remaining bugs
17:08 <smcv> which is not necessarily the case if you don't run a dbus-daemon until entering per-user code
17:08 <bigon> ansgar: right
17:08 <ansgar> bigon: So if it should change, pam_systemd should probably be added there.
17:08 <mbiebl_> so far we deliberately excluded pam_systemd from common-session-noninteractive
17:09  * bigon forgot about atd
17:09 <smcv> one thing that needs to happen is that DBUS_SESSION_BUS_ADDRESS needs to be set before entering /etc/X11/Xsession.d/75dbus_dbus-launch (or /etc/X11/Xsession.d/75dbus_dbus-launch needs to learn some other way to know that it must disable itself)
17:09 <mbiebl_> bigon: and I'm not sure if we should change that
17:10 <mbiebl_> i.e. creating a systemd logind session on every cron execution
17:10 <smcv> so that dbus-x11 quietly disables itself in the presence of an implementation of dbus-user-session, to avoid a split-brain situation between the per-uid bus and the per-X11-display bus, both of which think they are "the" session bus
17:10 <bigon> (if you have a user crontab)
17:10 <bigon> other distro seems to do so (if that argument has any value)
17:11 <mbiebl_> do we have an actual use case / someone needing that which would justify that change?
17:12 <smcv> possibly Diziet's implementation of a user bus would have to start really early in /etc/X11/Xsession.d, but later in the login process from .profile, or something like that
17:12 <mbiebl_> I'm sure we'd also have admins who would be unhappy if we constantly created logind session on busy servers
17:15 <bigon> The thing is that (if I understood correctly) not creating the logind session might change the behaviour if you have a session open and XDG_RUNTIME_DIR exists (and dbus can be started) and the case where it's not
17:17 <bigon> and it's only about user cron jobs
17:17 <bigon> not the system one
17:17 <bigon> so by default this shouldn't happen
17:19 <ansgar> mbiebl_: Strange things can happen if the cron script uses anything that wants to use $XDG_RUNTIME_DIR.
17:21 <mbiebl_> do we have cron scripts which rely on $XDG_RUNTIME_DIR ?
17:21 <ansgar> On the other hand it makes "can write to service account's $HOME" imply "can run code as service"
17:22 <ansgar> mbiebl_: GnuPG is really horrible when started with /run/user/<uid> not existing and later again with the directory around.
17:22 <bigon> 18:21 < mbiebl_> do we have cron scripts which rely on $XDG_RUNTIME_DIR ? < probably not, but again it's for the user cron jobs
17:22 <bigon> not the system one
17:22 <ansgar> (Regardless of XDG_RUNTIME_DIR set or not for the GnuPG process; it will guess the /run/user/<uid> path)
17:23 <ansgar> If only the user database would allow flagging users as service accounts :>
17:23 <mbiebl_> bigon: /etc/pam.d/cron is only used for user crontabs?
17:23 <bigon> yes
17:24 <bigon> let me check
17:26 <ansgar> The source looks like it always opens a pam session.
17:26 <mbiebl_> right
17:26 <mbiebl_> I've just added a cron job to /etc/crontab which runs every minute
17:26 <bigon> mmmh
17:26 <bigon> right....
17:26 <bigon> it indeed does
17:26 <mbiebl_> no I get a systemd --user instance started and stopped continuously
17:26 <mbiebl_> flodding the journal
17:27 <mbiebl_> I don't think that's good
17:27 <mbiebl_> s/no/now/
17:34 <bigon> I was completely wrong here
17:38 <bigon> https://github.com/cronie-crond/cronie/commit/e9943853bc3f09a31c38850b8a0100599981a36b
17:38  * bigon says something about switching to cronie
17:43 <mbiebl_> bigon: yeah, that would make more sense if it was handled like in cronie
17:46 <ansgar> bigon: The proper distinction is probably service account / real user.  As that doesn't exist, cron should probably not use PAM (and logind sessions) for system crontab (/etc/crontab), but for all user crontabs (including root's)
17:46 <bigon> ansgar: exactly
17:46 <ansgar> root / non-root seems less good.
17:47 <Myon> cron not using sessions would remove 90% of syslog spam
17:48 <mbiebl_> Myon: with pam_systemd enabled, you'd get a lot more spam (and overhead)
17:49 <mbiebl_> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909200#12
17:49 -zwiebelbot:#debian-devel- Debian#909200: Please call pam_systemd in the PAM service - https://bugs.debian.org/909200
17:49 <Myon> mbiebl_: fwiw this weird systemd/logind issue I was reporting a few months back was probably due to stale sessions from pam_systemd interacting badly with jobs started from jenkins ssh remote nodes
17:50 <ansgar> But one can approximate that by using .timer units instead of /etc/crontab ;-)
17:50 <Myon> I uninstalled pam_systemd and everything seems sane now
17:50 <bigon> ansgar: is a PAM session opened in that case?
17:51 <mbiebl_> for an SSH session, sure
17:51 <bigon> (I meant the .timer case :)
17:51 <ansgar> bigon: No, like for all services.  One can start a PAM session if wanted (PAMName= in the .service)
17:51 <bigon> k
17:51 <mbiebl_> if you have high frequency/automated SSH logins
17:51 <ansgar> I guess that could then start a logind session.
17:52 <mbiebl_> you might consider using non-interactive in /etc/pam.d/sssh
17:52 <mbiebl_> common-session-noninteractive
17:53 <mbiebl_> Myon: I vaguely remember an upstream bug report, where a user reported long SSH login times
17:53 <Myon> I'm not sure what the problem is/was, the ssh connection is persistent
17:54 <mbiebl_> apparently logind sessions did pile up and weren't correctly removed
17:54 <mbiebl_> if you have one persistent connection, then your problem might be different though
17:54 <Myon> it was leaking dead "cscope" things in "systemctl" output like hell
17:55 <Myon> and eventually the system went dead because it ran out of IDs (pids, something)
17:55 <Myon> (of course I should have noticed that by monitoring)
17:55 <Myon> this setup does a lot of sudo calls from that ssh session, maybe that's the problem
17:57 <mbiebl_> Myon: if you can (reliably) reproduce the problem, it would be worth investigating the problem properly
17:58 <Myon> yeah, I'll file a bug if I have something concrete. The last report was really just because I was desparate with the breakage
17:59 <mbiebl_> thanks