2

I use Linux Mint 16 Petra 64bit Cinnamon. When I install Skype (either from repo, or directly from Microsoft) it soon starts using 100% of 1 CPU Core, doubling power consumption of my system.

I tried removing the ~/.skype folder and logging with different account.

I tried removing the skype from repositories and install it directly from Microsoft.

Is there anything I can do to troubleshoot and fix this problem?

I can't reproduce this problem with older Mints, nor with Ubuntu Saucy and Raring.

The doesn't manifest itself, if I launch skype and never log in (keep skype displaying the login screen). But if the skype was logged in before and had the high CPU consumption - clicking "Sign Out" doesn't help the problem (besides even if it did, there is little point in using skype without logging in)

Following the advise of @slm I can include the strace output. It seems that Skype is busy doing poll syscall... I thought that polling for resource introduces processor idling, not 100% usage.

 strace -c skype [ Process PID=31614 runs in 32 bit mode. ] % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 0.00 0.000000 0 1 execve ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000000 1 total System call usage summary for 32 bit mode: % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 96.95 45.349256 493 92056 poll 1.26 0.588104 2 279026 clock_gettime 0.99 0.462877 3 183996 182979 recv 0.33 0.156517 2 79850 468 stat64 0.30 0.138574 2 79740 gettimeofday 0.10 0.047275 45 1040 174 futex 0.04 0.020046 1671 12 nanosleep 0.01 0.003025 4 792 writev 0.00 0.002037 2 871 write 0.00 0.001928 3 692 143 read 0.00 0.001482 2 944 561 open 0.00 0.000591 2 333 238 access 0.00 0.000584 1 466 mmap2 0.00 0.000577 1 421 madvise 0.00 0.000485 1 431 close 0.00 0.000462 4 120 munmap 0.00 0.000378 3 115 mprotect 0.00 0.000372 4 86 fstatfs64 0.00 0.000269 1 263 fstat64 0.00 0.000175 3 66 29 recvmsg 0.00 0.000113 1 121 time 0.00 0.000108 1 113 5 lstat64 0.00 0.000082 3 29 getdents64 0.00 0.000056 2 30 fadvise64_64 0.00 0.000047 3 15 openat 0.00 0.000046 15 3 shmdt 0.00 0.000045 2 24 sendmsg 0.00 0.000038 2 22 clone 0.00 0.000037 1 33 socket 0.00 0.000032 2 13 _llseek 0.00 0.000032 11 3 shmat 0.00 0.000032 11 3 shmget 0.00 0.000031 1 29 brk 0.00 0.000027 5 6 shmctl 0.00 0.000015 2 9 send 0.00 0.000013 0 27 fcntl64 0.00 0.000011 2 6 2 connect 0.00 0.000007 2 3 readlink 0.00 0.000007 1 13 rt_sigaction 0.00 0.000005 1 4 geteuid32 0.00 0.000005 1 4 getsockname 0.00 0.000003 0 10 uname 0.00 0.000003 3 1 eventfd2 0.00 0.000003 3 1 pipe2 0.00 0.000002 2 1 set_tid_address 0.00 0.000002 2 1 getpeername 0.00 0.000001 1 2 rt_sigprocmask 0.00 0.000001 1 2 getrlimit 0.00 0.000001 1 2 clock_getres 0.00 0.000001 1 1 set_robust_list 0.00 0.000000 0 2 unlink 0.00 0.000000 0 2 chmod 0.00 0.000000 0 3 3 mkdir 0.00 0.000000 0 1 pipe 0.00 0.000000 0 22 ioctl 0.00 0.000000 0 1 umask 0.00 0.000000 0 4 statfs 0.00 0.000000 0 4 fstatfs 0.00 0.000000 0 2 flock 0.00 0.000000 0 3 getuid32 0.00 0.000000 0 1 getgid32 0.00 0.000000 0 1 getegid32 0.00 0.000000 0 1 getresuid32 0.00 0.000000 0 1 getresgid32 0.00 0.000000 0 2 gettid 0.00 0.000000 0 1 sched_getaffinity 0.00 0.000000 0 1 set_thread_area 0.00 0.000000 0 4 1 bind 0.00 0.000000 0 1 listen 0.00 0.000000 0 2 sendto 0.00 0.000000 0 1 shutdown ------ ----------- ----------- --------- --------- ---------------- 100.00 46.775820 721911 184603 total

When I attach strace to running skype with sudo strace -p $(pgrep skype) I get tons of the following entries:

clock_gettime(CLOCK_MONOTONIC, {7553, 920730509}) = 0 recv(6, 0xf967e5a8, 4096, 0) = -1 EAGAIN (Resource temporarily unavailable) clock_gettime(CLOCK_MONOTONIC, {7553, 920937548}) = 0 poll([{fd=3, events=POLLIN}, {fd=7, events=POLLIN}, {fd=6, events=POLLIN}, {fd=9, events=POLLIN}, {fd=12, events=POLLIN}, {fd=28, events=POLLIN}], 6, 0) = 0 (Timeout) recv(6, 0xf967e5a8, 4096, 0) = -1 EAGAIN (Resource temporarily unavailable) clock_gettime(CLOCK_MONOTONIC, {7553, 921039735}) = 0 recv(6, 0xf967e5a8, 4096, 0) = -1 EAGAIN (Resource temporarily unavailable) clock_gettime(CLOCK_MONOTONIC, {7553, 921089170}) = 0 poll([{fd=3, events=POLLIN}, {fd=7, events=POLLIN}, {fd=6, events=POLLIN}, {fd=9, events=POLLIN}, {fd=12, events=POLLIN}, {fd=28, events=POLLIN}], 6, 0) = 0 (Timeout)
Improve this question

2 Answers 2

Reset to default
3

strace profile

You could try debugging it further using strace to see what system calls skype is making that are causing the surge in resources. This will show you what system calls skype is stuck in.

Example

$ strace -c ls afile1 afile2 afile3 afile4 afile5 % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 0.00 0.000000 0 8 read 0.00 0.000000 0 1 write 0.00 0.000000 0 10 open 0.00 0.000000 0 13 close 0.00 0.000000 0 1 stat 0.00 0.000000 0 11 fstat 0.00 0.000000 0 27 mmap 0.00 0.000000 0 18 mprotect 0.00 0.000000 0 2 munmap 0.00 0.000000 0 3 brk 0.00 0.000000 0 2 rt_sigaction 0.00 0.000000 0 1 rt_sigprocmask 0.00 0.000000 0 2 ioctl 0.00 0.000000 0 1 1 access 0.00 0.000000 0 1 execve 0.00 0.000000 0 2 getdents 0.00 0.000000 0 1 getrlimit 0.00 0.000000 0 2 statfs 0.00 0.000000 0 1 arch_prctl 0.00 0.000000 0 1 set_tid_address 0.00 0.000000 0 1 openat 0.00 0.000000 0 1 set_robust_list ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000000 110 1 total

top & htop

You can also monitor skype using a tool such as top or htop to see what the processes is doing overall.

   ss of htop

strace - attaching to a running process

You can also use strace to attach to already running processes. This allows you to attach after they've started to misbehave.

Example

Say we want to attach to our already running htop process from above.

$ pgrep htop 32495

This is htop's PID - process ID. You can use these to connect strace.

$ strace -p 32495 |& head -10 Process 32495 attached select(1, [0], NULL, NULL, {0, 729724}) = 0 (Timeout) open("/proc/meminfo", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f685faf1000 read(3, "MemTotal: 7969128 kB\nMemF"..., 1024) = 1024 read(3, "e: 0\nHugePages_Rsvd: "..., 1024) = 146 read(3, "", 1024) = 0 close(3) = 0 munmap(0x7f685faf1000, 4096) = 0 ... ...

UPDATE #1 - debugging the poll() syscalls

The strace the OP provided show a high level of poll() system calls. You can find out what these are via man poll.

 poll, ppoll - wait for some event on a file descriptor

So Skype is waiting on a file descriptor, but in this case it isn't necessarily a file, it may be, but probably it's waiting on a network resource that is wrapped in a file descriptor.

Example

To show this a little better here's an example. Say we were downloading a 100MB file like this using wget.

$ wget -O /dev/null http://speedtest.wdc01.softlayer.com/downloads/test100.zip

We could then see what file descriptors were in use using the command lsof -c wget.

$ lsof -c wget COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME wget 11531 saml cwd DIR 253,2 4096 7340394 /home/saml/media/mp3s/kids_music wget 11531 saml rtd DIR 253,1 4096 2 / wget 11531 saml txt REG 253,1 421712 531380 /usr/bin/wget wget 11531 saml mem REG 253,1 310576 544452 /usr/lib64/libgssapi_krb5.so.2.2 ... ... wget 11531 saml mem REG 253,1 62368 528212 /usr/lib64/libnss_files-2.17.so wget 11531 saml mem REG 253,1 106055264 803764 /usr/lib/locale/locale-archive wget 11531 saml mem REG 253,1 26254 660143 /usr/lib64/gconv/gconv-modules.cache wget 11531 saml 0u CHR 136,2 0t0 5 /dev/pts/2 wget 11531 saml 1u CHR 136,2 0t0 5 /dev/pts/2 wget 11531 saml 2u CHR 136,2 0t0 5 /dev/pts/2 wget 11531 saml 3w CHR 1,3 0t0 1028 /dev/null wget 11531 saml 4u IPv4 1543927 0t0 TCP greeneggs.bubba.net:55907->speedtest.wdc01.softlayer.com:htt

Notice the last line, that's a file descriptor for our connection to softlayer.com. So the network connection is also treated as a a poll() to via a file descriptor. You can do the same and confirm using a command such as:

$ lsof -c skype
Improve this answer
2
  • Thank you very much! I've included the strace to the question. Commented Jan 12, 2014 at 10:49
  • @AdamRyczkowski - this probably seems like it's going no where but bare with me, please see updates, and please confirm using lsof -c skype. Commented Jan 12, 2014 at 18:02
0

After re-installation of the whole system in seemingly the same way as the affected system was installed, the problem never re-appeared.

(And who says that you don't have to format the hard drive to solve solve problems under Linux? ;-) )

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.