既然有人在的话我问个碰到的问题,倒不是什么烦人的问题。
不知道是systemd-logind 管理会话的什么毛病
我
```
systemctl get-default
multi-user.target
```
然后用的 tty 直接 登录,登录后直接输入 sway进ui。
这时候loginctl 当然是显示
```
loginctl
SESSION UID USER SEAT TTY
1 1000 atmouse seat0 tty1
1 sessions listed.
```
这时候我退出 sway,然后 退出bash,然后很快速的又在同个tty console登录进去。
这时候
```
loginctl
SESSION UID USER SEAT TTY
1 1000 atmouse seat0 tty1
4 1000 atmouse seat1 tty1
2 sessions listed.
```
大概是这样,两个seat session是不是一样的我忘了。
session 1 是上次退出没有注销的,我得用 loginctl kill-session 1才行, terminate-session 还没用。。
补充,这种情况下,第二次登陆的login session 会同时出现 gnome-keyring-daemon 一些功能失灵,pam.d 启动的 gnome-keyring-daemon 提示什么 /run/user/1000/keyring not found,一个用户只出现一个login session的时候不会。
最近编辑记录 atmouse (2020-07-20 21:06:21)
离线
你的 sway 以及 sway 里的东西都退出了吗?
systemctl status 可以看 cgroup 树,看看你的会话里还有哪些进程还活着。
这也是不建议从 tty 自行启动图形界面的原因:会话会乱乱的。
在线
目前的情况变成了。
loginctl 只显示一个了,不知道是不是我昨天升级这几个app就给修复了
```
[2020-07-20T20:42:33+0800] [ALPM] upgraded acpica (20200528-1 -> 20200717-1)
[2020-07-20T20:42:33+0800] [ALPM] upgraded python-botocore (1.17.20-1 -> 1.17.23-1)
[2020-07-20T20:42:33+0800] [ALPM] upgraded aws-cli (1.18.97-1 -> 1.18.100-1)
[2020-07-20T20:42:33+0800] [ALPM] upgraded jsoncpp (1.9.2-1 -> 1.9.3-1)
[2020-07-20T20:42:34+0800] [ALPM] upgraded cmake (3.18.0-1 -> 3.18.0-2)
[2020-07-20T20:42:34+0800] [ALPM] upgraded code (1.47.1-1 -> 1.47.2-2)
[2020-07-20T20:42:34+0800] [ALPM] upgraded libjcat (0.1.2-1 -> 0.1.3-1)
[2020-07-20T20:42:34+0800] [ALPM] upgraded fwupd (1.4.4-1 -> 1.4.4-2)
[2020-07-20T20:42:34+0800] [ALPM] upgraded imagemagick (7.0.10.23-1 -> 7.0.10.24-1)
[2020-07-20T20:42:34+0800] [ALPM] upgraded intel-gmmlib (20.1.1-1 -> 20.2.2-1)
[2020-07-20T20:42:34+0800] [ALPM] upgraded intel-media-driver (20.1.1-1 -> 20.2.0-1)
[2020-07-20T20:42:34+0800] [ALPM] upgraded libva-utils (2.7.1-1 -> 2.8.0-1)
[2020-07-20T20:42:34+0800] [ALPM] upgraded mkinitcpio (27-3 -> 28-1)
[2020-07-20T20:42:34+0800] [ALPM] upgraded openssh (8.3p1-2 -> 8.3p1-3)
[2020-07-20T20:42:34+0800] [ALPM] upgraded python-boto3 (1.14.20-1 -> 1.14.23-1)
[2020-07-20T20:42:34+0800] [ALPM] upgraded python-pymysql (0.9.3-3 -> 0.10.0-1)
[2020-07-20T20:42:34+0800] [ALPM] upgraded python2-ordered-set (3.1.1-2 -> 3.1.1-3)
[2020-07-20T20:42:34+0800] [ALPM] upgraded wlroots (0.10.1-1 -> 0.11.0-1)
[2020-07-20T20:42:34+0800] [ALPM] upgraded sway (1:1.4-9 -> 1:1.5-1)
[2020-07-20T20:42:34+0800] [ALPM] upgraded waybar (0.9.2-2 -> 0.9.2-3)
[2020-07-20T20:42:34+0800] [ALPM] upgraded xorg-xev (1.2.3-2 -> 1.2.4-1)
```
但是 pam.d 启动的 gnome-keyring-daemon 提示什么 /run/user/1000/keyring not found, 这个还是有。
现象为: 重新登录刚登陆进去执行sway, 提示上面错误sway里面 keyring 不能正常使用, 退出sway然后再执行sway, 错误就消失了。。。 keyring 也可以正常使用
gnome keyring 没错就是pam.d 启动的
```
cat /etc/pam.d/login
#%PAM-1.0
auth required pam_securetty.so
auth requisite pam_nologin.so
auth include system-local-login
auth optional pam_gnome_keyring.so
account include system-local-login
session include system-local-login
session optional pam_gnome_keyring.so auto_start
```
至于为什么用 tty 启动sway,这个是sway建议的
大致知道了,gnome-keyring 没有在 tty 登录的时候启动。而且还不能自动使用 登录密码来解锁keyring
最近编辑记录 atmouse (2020-07-21 16:22:03)
离线
不对啊,我看这边说会自动加载并解锁的才对
https://wiki.archlinux.org/index.php/GN … sole_login
目前我排查,添加到pam.d 自动启动gnome-keyring的时候。
如果重新登录太快, gnome-keyring-daemon 会启动失败,
如果退出,等稍微30秒再登陆, 登录进去 gnome-keyring-daemon 是会自动启动成功的。
最近编辑记录 atmouse (2020-07-21 17:11:41)
离线
```
Jul 21 17:18:22 orbment login[4360]: pam_unix(login:session): session closed for user atmouse
Jul 21 17:18:22 orbment login[4360]: pam_tty_audit(login:session): restored status to 0
Jul 21 17:18:26 orbment login[5543]: gkr-pam: unable to locate daemon control file
Jul 21 17:18:26 orbment login[5543]: gkr-pam: stashed password to try later in open session
Jul 21 17:18:26 orbment login[5543]: pam_unix(login:session): session opened for user atmouse by LOGIN(uid=0)
Jul 21 17:18:26 orbment login[5543]: pam_tty_audit(login:session): changed status from 0 to 1
Jul 21 17:18:26 orbment login[5548]: couldn't read data from gnome-keyring-daemon: Connection reset by peer
Jul 21 17:18:26 orbment login[5543]: gkr-pam: couldn't unlock the login keyring.
Jul 21 17:18:26 orbment login[5543]: LOGIN ON tty1 BY atmouse
```
17:18:22 是登出
17:18:26 是登陆,看起来出问题了
离线
离线
通过debug破案了。 上个tty1退出的时候,gnome-keyring-daemon 大概会延迟4秒 退出并删除 daemon监听的socket。
(原来tty推出的时候所有未退出的进程还会在啊?也不会强制退出,人微软windows session退出逻辑是,绝对hold住session的进程都会关掉)
如果我在这4秒内 tty1重新登录的时候,pam里面的 pam_gnome_keyring 里面逻辑lookup daemon可以成功,但下一瞬间 ,之前的daemon退出并删除socket了。
导致 pam_gnome_keyring 不再给这次session启动daemon。于是 keyring不能用。
离线
(原来tty推出的时候所有未退出的进程还会在啊?也不会强制退出,人微软windows session退出逻辑是,绝对hold住session的进程都会关掉)
我记得之前默认过 KillUserProcesses=yes,然后一群 screen / tmux / nohup / ... 用户不开心,现在默认 KillUserProcesses=no 了。
在线
哦原来,那我自己改成yes
离线