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 [~y...@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