Comment 81 for bug 1246272

And so... considering information that was mentioned by previous posters, I did some investigation. First of I do not use any DM, I'm also big antifan of various useless deamons like gconf and dconf, and even before posting here I disabled them. I also do not run IBus. So that basically left me with very little files. So I used inotify on /etc/default/keyboard, and lo and behold something reads it, with no reason. Though getting the process that does that was a bit more difficult as inotify does not provide such information. I found that I can do this with auditd, so I setup fs audit:

auditctl -w /etc/default/keyboard -p war -k culprit

And after significant waiting [almost a day, I do not turn my machine off] (strangely moments before resets happened like once every 2-5 minutes, like 10 times in a row), I get keyboard reset, inotify reports file access, and here is what audit shows:

# ausearch -f /etc/default/keyboard
time->Thu Dec 4 09:16:47 2014
type=PATH msg=audit(1417677407.634:1120389): item=0 name="/etc/default/keyboard" inode=524629 dev=08:06 mode=0100664 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL
type=CWD msg=audit(1417677407.634:1120389): cwd="/"
type=SYSCALL msg=audit(1417677407.634:1120389): arch=c000003e syscall=2 success=yes exit=5 a0=7ffff3668ff0 a1=80000 a2=1b6 a3=0 items=1 ppid=9235 pid=8863 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="systemd-udevd" exe="/lib/systemd/systemd-udevd" key="culprit"

Now all I can say is that I suspected that something like that will be responsible for this. For a very long time now I have very hard time saying anything positive about systemd, this does not make it better. Considering that this is /dev related I'm pretty sure I can not simply nuke it without some unpeasant consequences. In any case, we now know what is causing it (well at least process-wise). Anyone has any suggestions how to work around this? And if fix can be expected?