이것은 나를 당황하게 만들었습니다. 3일 전(2014-20-10) Ubuntu 14.04가 느려지기 시작했습니다.
나는 gedit를 연 다음 gedit를 닫아 재현했습니다. 문제가 활성화되면 빈 파일을 닫는 데 약 2초가 걸리는 반면, 문제가 없으면 이것은 항상 즉각적입니다. 비슷한 방식으로 다른 모든 것에 영향을 미칩니다.
top은 정지가 발생해도 비정상적인 활동을 보고하지 않으며, htop도 동일하고, iotop도 동일합니다.
문제는 가동 시간 30분 후에만 발생합니다. 가동 시간 29분에는 재현할 수 없었고, 가동 시간 31분에는 이를 일관되게 재현할 수 있었고(위 방법을 사용하면 터미널 및 htop 이외의 앱은 시작되지 않음) 관리할 수 있습니다. 이 작업을 4~5회 반복합니다(종료하고 부팅하고 30분 동안 기다리며 - 즐거웠습니다).
재부팅 후에도 문제가 지속되지만 종료하고 전원을 다시 켜면 재설정할 수 있습니다. Ubuntu의 어떤 부분이 재부팅 후에도 상태를 유지하지만 종료되지 않습니까?
이 기간에 대한 관련 로그는 syslog, auth.log 및 Xorg.0.log입니다(지정된 범위에서 수정된 시간에 대해 /var/log의 내용을 검사함).
시스템로그:
Oct 22 17:21:36 raiden NetworkManager[1102]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Oct 22 17:39:01 raiden CRON[3284]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime))
Oct 22 18:09:01 raiden CRON[3370]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime))
인증 로그:
Oct 22 17:39:01 raiden CRON[3283]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 22 17:39:01 raiden CRON[3283]: pam_unix(cron:session): session closed for user root
Oct 22 18:09:01 raiden CRON[3369]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 22 18:09:01 raiden CRON[3369]: pam_unix(cron:session): session closed for user root
Oct 22 18:17:01 raiden CRON[3495]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 22 18:17:01 raiden CRON[3495]: pam_unix(cron:session): session closed for user root
Xorg.0.log: (아마도 컴퓨터 백업을 깨운 것 같습니다.)
[ 3466.727] (II) intel(0): switch to mode [email protected] on LVDS1 using pipe 0, position (0, 900), rotation normal, reflection none
[ 3466.880] (II) intel(0): switch to mode [email protected] on VGA1 using pipe 1, position (0, 0), rotation normal, reflection none
이들 중 어느 것도 나쁜 점을 나타내지 않으며 문제를 재현하기 위한 후속 단계는 로그에 변경 사항이 없음을 나타내므로 이는 단지 무고한 로그일 가능성이 높습니다.
나는 이 문제의 원인이 3가지라고 생각합니다.
소프트웨어 설치: 이상한 것을 설치했습니다.
나는 그랬다:
- 역사 | grep apt-get' - 해당 기간 동안 설치가 없습니다.
- 시냅틱 패키지 관리자 기록을 살펴봤습니다. 해당 기간에는 아무것도 없습니다.
- 소프트웨어 센터 기록 - 마지막 업데이트는 몇 주 전이었습니다(종속성 문제가 있어서 한동안 업데이트를 하지 않았습니다).
- 해당 기간에 Ubuntu용 Skype를 설치했지만 Skype로 인해 발생했다는 표시는 없습니다(어쨌든 제거했습니다).
크론 작업이 잘못됨
crontab, /etc/cron.d /etc/cron.daily에서 cronjob을 확인하고 매시간 거기에 뭔가가 있다는 것을 나타내는 아무것도 없습니다. PHP cron 작업은 30분마다 발생하지만 cron이라면 24시간 내내 특정 지점에서 수행됩니다. 시작 후 30분.
속도가 느려지지 않은 상태와 속도가 느려진 상태 사이에 시작된 새 프로세스를 분석하면 새 프로세스가 시작되지 않은 것으로 나타났습니다. (첫 번째 테스트에서는 kworker 스레드가 표시되었지만 이는 우연의 일치일 가능성이 높습니다.) 나는 이것이 그것을 촉발한 기존 프로세스이거나 다른 무엇인가를 의미해야 한다고 생각합니다.
악성 코드
이해하기 어렵고 30분 동안 문제가 발생하지 않기 때문에(30분은 인간이 선택한 시간인 것 같습니다) 그럴 가능성은 거의 없지만 일종의 악성 코드일 수 있다고 생각하기 시작했습니다(업데이트를 수행하지 않았습니다). 잠시 동안 몇 개의 포트가 열려 있습니다). 그래서 rkhunter(루트킷 파인더)를 실행했지만 잘못된 것은 아무것도 발견되지 않았습니다.
내가 시도한 다른 것들:
- 특정 compiz 구성 요소 선택 해제 - 변경 사항 없음
- compiz 다시 시작 - 변경 사항 없음
- 모든 compiz 구성 요소 선택 해제 - 변경 사항 없음(컴퓨터를 다시 사용할 수 있게 하기 위해 씨름하는 것을 제외하고)
- 가동 시간이 30분에 이를 때까지 기다리는 동안 다양한 악기를 연주한 다음 의심스러운 변화가 있는지 top 및 htop의 결과를 관찰합니다. 이상한 것은 아닙니다.
이와 비슷한 일이 발생한 사람이 있습니까? 아니면 저에게 올바른 방향을 알려줄 수 있습니까? 그렇다면 귀하의 답변에 대해 찬성 투표 버튼을 반복해서 누를 것입니다(홀수인지 확인하겠습니다).
답변1
시작 후 30분 후에 작업을 실행하도록 cron을 구성하는 몇 가지 방법이 있습니다. Jenkins는 함수를 해싱하고 H/30 * * * *예를 들어 이를 수행합니다. 또한 30분 동안 잠자고 자동 CPU 킬러 프로세스를 생성하는 스레드일 수도 있습니다.
거기에 몇 가지 아이디어가 있습니다.
htop을 루트로 사용해 보셨나요? 일부 프로세스는 보이지 않을 수 있습니다. 특히 데비안에서 이런 현상을 보았습니다.
문제가 발생했을 때 로그아웃/다시 로그인을 시도하셨나요? 창 관리자 또는 세션 문제일 수 있습니다.
로그아웃/로그인이 작동하지 않으면 세션 관리자를 다시 시작해 보세요. 나는 그것이 기본적으로 lightdm이라고 생각하므로 sudo service lightdm restart그렇게 해야 합니다.
답변2
이는 다음으로 인해 발생했습니다.스마트 데이터문제의 드라이브에 대해 활성화되어 있습니다.
SMART 데이터를 비활성화하면 이 문제가 해결되었습니다.
sudo smartctl --smart=off /dev/sda
아마도 디스크가 회전하고 루프에 빠진 후 30분 동안 일종의 내부 자체 테스트가 계속 재실행되었을 것입니다. 이는 하드웨어 계층에 있었기 때문에 컴퓨터의 나머지 부분은 진행 상황을 인식하지 못했기 때문에 특히 IO 차단을 담당하는 프로세스나 리소스를 차지하는 프로세스를 볼 수 없었습니다.