내가 실행 중인 명령이 SSH 세션 내에 있는지 확인하려고 합니다. 일반적으로 $SSH_CONNECTION이는 프로세스 트리를 검사하거나 살펴보고 를 보면 잘 작동합니다 sshd.
그러나 screen세션을 로컬로 시작한 다음 SSH를 통해 다시 연결하면 이 중 아무 것도 작동하지 않습니다.
세션이 현재 연결된 쉘을 확인하기 위해 다시 연결된 화면 세션에 어떤 방법이 있습니까?
프로세스 트리는 다음과 같습니다. shell(X) --> screen(Y) --> systemd(1)로컬 터미널을 종료할 때 screen 세션의 부모가 다시 지정될 수 있으므로 이는 의미가 있습니다.
screen -ls다른 것은 없고 (Attached)PID만 있으며 Y현재 연결된 위치에 유용한 PID는 없습니다.
연결된 프로세스 트리에는 shell(A)하위 프로세스가 포함되어 있지만 screen(B)PID Y와 B. 유닉스 소켓의 다른 쪽 끝을 사용하여 화면을 찾으려고 시도했지만 비어 있었습니다. (심지어 로 확인됨 root).
이게 그냥 불가능한 걸까요?
답변1
많은 실험 끝에 얻은 최종 결과는 다음과 같습니다.
쉘이 실행 중인 화면을 찾으십시오. 화면 프로세스를 찾을 때까지 pstree를 계속 탐색합니다.
screen_pid=$(pstree -psUA $$ | egrep -o 'screen\([0-9]+\)' | tail -1 | egrep -o '[0-9]+')이 프로세스에 대해 열려 있는 모든 파일을 봅니다. 목록에서 유일한 /dev/pts/* 파일을 찾으십시오.
screen_pts=$(lsof -p $screen_pid | grep /dev/pts | awk '{print $NF}')의사 터미널을 제어하는 화면 프로세스를 찾습니다.
ps -o pid=,tty= -C screen | grep ${screen_pts/\/dev\/} | awk '{print $1}'거기에서 상위 프로세스는 shell/ssh/화면을 시작하는 모든 것이 됩니다.지금껍질에 붙어 있습니다.
여기에는 확실히 몇 가지 이상한 "내 컴퓨터(tm)에서 작동"하는 가정이 있지만 이것이 일반적인 생각입니다.
신뢰성이 필요한 경우 statwith를 사용하면 st_rdev해킹된 /dev/pts/5 -> pts/5 대체가 제거됩니다. 유사한 것을 사용 major(st_rdev)하여 의사 터미널을 나타내는 == 일부 값을 사용하여 열려 있는 파일 목록을 필터링할 수 있습니다 .