弁財天

ゴフマン「専門家を信じるのではなく、自分自身で考えて判断せよ」

systemd-logind disappeared (stopped/restarted?) update3

2016年6月1日DBサーバーでBIOS更新テロ。systemdにBIOSバージョンをモニターしてinitramfsを再作成する実装がある。
なんで1年のインターバル?
2017年6月4日
snmpd[3101]: *** Error in `/usr/sbin/snmpd': malloc(): smallbin double linked list corrupted: 0x00007f5546167d60 ***
2017年6月8日トレンドマイクロのパターンファイル更新用途でF/Wに裏口があることが判明。
2017年8月12日わが家サーバ#1がハングアップする原因がsystemd-logindが原因だと判明する。
2017年9月25日DBサーバ#1の起動失敗。systemd/ohasd.serviceしか動いていなかった。

[206195.116] (EE)
Fatal server error:
[206195.117] (EE) systemd-logind disappeared (stopped/restarted?)
[206195.117] (EE)
[206195.118] (EE)
Please consult the Fedora Project support
         at http://wiki.x.org
 for help.
[206195.118] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[206195.118] (EE)
[206195.121] (II) AIGLX: Suspending AIGLX clients for VT switch
[206195.554] (EE) Server terminated with error (1). Closing log file.

/home/hoge/.local/share/xorg/Xorg.0.log

[ 79046.402] (EE) 
Fatal server error: 
[ 79046.407] (EE) systemd-logind disappeared (stopped/restarted?) 
[ 79046.407] (EE) 
[ 79046.407] (EE) 
Please consult the Fedora Project support 
     at http://wiki.x.org
 for help. 
[ 79046.407] (EE) Please also check the log file at "/home/hoge/.local/share/xorg/Xorg.0.log" for additional information. 
[ 79046.407] (EE) 
[ 79046.408] (II) AIGLX: Suspending AIGLX clients for VT switch
[ 79071.446] (EE) systemd-logind: ReleaseControl failed: Failed to activate service 'org.freedesktop.login1': timed out
[ 79071.449] (EE) Server terminated with error (1). Closing log file.

wiki.archlinuxjp.org→ systemd/ユーザー
この辺の連携がバグってるのか?w

github.com→ Systemd user units for my own session.
なんだこの設定は?w

qiita.com→ Linux(systemd)を入れたノートPCを、閉じてもサスペンドさせないようにする
/etc/systemd/login.confに
HandleLidSwitch=ignore
を追加?
beautifulajax.dip.jp→ CentOS7 でノートPCの自動サスペンドをオフにする
HandlePowerKey=ignore
HandleLidSwitch=ignore

ちょっと現象とは違いますな。

wiki.archlinuxjp.org→ systemd/ユーザー
要するにsystemd-logindとxorgを切り離せばいいのだけど、ワカワカメに混乱した設定になってる。

bbs.archlinux.org→ systemctl mask systemd-logind.service
systemctl mask systemd-logind.service
あー、これだわ。systemd-logindが動いてない状態だったんだわ。

再発したときに裏からsystemctl restart systemd-logindを実行するとハングアップしたコンソールが再開することを確認w

bbs.archlinux.org→ [SOLVED] Systemd/Logind - how to start X on other VT ?
bugzilla.redhat.com→ Bug 820675 - startx does not work with systemd-logind
bbs.archlinux.org→ [SOLVED] systemd-logind.service failed

jasonwryan 2015-01-11 00:53:10
Re: [SOLVED] systemd-logind.service failed
The Xorg log looks OK.
Try using this in your profile:
[[ -z $DISPLAY && $XDG_VTNR -eq 1 ]] && exec startx -- vt1 -keeptty
Also, please paste your .xinitrc.
startx -- vt1 -keeptty

man xorg

-keeptty
Prevent the server from detaching its initial controlling terminal. If you want to use systemd-logind integration you must specify this option. Not all platforms support (or can use) this option.
If you want to use systemd-logind integration you must specify this option.
もしsystemd-logindと統合したいのならこのオプションは必須。

ask.fedoraproject.org→ F21: can I have multiple X logins on the console?

Yeah, what you're talking about is a multiseat configuration, and it's awesome. Systemd makes this possible in Fedora 21. I outline the general procedure on my blog and include a link to a detailed instruction set from Fedora 17 which is still applicable. Said general procedure is as follows:

1) Identify the seats currently defined for your system (probably just seat0).

loginctl list-seats

2) List the devices currently attached to the seats (simple if it’s just seat0)

loginctl seat-status seat0

3) Identify the devices you would like to repurpose for the new seat (seat1, in this example).

loginctl seat-status

4) Attach the devices to seat1.

loginctl attach seat0 /sys/devices/device_path_here [attach as many as are necessary for your purposes]

5) Observe success and rejoice.

The general prerequisites are sufficient hardware - you'll need two graphics adapters so that one can be assigned to each seat, and obviously you'll need two monitors, keyboards, and mice at a minimum. You can basically assign any device connected to your system to either seat, however, so you can even provide independent sound cards or other PCI/USB devices for each seat.

crond[23386]: pam_systemd(crond:session): Failed to create session: Message recipient disconnected from message bu s without replying
bugs.debian.org→ Debian Bug report logs - #770135 systemd: ssh logins considerably delayed (until PAM timeout) when systemd is upgraded but the system not rebooted
Hi,
I recently ran into the same problem, and I just tried Michael Biebl's suggestions.
'systemctl restart systemd-journald.service': did not help.
'systemctl restart systemd-logind.service': fixed the problem.
Thanks.
Kind regards, Aljoscha
'systemctl restart systemd-logind.service': fixed the problem.

ありえねー。Xが落ちるのも、sudoが遅くなるのも、crondが動かなくなるのも systemd-logind.service なのかよ。

docs.oracle.com→ D-Bus System Daemon Has a Small File Descriptor Limit for Sun Ray or XDMCP Server Use (15812274)

Modify line 40 in the /lib/svc/method/svc-dbus file from:
/usr/lib/dbus-daemon --system
to:
ulimit -S -n 8192 ; /usr/lib/dbus-daemon --system

redhat.com→ dbus-daemon リソース制限を増やす
redhat.com→ How to increase "dbus-daemon" resource limits ?

cvedetails.com→ D-bus Project : Security Vulnerabilities

bbs.archlinux.org→ [SOLVED] systemd switchover - httpd.service always fails

[Service]
略
PrivateTmp=true
LimitNOFILE=infinity

fedoraproject.org→ Features/ServicesPrivateTmp

この障害は攻撃とは呼べないかも。
大量のWebのアクセスに連動させてsudoみたいな監査ログを大量に発生させる実装をやってしまうと systemd-logindの負荷が設計の意図以上にかかりリソースを使い尽くしてしまうという現象みたいだ。

なんつか昔問題なくできたこともsystemdのような新機能のダサい実装が負荷に耐えられなくなり、それが原因でシステム全体が停止してしまうという問題w

その後、systemdが111番ポートでLISTENしてて攻略ポイントになってることが判明。
rpcbindの111番ポートのsystemd脆弱性


毎日停止起動に成功していた11gR2 RACがある日だけOHASだけが起動して、それ以外のCRS以下が動いてなかった。おもしろいことに翌日からの停止起動では再び何も起きないw。

OHASとはRHEL7ではsystemd下で動作してるohasd.serviceのことで、それ以下が起動してなかったのだから、このsystemdとohasd.serviceをいたずらされたのだろうw。

BIOSをオンライン状態で更新。systemdがBIOS更新をトリガーに行なうinitramfsの再作成中にkernelをクラッシュさせ、結果的にinitramfsを破損、データベースサーバをブートしない状態にしたのもsystemdだったなw。すでに3回(3種類)の攻撃に遭遇している。

わが家のサーバ障害はともかく、BIOS更新時のinitramfs破損と、11gR2 RAC#1ノードの起動失敗は、ベンダーがサポートする本番環境のデータベース・サーバで起きた話だ。

そして、もっとおもしろい話もある。本番環境での障害なので、BIOS更新テロでも、11gR2 RAC#1ノードの起動失敗の障害でもベンダーのサポートが入っている。BIOS更新テロのときはoracleのpublic yumからrpmを導入したのが問題だなどといい、11gR2 RAC#1ノードの起動失敗の障害では停止手順が違うなどと筋違いで必死なスピン回答をはじめている。両方とも障害原因は明確になってないw。もはやこの状況証拠だけでも犯人はほぼ特定されているw。

投稿されたコメント:

コメント
コメントは無効になっています。