OSX: DBus Session Lookup Always Fails when Run from Cron or a Parent Process - Direct Exec Always Works

[Jim Mannix]

Hi Rene,
Thanks for your detailed response.
I do think it could be just an environment variable issue but I would not be shocked if there was more to it than that.


> On Dec 18, 2015, at 1:57 AM, René J.V. Bertin <rjvbertin at gmail.com> wrote:
> 
> On Thursday December 17 2015 18:07:57 Jim Mannix wrote:
> 
>> 
>> I’ve tried a great many things to get a Qt/DBus application to work under automation, but it only works when run directly.manually by a human in a terminal .. and the application is intended for cron automation or automation by a parent process.
> 
> That is with Qt5 I presume? Was it written from scratch for OS X?
I could not find a Qt version number, but it seems like the issue might just be in the Net::DBus->session() call and how that code is trying to determine a session identifier.
I don’t have anything pointing me to the Qt part of it at this point.
It might be an issue on OSX with some part of the Net::DBus module and probably specific to OSX.

I would imagine that folks would expect DBus to find the correct session even when run from cron or some upstream parent process.
I do realize however that some technologies are sensitive to environment variables in this context, but I have tried everything I can possibly think of to solve a mere ENV variable issue.

Perhaps there is a very dynamic environement variable involved and it only exists briefly right at the problem point and that is why I have not seen it or been able to capture/pass it on or make sure it is inherited in some manner.
Stabbing in the dark a little there .. but that’s where I am at.

> 
> Not that I can help you, but it looks a lot like an issue I have ran into myself porting KF5 (KDE5) frameworks and applications:
> 
> KF5's secure wallet feature relies on a central daemon process (kwalletd5) which handles and serves all requests to access wallets; it uses gpgme when available and thus requires communication with an appropriate pinentry tool.
> 
> This works fine when kwalletd5 is started manually from a terminal. It does not however if the daemon is started automatically when an application tries to access a wallet, even if that parent process is started manually from a terminal. The same applies when starting kwalletd5 through a launchctl script or even through LaunchServices; building it as an app bundle or not doesn't make a difference, nor does the LSUIElement setting.
> It's been a while since I last checked this particular issue, but the error message about loading the DBus session plist seems familiar in this context. Coupled with the OOM error it does look like it comes from a bit of code that doesn't really know what it's reporting on (or reports an inappropriate error code).

There is a daemon and launchctl involved in my scenario but I have not dived too deep into that part.

I did at one point get the same error I am reporting, but in this rare case it occurred when I was manually running things (the context in which they normally work fine.)
But in this case I figured out that the daemon process was not running.
I did an unload of the plist, confirming it was not running.
Then I loaded again .. presumably no restarting the missing service.

The error went away; things ran fine again.
This error is very generic in my opinion .. occurring both for a missing service as well as a scenario in which a session cannot be identified.
(*Unless perhaps the actual scenario in both cases IS a missing service .. SOMETHING TO CONSIDER. i.e. The error message was the same in these two different scenarios because the underlying issue (similar to a missing/crashed service) is as good or better definition of the root cause as the inability to identify a session.) Gotta love it when you get vague/ambiguous error messages, but it happens.

I have read discussions touching on vagaries of how sessions are identified and while ENV vars have been mentioned, I have also see things mentioned referring to DBus looking at what user or what PID started the service in question .. as part of identifying the correct session.

I will probably be doing more experiments soon and will update with anything interesting.

Regards,
Jim

> 
> I'd be a bit surprised if the OS X implementation of gpgme uses DBus to communicate with the pinentry utility, but the communication between kwalletd5 and its clients is definitely done using DBus.
> 
> My first thought was that the DBus session address env.variable somehow gets lost or went stale; that appears not to be the case (it still shows up correctly in `launchctl export` and thus should be available to any process started no matter how).
> 
> Do DBus and/or Qt5 use any other env. variables that might not be available to applications that are not started manually from a terminal, on OS X?
> 
> FWIW ...
> René