절전 모드로 내려가는 우분투 머신
이상하군요, 가상 머신의 리눅스가 지겨워 ^^ 기존 윈도우 머신 하나를 밀어 새롭게 우분투 20.04를 설치했는데요, 컴퓨터 설정을 모두 완료한 후 모니터/키보드를 떼 서버실에 놓고, 이후 잠시 사용하지 않다가 코로나로 장기 재택이 되는 요즘 집에서 접속을 시도했는데, 안 되는군요. ^^;
다른 직원 없는 토요일에 출근해 컴퓨터를 살펴보니, 파워 LED 쪽이 약간의 희미하게 불빛이 있는데 뭔가 잘못됐나 싶어 다시 컴퓨터를 서버실에서 빼 모니터/키보드를 연결 후 부팅했더니 잘 동작합니다. ^^; 음... 일단 그동안 못했던 "apt update/upgrade"를 한 후 서버실에 내려놓고 ping이 되는 것을 확인한 다음 집으로 왔는데요... 다시 접속이 안 됩니다. ^^;
다행인 것은 제가 그 컴퓨터에 혹시 몰라 키보드를 연결해 두었다는 사실입니다. ^^
그래서, 다음 날 출근한 동료에게 부탁해 서버 실의 그 컴퓨터에 연결되어 있는 키보드를 그냥 무작위로 눌러 달라고 했습니다. 오호~~~ 그랬더니 정말 ping이 살아났습니다. 결국 전형적인 절전 모드 현상이었던 것입니다.
그건 그렇고, 이대로 있으면 다시 절전 모드로 내려갈 것이 뻔하므로 관련해서 이를 막을 수 있는 방법에 대해 검색을 해봤지만 딱히 답이 없습니다. (심지어, 회사의 리눅스 guy는 리눅스에 절전 모드라는 것이 있었냐며 오히려 놀래는 눈치입니다.)
그나마, 이런 내용이 있긴 한데,
[Linux] 절전(대기) 모드 해제
; https://luyin.tistory.com/423
$ cat /etc/systemd/logind.conf
...[생략]...
HandleLidSwitch=ignore
...[생략]...
말 그대로 노트북 덮개의 경우라 제 컴퓨터와는 상관이 없었습니다. 혹시 전원 관리 옵션일까 싶어 검색된 xset 명령을 봤지만,
$ xset
usage: xset [-display host:dpy] option ...
To turn bell off:
-b b off b 0
To set bell volume, pitch and duration:
b [vol [pitch [dur]]] b on
To disable bug compatibility mode:
-bc
To enable bug compatibility mode:
bc
To turn keyclick off:
-c c off c 0
To set keyclick volume:
c [0-100] c on
To control Energy Star (DPMS) features:
-dpms Energy Star features off
+dpms Energy Star features on
dpms [standby [suspend [off]]]
force standby
force suspend
force off
force on
(also implicitly enables DPMS features)
a timeout value of zero disables the mode
To set the font path:
fp= path[,path...]
To restore the default font path:
fp default
To have the server reread font databases:
fp rehash
To remove elements from font path:
-fp path[,path...] fp- path[,path...]
To prepend or append elements to font path:
+fp path[,path...] fp+ path[,path...]
To set LED states off or on:
-led [1-32] led off
led [1-32] led on
-led named 'name' led off
led named 'name' led on
To set mouse acceleration and threshold:
m [acc_mult[/acc_div] [thr]] m default
To set pixel colors:
p pixel_value color_name
To turn auto-repeat off or on:
-r [keycode] r off
r [keycode] r on
r rate [delay [rate]]
For screen-saver control:
s [timeout [cycle]] s default s on
s blank s noblank s off
s expose s noexpose
s activate s reset
For status information: q
To print version: -version
xset의 "x"는 X-Window 설정만을 의미하는 듯 실제로 명령을 수행하면 오류만 발생합니다.
$ sudo xset -dpms
xset: unable to open display ""
이렇게 시간을 보낸 사이, SSH 연결 상태 중이었음에도 불구하고 해당 컴퓨터는 다시 절전 모드로 내려가 버렸습니다. ^^;
이것 참,,, 매번 회사 동료에게 서버 실로 내려가 달라고 부탁할 수도 없고, ... 곰곰 생각하다 묘안이 떠올랐습니다. 일단, 또 다른 동료에게 부탁해 이번에는 작은 물체 하나를 연결된 그 키보드 위에 버튼이 눌리도록 올려만 달라고 했습니다. ^^
오호~~~ 그랬더니, 다시 살아났습니다. 그리고 어쩌면 눌려져 있는 키보드로 인해 다시 절전 모드로 내려가지는 않을 것입니다.
하지만, 불현듯 키보드의 입력 버퍼가 차면 이것도 혹시 입력 없음으로 처리하지 않을까... 하는 불안감이 엄습했습니다. 100% 보장을 할 수 없기에 일단 좀 더 검색을 해봤고, 그러다 rtcwake 명령어가 눈에 들어왔습니다.
rtcwake(8) — Linux manual page
; https://man7.org/linux/man-pages/man8/rtcwake.8.html
자꾸 시스템이 절전 모드로 빠지는 거니까, 깨우기 위해 -s 값을 300(5분)으로 주는 것을
crontab과 연동해 설정하는 것으로 결과를 지켜봤습니다.
$ crontab -e
$ crontab -l
5 * * * * rtcwake -m no -s 5
그래서 일단은 한참 동안 시스템이 절전 모드로 내려가지 않고 있는데요, 저 둘 중의 하나가 먹힌 것 같은데 아무래도 승자는 키보드인 것 같습니다. 왜냐하면, syslog에 남은 CRON 실행 로그를 보니,
$ tail -f /var/log/syslog | grep "(CRON)"
...[생략]...
May 3 17:05:01 testnix CRON[43321]: (CRON) info (No MTA installed, discarding output)
May 3 18:05:01 testnix CRON[49913]: (CRON) info (No MTA installed, discarding output)
May 3 19:05:01 testnix CRON[56487]: (CRON) info (No MTA installed, discarding output)
이상하게 1시간마다 실행 로그가 찍혀 있습니다. 일단 저 로그의 원인은 알 수 없지만, 적어도 rtcwake가 아닌 키보드 덕분에 절전 모드가 유지되고 있다는 것은 확실한 듯합니다.
그건 그렇고, 다음에 회사로 출근할 때 확인을 해봐야겠습니다. 어쩌면 BIOS 설정에서 절전 모드가 있었던 것은 아닐지...? ^^ (혹시 이와 관련해 원인을 짐작할 수 있는 분은 덧글 부탁드립니다.)
(2021-05-17: Bios의 Power에 Suspend Mode가 Auto, ACPI 2.0 Support (Disabled), ACPI APIC support (Enabled)로 기본 모드였습니다.)
(2021-05-31: 해당 머신은 Ubuntu 20.04 서버 운영체제로 재설치했고 관련 현상은 없는 상태입니다.)