This did not call any visible problem without audit (just some higher cpu usage and context switching, but user/admin can't see that without load profiling). Problem appeared with auditd enabled, because this activity produce many records in audit journal, that lead to free disk space consumption. For example. system with two idle users generate about ~1000 audit events/second like above (Every access to proc, cause 3 audit event in journal), that about 240K/sec free space out. Below an strace block for Xvnc process, may be it help? There are two 'open' syscall to proc, after getsockopt. ... select(256, [0 1 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 34 36 37], [30], NULL, {39, 991000}) = 2 (in [0 36], left {39, 990992}) setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0 read(36, "\210\0\2\0\1\0\0\0", 4096) = 8 read(36, 0x16908e0, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(36, [{"\1\1\6\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 32}], 1) = 32 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 accept(0, {sa_family=AF_FILE, NULL}, [2]) = 33 fcntl(33, F_GETFL) = 0x2 (flags O_RDWR) fcntl(33, F_SETFL, O_RDWR|O_NONBLOCK) = 0 getsockopt(33, SOL_SOCKET, SO_PEERCRED, "g\n\0\0\364\1\0\0\364\1\0\0", [12]) = 0 open("/proc/2663/cmdline", O_RDONLY) = 35 read(35, "metacity\0", 4097) = 9 close(35) = 0 select(256, [0 1 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 36 37], [30], NULL, {39, 981000}) = 4 (in [0 23 33 36], left {39, 980992}) setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0 read(23, "(\0\4\0|\315U\2\354\0\0\0\0\0\31\0", 4096) = 16 read(23, 0x1efeae0, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(23, [{"\1\1\206\5\0\0\0\0\306\345\r\1\362\0Y\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 32}], 1) = 32 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 accept(0, {sa_family=AF_FILE, NULL}, [2]) = 35 fcntl(35, F_GETFL) = 0x2 (flags O_RDWR) fcntl(35, F_SETFL, O_RDWR|O_NONBLOCK) = 0 getsockopt(35, SOL_SOCKET, SO_PEERCRED, "\371F\0\0\364\1\0\0\364\1\0\0", [12]) = 0 open("/proc/18169/cmdline", O_RDONLY) = 38 read(38, "/usr/bin/gpk-update-icon\0", 4097) = 25 close(38) = 0 select(256, [0 1 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37], [30], NULL, {39, 966000}) = 4 (in [23 33 35 36], left {39, 965987}) ... > I have no experience in kernel auditing and my collegues who probably > do are away on vacation at the moment. > But as far as I can see, this is not an issue we have seen before. I do > not know what can be causing it. Does these cmdline calls cause high > load or any other problems? > > Regards,