Bug 253429 - Kremotecontrol works as root but not as "normal" user
Summary: Kremotecontrol works as root but not as "normal" user
Status: RESOLVED NOT A BUG
Alias: None
Product: kremotecontrol
Classification: Applications
Component: settings (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Michael Zanetti
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-06 21:39 UTC by benjamin.reveille
Modified: 2010-10-11 09:55 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
My lircd.conf file (2.24 KB, text/plain)
2010-10-06 21:39 UTC, benjamin.reveille
Details

Note You need to log in before you can comment on or make changes to this bug.
Description benjamin.reveille 2010-10-06 21:39:31 UTC
Created attachment 52289 [details]
My lircd.conf file

Version:           unspecified (using KDE 4.5.1) 
OS:                Linux

Lirc seems properly configured as using irw and pressing keys returns the correct info in konsole, and kremotecontrol works when started as root.

I've posted this an forums.kde.org and was told to file a bug

Reproducible: Always

Steps to Reproduce:
Start kremotecontrol as a standard user (my account, or a brand new account created just for a test) through systemsettings

Actual Results:  
It says lirc is not configured or no remotes found.

Expected Results:  
It should find the configuration which works for root (using kdesu to start systemssettings and access kremontecontrol configuration) and let me configure the remote for various softwares

I have been dragging this problem for a while now (things used to work way back (for sure with KDE3.X and at first in KDE4.X)

I was guessing this was a permission issue (as it works for root but not for other users) so I checked my files but don't see where the issue lies:

configuration files:
-rw-rw-rw- 1 root root   208 30 sept.  2008 /etc/lirc/lircmd.conf
-rw-rw-rw- 1 root root  2298 18 juil. 22:15 /etc/lirc/lircd.conf

lirc started with : 'LIRCD_OPTS="-H devinput -d /dev/tntremote /etc/lirc/lircd.conf"'
lrwxrwxrwx 1 root root      6  4 oct.  23:17 /dev/tntremote -> input/event6
crw-rw-rw- 1 root root 13, 70  4 oct.  23:17 /dev/input/event6
lrwxrwxrwx 1 root root 19  4 oct.  21:18 /dev/lircd -> /var/run/lirc/lircd=

prw-r--r-- 1 root root 0  3 oct.   2009 /var/run/lirc/lircm|
srw-rw-rw- 1 root root 0  4 oct.  21:18 /var/run/lirc/lircd=
-rw-rw-rw- 1 root root 5  4 oct.  21:18 /var/run/lirc/lircd.pid
Comment 1 Michael Zanetti 2010-10-07 20:49:03 UTC
Indeed, sounds like a permission thing, but the `ls` output seems correct...

Please perform the following steps to debug it further:

- make sure kremotecontrol is compiled using the "debug" use flag
- run "kdebugdialog" and turn on all debug output
- stop kded4 using "kquitapp kded4"
- run it again from konsole (It should print loads of debug stuff now - wait for it to settle down)
- execute "qdbus org.kde.kded /kded unloadModule kremotecontroldaemon"
- execute "qdbus org.kde.kded /kded loadModule kremotecontroldaemon"

The last two commands should stop and run the remotecontrol daemon (and put the icon in the notification area if enabled in systemsettings). Please attach the output of those two to this bug report.

Thanks
Comment 2 benjamin.reveille 2010-10-07 22:01:36 UTC
Hi Micheal and thanks for the answer

I had to kill -9 kded4_pid to stop kded4 as the kquitapp was not stopping it.

Here are the outputs:

> qdbus org.kde.kded /kded unloadModule kremotecontroldaemon
false

> qdbus org.kde.kded /kded loadModule kremotecontroldaemon
kded(11918)/kdecore (KSycoca) KSycocaPrivate::openDatabase: Trying to open ksycoca from  "/var/tmp/kdecache-dwardo/ksycoca4"

The icon didn't make it to the notifications area :( !
Comment 3 benjamin.reveille 2010-10-07 22:53:42 UTC
> qdbus org.kde.kded /kded loadModule kremotecontroldaemon
kded(11918)/kdecore (KSycoca) KSycocaPrivate::openDatabase: Trying to open ksycoca from  "/var/tmp/kdecache-dwardo/ksycoca4"
false
Comment 4 Michael Zanetti 2010-10-11 09:55:27 UTC
This turned out to be a permission problem. /usr/share/kde4/services had only read-access for root and so kded couldn't find the daemon plugin.

changing permissions, running kbuildsycoca4 and restarting kded4 solved the problem.