On Thu 28 Jul 2022 at 10:35:07 (-0400), Greg Wooledge wrote: > On Thu, Jul 28, 2022 at 10:34:50AM -0300, Chris Mitchell wrote: > > From the output of systemd-cgls I see that the rogue ssh-agent process > > is part of the .scope CGroup corresponding to my X login session. > > > > # systemctl status session-8.scope > > ● session-8.scope - Session 8 of User chris > > Loaded: loaded (/run/systemd/transient/session-8.scope; transient) > > Transient: yes > > Active: active (running) since Thu 2022-07-28 08:59:48 ADT; 25min > > ago Tasks: 254 > > Memory: 957.6M > > CPU: 2min 5.903s > > CGroup: /user.slice/user-1000.slice/session-8.scope > > ├─ 7588 lightdm --session-child 14 23 > > ├─ 7625 xfce4-session > > ├─ 7687 /usr/bin/ssh-agent -s > > etc. > > Looks like it's coming from login stuff, somehow. > > Curious, I looked at my own session. > > unicorn:~$ ps -ef | grep ssh-agent > greg 956 912 0 Jul09 ? 00:00:04 /usr/bin/ssh-agent > /home/greg/.xsession > greg 968 1 0 Jul09 ? 00:00:00 ssh-agent -s > greg 1510760 984 0 10:24 pts/2 00:00:00 grep ssh-agent > > unicorn:~$ systemctl status session-1.scope > ● session-1.scope - Session 1 of user greg > Loaded: loaded (/run/systemd/transient/session-1.scope; transient) > Transient: yes > Active: active (running) since Sat 2022-07-09 08:23:23 EDT; 2 weeks 5 > days> > Tasks: 1176 > Memory: 9.7G > CPU: 1w 5d 8h 51min 25.285s > CGroup: /user.slice/user-1000.slice/session-1.scope > ├─ 697 /bin/login -p -- > ├─ 856 -bash > ├─ 871 /bin/sh /usr/bin/startx > ├─ 893 xinit /etc/X11/xinit/xinitrc -- > /etc/X11/xinit/xserverrc> > ├─ 894 /usr/lib/xorg/Xorg -nolisten tcp :0 vt1 -keeptty -auth > /> > ├─ 912 /bin/bash /home/greg/.xsession > ├─ 956 /usr/bin/ssh-agent /home/greg/.xsession > ├─ 968 ssh-agent -s > ├─ 971 rxvt -font 7x13 -geometry 80x24+0+116 > [...]
I did much the same … > My .xsession file contains only this line concerning ssh-agent: > > hash ssh-agent 2>/dev/null && eval "$(ssh-agent -s)" … but I don't do that. So my ssh-agent is still "properly" parented, rather than an adoptee of 1. > So... in my case... "ssh-agent -s" (PID 968) is the one I requested. What > is the *other* one, PID 956? It's a child of 912 (shown earlier), so > let's trace that back: > > unicorn:~$ ps -fp 912 > UID PID PPID C STIME TTY TIME CMD > greg 912 893 0 Jul09 tty1 00:00:00 /bin/bash > /home/greg/.xsessi > unicorn:~$ ps -fp 893 > UID PID PPID C STIME TTY TIME CMD > greg 893 871 0 Jul09 tty1 00:00:00 xinit > /etc/X11/xinit/xinitrc > > /etc/X11/xinit/xinitrc is a shell script that contains only one non-comment > line: > > . /etc/X11/Xsession > > Looking for related stuff: > > unicorn:~$ grep -r ssh-agent /etc/X11/Xsession* > /etc/X11/Xsession.d/90x11-common_ssh-agent:# $Id: 90x11-common_ssh-agent 305 > 2005-07-03 18:51:43Z dnusinow $ > /etc/X11/Xsession.d/90x11-common_ssh-agent:SSHAGENT=/usr/bin/ssh-agent > /etc/X11/Xsession.d/90x11-common_ssh-agent:if has_option use-ssh-agent; then > /etc/X11/Xsession.d/90x11-common_ssh-agent: if [ -f /usr/bin/ssh-add1 ] && > cmp -s $SSHAGENT /usr/bin/ssh-agent2; then > /etc/X11/Xsession.d/90x11-common_ssh-agent: # use ssh-agent2's > ssh-agent1 compatibility mode > /etc/X11/Xsession.options:use-ssh-agent > > So, I suppose Debian is starting this ssh-agent via its Xsession even > though I have my own .xsession file which is starting my own instance of > ssh-agent. > > I guess you've already disabled that one...? > > Anyway, your login is completely different from mine (you're using lightdm, > while I'm using a console login and startx), so you'll have to pursue your > own investigation from here. > > Given the order of the processes shown in your session-8, it looks like > it might be an XFCE thing. Maybe start there? I can't help you with > that, though. I assume that some process above ssh-agent has died, unintentionally or otherwise. > > Any ideas where I might look next? Anyone know if it's possible to ask > > systemd what process "externally created" a process in a .scope? I'm not sure what you mean by this, unless it's the (wrong) idea that systemd "injected" the ssh-agent into your scope, evidenced by its parent being PID 1. My scope is clearly generated merely by logging in. Everything in it is mine, all mine … … Control group /: -.slice ├─user.slice │ └─user-1000.slice │ ├─user@1000.service │ │ ├─app.slice │ │ │ ├─at-spi-dbus-bus.service │ │ │ │ ├─5409 /usr/libexec/at-spi-bus-launcher │ │ │ │ ├─5414 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2… │ │ │ │ └─5419 /usr/libexec/at-spi2-registryd --use-gnome-session │ │ │ ├─pipewire.service │ │ │ │ ├─1103 /usr/bin/pipewire │ │ │ │ └─1108 /usr/bin/pipewire-media-session │ │ │ └─dbus.service │ │ │ ├─1106 /usr/bin/dbus-daemon --session --address=systemd: --nofork --n… │ │ │ └─5466 /usr/libexec/dconf-service │ │ └─init.scope │ │ ├─1088 /lib/systemd/systemd --user │ │ └─1089 (sd-pam) │ └─session-4.scope │ ├─1082 /bin/login -p -- │ ├─1105 -bash │ ├─2107 /bin/sh /usr/bin/X11/startx │ ├─2129 xinit /etc/X11/xinit/xinitrc -- /etc/X11/xinit/xserverrc :0 vt1 -k… │ ├─2130 /usr/lib/xorg/Xorg -nolisten tcp :0 vt1 -keeptty -auth /tmp/server… │ ├─2174 /bin/bash /home/auser/.xsession │ ├─2218 /usr/bin/ssh-agent /bin/bash /home/auser/.xsession │ ├─2228 /usr/bin/fvwm │ ├─2237 /usr/lib/fvwm/2.6.8/FvwmPager 7 4 none 0 8 │ ├─2238 /usr/lib/fvwm/2.6.8/FvwmButtons 9 4 none 0 8 MyButtons │ ├─2239 /usr/lib/fvwm/2.6.8/FvwmEvent 11 4 none 0 8 MyEvent │ ├─2250 xterm -geometry 110x38+0+0 -xrm *Page: 4 3 │ ├─2252 bash │ ├─2266 xterm -geometry 110x38+0+0 -xrm *Page: 3 3 │ ├─2293 bash [ … ] │ ├─5671 systemd-cgls --no-pager │ └─5672 less ├─init.scope │ └─1 /sbin/init └─system.slice ├─xfstt.service │ └─608 /usr/bin/xfstt --notcp [ … ] and the rest of the system services. All the parent/child relationships are as you would expect, except that each xterm was started by a deceased instance of xtoolwait (for correct placement) and so are all adoptees of PID 1. > > Also, in the absence of more promising leads, I followed Tomas' advice > > and inserted "echo" statements at every decision point in > > 90x11-common_ssh-agent, which confirmed that the initial "if > > has_option" check is returning False and none of the code in that if > > block is being run. I'm convinced that Xsession is not the culprit. I'd like to see the contents of $STARTUP before it's exec'd by /etc/X11/Xsession.d/99x11-common_start, because that's what actually does the business. Cheers, David.
