그런데, 왜 그런지, 잠금화면이 마우스는 움직이는데, 키보드가 안 되는 듯 하다. 또한 상단 메뉴등이 클릭이 되지 않는다.
아예 멈춘것은 아닌데, 이상하다. 그래서 ssh 로 접속해보니, 정상적으로 동작하고 있었다. lock screen 만 이상한 것이다.
이런경우 ssh 로 root 접속한 후 다음 명령을 입력한다. (또는 sudo 명령으로 )
# loginctl unlock-sessions
일단 해결은 했는데, 왜 그런 현상이 발생했는지는 모르겠다.
현상 중 하나가 잠금화면의 암호 입력부분이 마치 키보드의 특정키가 눌린 것처럼 여러개가 눌려져 입력되어 있다는 것이다. (어디서 이상한 입력이 들어온다? - 해킹?) 위 원인으로 인한 다른 현상은 잠금화면이 되면, 모니터도 잠자기(?) 모드로 가는데, 모니터도 켜져 있다.
좀더 현상을 지켜봐야 겠다. (18.04 등으로 업그레이드를 해야할려나?)
[추가] 현상 재연을 확인했다. 키보드가 로지텍 무선 키보드인데, usb 리시버의 이상인지. 무선키보드 전원 껐다 다시 키면 , 특정문자가 여러개 입력이 되버린다.
켜져있는 상태에서 드라이버 문제인지, 키보드 자체문제인지, 혹은 usb 리시버, 혹은 메인보드 이상 현상으로 인한 문제일 듯 하다.
[ 2676.415781] mei 0000:00:16.0: unexpected reset.
[ 2706.390158] mei 0000:00:16.0: unexpected reset.
[ 2736.364548] mei 0000:00:16.0: unexpected reset.
[ 2766.338924] mei 0000:00:16.0: unexpected reset.
[ 2796.313317] mei 0000:00:16.0: unexpected reset.
[ 2826.287704] mei 0000:00:16.0: unexpected reset.
[ 2856.262086] mei 0000:00:16.0: unexpected reset.
[ 2886.236475] mei 0000:00:16.0: unexpected reset.
원래부터 나오던 메시지였는지도 불확실 하다.
다음과 같은 장치인데,
# lspci -v |grep -i mei
00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04)
Kernel modules: mei
MEI 는 Management Engine Interface 라고 한다.
Update - We have received word from
our colocation provider that there has been a power event in a section
of the Fremont datacenter. The affected space is where a critical part
of the datacenter network is located. The datacenter's electric provider
is working with staff to restore power as soon as possible. Please
watch this status page for further updates.
May 30, 02:25 UTC
Identified - We are aware of an
issue within our Fremont datacenter and are investigating at this time.
We will provide additional information as it becomes available.
May 30, 01:47 UTC
BTRFS error (device dm-6): block group 117604089856 has wrong amount of free space BTRFS error (device dm-6): failed to load free space cache for block group 117604089856
솔루션내에서 Product Advertising API 가 필요해서 연결중인데, 수익을 목적으로 하는 것은 아니고, 잘 되나 확인중이다.
1월경부터 시작해서, 이제야 적립이 된 듯 하다.
1월에는 금액이 별로 없다.(현재 400$ 이상 쌓인 듯 하다)
정산(?)이 2개월주기로 되는 듯 하다.
Unpaid Balance 인것을 보니, 아직 미 지급 된듯 한데, 글을 찾아보니 말경에 되는 듯 하다.
그러면 꼬박 3개월은 되어야 손에 수수료를 쥘 수 있는 듯 하다.
뭐! 부수입으로는 괜찮겠지만, 정산주기가 너무 길다.
추가 30 일 경에 드디어 입금이 되었다.
payoneer 계정으로 입금받도록 했는데, 입금이 되었다. payoneer 연회비로 대부분 빠져나갔다. 거의 첫 정산은 3달만에 이뤄진다. 다음달 부터는 한달단위로 되겠지. (페이오니아 는 25$ 프로모션을 하고 있다. - 가입후 100$ 이 계좌로 입금되면 25$ 리워드?를 준다.)
t eD iI N; InnoDB: End of page dump 140915 12:19:26 InnoDB: Page checksum 1570298453 (32bit_calc: 3018546506), prior-to-4.0.14-form checksum 1152805193 InnoDB: stored checksum 1570298453, prior-to-4.0.14-form stored checksum 1152805193 InnoDB: Page lsn 69 2816875854, low 4 bytes of lsn at page end 2816875854 InnoDB: Page number (if stored to page already) 4, InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0 InnoDB: Page may be an update undo log page InnoDB: Page may be an index page where index id is 18446744069414584320 140915 12:19:26 InnoDB: Assertion failure in thread 139780984702912 in file page0cur.c line 905 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 140915 12:19:26 [ERROR] mysqld got signal 6 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware.
To report this bug, see http://kb.askmonty.org/en/reporting-bugs
We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail.
Server version: 5.5.39-MariaDB-1~saucy-log key_buffer_size=134217728 read_buffer_size=2097152 max_used_connections=0 max_threads=302 thread_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1991930 K bytes of memory Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0x0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 0x0 thread_stack 0x48000 /usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x7f214c7efdae] /usr/sbin/mysqld(handle_fatal_signal+0x457)[0x7f214c3e1f07] /lib/x86_64-linux-gnu/libpthread.so.0(+0xfbb0)[0x7f214b491bb0] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f214a4aef77] /lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f214a4b25e8] /usr/sbin/mysqld(+0x816543)[0x7f214c730543] /usr/sbin/mysqld(+0x7f9e4c)[0x7f214c713e4c] /usr/sbin/mysqld(+0x7fbea6)[0x7f214c715ea6] /usr/sbin/mysqld(+0x780253)[0x7f214c69a253] /usr/sbin/mysqld(+0x791518)[0x7f214c6ab518] /usr/sbin/mysqld(+0x77ab5b)[0x7f214c694b5b] /usr/sbin/mysqld(+0x7dc453)[0x7f214c6f6453] /usr/sbin/mysqld(+0x795b75)[0x7f214c6afb75] /usr/sbin/mysqld(+0x72d009)[0x7f214c647009] /usr/sbin/mysqld(+0x6e8b9e)[0x7f214c602b9e] /usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x48)[0x7f214c3e4938] /usr/sbin/mysqld(+0x38dbd5)[0x7f214c2a7bd5] /usr/sbin/mysqld(_Z11plugin_initPiPPci+0x531)[0x7f214c2acb51] /usr/sbin/mysqld(+0x2f1282)[0x7f214c20b282] /usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x5ca)[0x7f214c2101ca] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f214a499de5] /usr/sbin/mysqld(+0x2ec6f7)[0x7f214c2066f7] The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash. 140915 12:19:26 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
140915 12:46:04 InnoDB: Waiting for the background threads to start 140915 12:46:05 InnoDB: Waiting for the background threads to start
찾아보니, 다음 옵션을 추가하라고 한다.
innodb_purge_threads=0
mysqlcheck --all-databases 를 해본다.
InnoDB: space id 74 did not exist in memory. Retrying an open. 140915 13:24:47 InnoDB: Warning: allocated tablespace 74, old maximum was 9 .... InnoDB: space id 83 did not exist in memory. Retrying an open
다음과 같은 메시지가 나온다.
점점 골치가 아파진다. 나에겐 InnoDB 는 사치인가?
이런 에러도 보인다.
140915 20:04:43 InnoDB: Assertion failure in thread 140280661518080 in file fsp0fsp.c line 2113
포스팅해주신글 덕분에 vultr 를 알게되었습니다. 좋은 서버 호스팅 업체 추천해주셔서 정말 감사합니다..
vultr 가입을 하면서 알게된 점인데, 최근에 생긴 도메인 같습니다.
vultr.kr 으로 가입하면 $10~$200 프로모션을 받을 수 있더라구요.. 선결제 금액에 따라 차등으로 받으니까 적당히 크레딧 충전하시면 프로모션도 챙기실 수 있으니까 아마 블로그에서도 링크수정하신다면 방문자분들이 더 많은 혜택 누리실 수 있을 것 같습니다.
최근에 $2.5 샌드박스 요금제가 출시되었고 1인당 2개까지만 구매 가능합니다.
아쉽지만 현재는 재고 부족으로 구매가 불가능한 상황입니다.
vultr 은 최근에 디도스 방어도 제공하고 있고, 일본 기준 10MB/s 속도 나올 정도로 10Gbps 속도가 매우 좋습니다. 요즘에는 다운도 안되구요. 정말 좋은 업체라고 생각합니다.