매번 부팅하면 블루투스가 꺼진다
이날은 코드를 안 짜고 시스템 문제를 잡은 날이었다.
매번 부팅할 때마다 블루투스가 꺼져 있어서 수동으로 다시 켜야 하는 문제가 있었다.
귀찮은 일이었는데, 드디어 원인을 찾아서 고쳤다.
증상은 단순했다.
컴퓨터를 켤 때마다 블루투스가 꺼져 있었다.
어제 분명히 켜놓고 종료했는데, 다시 켜면 꺼져 있다.
그래서 매번 설정 들어가서 블루투스를 다시 켜야 했다.
이건 항상 켜두는 우분투 서버를 운영하면서 풀고 싶었던 작은 짜증 중 하나였다.
서버를 안정적으로 운영하려면 잡다한 수동 작업을 없애야 한다.
블루투스 매번 켜는 것도 그중 하나였다.
원인은 서비스가 숨겨져 있었다
원인을 추적해보니 systemd-rfkill 서비스가 숨겨져 있었다.
systemd-rfkill은 재부팅해도 무선 장치 상태를 기억하는 서비스다.
블루투스랑 와이파이 켜기 상태를 저장했다가, 다음 부팅 때 그 상태로 복원한다.
이 서비스가 정상이면 블루투스를 켜놓고 재부팅해도 켜진 채로 돌아온다.
근데 이 서비스가 비활성화된 게 아니라 아예 숨겨져 있었다.
숨겨지면 서비스가 아예 동작을 안 한다.
그러니까 재부팅할 때 상태 복원이 안 되고 블루투스는 기본값인 꺼짐으로 돌아간다.
범인은 한참 전에 설치한 TLP
그럼 왜 이 서비스가 숨겨져 있었을까. 범인은 TLP라는 절전 패키지였다.
두 달 전쯤에 노트북 배터리 최적화를 위해서 설치했던 거다.
근데 TLP가 설치될 때 systemd-rfkill을 자동으로 숨긴다는 걸 몰랐다.
TLP가 이렇게 하는 이유가 있다.
TLP가 자기가 직접 블루투스랑 와이파이 전원 상태를 관리하고 싶어서다.
systemd-rfkill이 같은 일을 하니까, 충돌을 피하려고 경쟁 서비스를 숨겨버리는 거다.
TLP 입장에서는 합리적인 선택이다.
근데 문제는 이 부작용이 설치한 날 바로 안 보인다는 거다.
TLP를 설치한 날에는 블루투스가 정상일 수 있다.
왜냐하면 그 세션 안에서는 상태가 유지되니까. 문제는 재부팅하고 나서야 드러난다.
그러니까 원인이 TLP 설치라는 걸 알아채리가 어렵다.
원인이랑 증상이 한참 떨어져 있는 거다.
두 달 전의 설치가 오늘의 블루투스 문제를 만들고 있었다.
수정
해결은 세 단계다.
sudo systemctl unmask systemd-rfkill.service sudo systemctl enable systemd-rfkill.service
sudo systemctl start systemd-rfkill.service
숨김을 풀고, 활성화하고, 시작한다.
이렇게 하니까 재부팅해도 블루투스가 켜진 채로 유지됐다.
시스템 로그랑 서비스 상태를 직접 확인해서 정상 동작을 검증했다.
더 이상 매번 수동으로 켤 필요가 없어졌다.
남는 질문
하나 남는 질문이 있다.
TLP랑 systemd-rfkill을 같이 쓸 수 있는가. 두 가지 방향이 있다.
하나는 TLP 설정에서 상태 복원 옵션을 켜서, TLP가 직접 상태를 복원하게 만드는 거다.
다른 하나는 TLP의 블루투스 관리를 끄고 systemd-rfkill한테 맡기는 거다.
둘 중 어느 쪽이 더 나은지는 아직 못 정했다.
당장은 systemd-rfkill을 복원하는 걸로 문제를 해결했다.
TLP가 다른 절전 기능은 여전히 쓰고 있으니까, 두 서비스가 충돌하는지는 좀 더 지켜봐야 한다.
마무리
이런 디버깅이 재밌는 이유는, 원인이랑 증상이 멀리 떨어져 있기 때문이다.
블루투스가 꺼지는 증상만 보면 블루투스 쪽을 의심하게 된다.
블루투스 데몬, 드라이버, 하드웨어 같은 곳을 뒤지게 된다.
근데 진짜 원인은 두 달 전에 설치한 절전 패키지였다.
전혀 관련 없어 보이는 패키지가, 부작용으로 서비스를 숨긴 거다.
이런 연결을 찾는 게 디버깅의 핵심이다.
그리고 항상 켜두는 서버를 운영하려면, 이런 작은 짜증도 하나씩 없애야 한다.
매번 수동으로 블루투스를 켜는 건 10초짜리 일이지만 매일 하면 귀찮다.
자동화하거나 고쳐놓으면 그 귀찮음이 영원히 사라진다.