0

If I open a terminal and run the below script, it works fine. The values from the gdbus call get written to the lockScreenTest.txt file. The values are true when the screen is locked and the values are false when the screen is unlocked.

#!/bin/bash
while true; do 
    echo "$(gdbus call -e -d com.canonical.Unity -o /com/canonical/Unity/Session -m com.canonical.Unity.Session.IsLocked)" >> lockScreenTest.txt
    sleep 2
    echo "called" >> lockScreenTest.txt
done

But if I add this line ./lockScreenCheck.sh& to ~/.profile and restart the computer, the output of gdbus doesn't get written to lockScreenTest.txt. Instead, only the following output is written:

called

called

called

called

called

called

called

called

called

called

called

called

called

called

called

called

called

called

called

called

called

called

called

called

called

called

called

called

called

called

called

called

called

called

called

called

called

called

called

called  

Why isn't the output of gdbus available when the script is run from ~/.profile?
I'm investigating this because I wrote a Java program which needs to check if the screen is locked, and I'm doing it with roughly the following commands:

String command = "gdbus call -e -d com.canonical.Unity -o /com/canonical/Unity/Session -m com.canonical.Unity.Session.IsLocked";
p = Runtime.getRuntime().exec(command);
p.waitFor(); 

Like the bash script, the Java program also works fine if I run it from a terminal with java -jar program.jar, but if I invoke it from ~/.profile, the Java program runs, but the output from the gdbus command is elusive.

5
  • In what environment is ~/.profile being sourced? if it's outside of a desktop session, then likely DBUS_SESSION_BUS_ADDRESS has not yet been set – steeldriver Sep 10 '19 at 15:53
  • This is a normal desktop Ubuntu login. I Googled DBUS_SESSION_BUS_ADDRESS just now but couldn't get much of a clue as to what the problem might be. – Nav Sep 10 '19 at 15:57
  • Well ~/.profile is sourced by login shells; it may be the case that the display manager invokes a user's desktop session inside a login shell, but you shouldn't count on it and you certainly can't count on the DBUS being active before the session. I'd suggest moving your lockScreenCheck code to a Startup Application - see for example How do I start applications automatically on login? – steeldriver Sep 10 '19 at 16:08
  • Bingo! Added it to start applications and it works fine. Thank you. You are welcome to add an answer. – Nav Sep 11 '19 at 4:26
  • Thanks for the update - I have converted my comment(s) to a brief answer below – steeldriver Sep 11 '19 at 15:52
1

It's probably failing because gdbus cannot establish a connection to a running session bus.

Remember that ~/.profile is sourced by login shells; it may be the case that the display manager invokes a user's desktop session inside a login shell, but you shouldn't count on it and even if it does, the session will be a child of the shell rather than the other way around - environment variables such as DBUS_SESSION_BUS_ADDRESS won't be set in the parent shell.

For applications that need to connect to a desktop session's bus, you are better off using the GUI's "Startup Applications" feature - see for example How do I start applications automatically on login?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.