trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: March 2014

Re: [trinity-devel] [tde_dbus_hardwarecontrol] Name request failed with error - normal?

From: "David C. Rankin" <drankinatty@...>
Date: Sat, 01 Mar 2014 22:36:49 -0600
On 03/01/2014 10:28 PM, David C. Rankin wrote:
> All, tdehw guys,
> 
>   Checking through my logs I note a consistent error from
> [tde_dbus_hardwarecontrol. The sequence of errors occurs on each login (several
> times):
> 
> Mar 01 21:40:15 valhalla org.trinitydesktop.hardwarecontrol[180]:
> [tde_dbus_hardwarecontrol] Name request failed with error 'Rejected send
> message, 2 matched rules; type="method_call", sender=":1.18" (uid=1000 pid=1597
> comm="tdepowersave [tdeinit]                            ")
> interface="org.trinitydesktop.hardwarecontrol.Power" member="CanHibernate" error
> name="(unset)" requested_reply="0"
> destination="org.trinitydesktop.hardwarecontrol" (uid=0 pid=1621
> comm="/opt/trinity/bin/tde_dbus_hardwarecontrol ")'
> 
> Mar 01 21:40:15 valhalla org.trinitydesktop.hardwarecontrol[180]:
> [tde_dbus_hardwarecontrol] Not primary owner (-1), exiting!
> 
> Mar 01 21:40:15 valhalla dbus[180]: [system] Activated service
> 'org.trinitydesktop.hardwarecontrol' failed: Launch helper exited with unknown
> return code 1
> 
>   I'm not sure if this is an 'error' or just a normal 'test for capabilities',
> not available, fail, situation?
> 
>   To me it looks like dbus org.trinitydesktop.hardwarecontrol.Power checks
> member "CanHibernate" and finds the name "(unset)". It checks that it is 'Not
> primary owner', then throws a 'failed: Launch helper exited with unknown return
> code 1'.
> 
>   I want to know if this is normal behavior or if there is a problem. On all old
> 3.5.13-sru hal installs I have the option to suspend/hibernate as a logout
> option. With R14 (same environment) I do not have that option available. Is that
> expected?
> 

opening kcontrol screensaver, I also get a coredump:

Mar 01 22:29:29 valhalla systemd-coredump[1780]: Process 1775 (kflux.kss) dumped
core.

This may be part of the bug 1902 user session tracking issue due to the
screensaver not being registered with the pam_stack in the pure-systemd
environment without consolekit. Why else would a screensave cause a
systemd-coredump?

-- 
David C. Rankin, J.D.,P.E.