Gsettings does not work from inside a script

lamyergeier · March 24, 2024, 11:28am

Installed kernel: 6.7.6-200.fc39.x86_64
Fedora release 39
Desktop: GNOME 45.4
Display Server: wayland

Followings works as expected (when executed from terminal) and color scheme changes:

$ gsettings set org.gnome.desktop.interface color-scheme 'prefer-dark'
$ gsettings set org.gnome.desktop.interface color-scheme 'prefer-light'

Followings does not works (i.e. nothing happens) (when executed from inside a bash script) and color scheme does not change:

$ cat Theme.sh
gsettings set org.gnome.desktop.interface color-scheme 'prefer-dark'
gsettings get org.gnome.desktop.interface color-scheme

bash ./Theme.sh
'prefer-dark'
gsettings get org.gnome.desktop.interface color-scheme
'prefer-light'

Please see similar issue I raised but facing similar problem: gsetttings not working from inside bashrc - Unix & Linux Stack Exchange

skeller · March 24, 2024, 11:52am

Are you running the script as the same user and within the same DBus session (i.e. using the same DBUS_* environment variables as the GNOME session you want to change this for)?

lamyergeier · March 24, 2024, 12:18pm

I am a basic user I haven’t done much customization. I logged into Fedora with my user and password and executed above in the gnome terminal.

Could you please tell me the command to test what you asked for?

Is this what you meant?

$ echo $DBUS_SESSION_BUS_ADDRESS 
unix:path=/run/user/1000/bus

$ \cat Theme.sh
#!/usr/bin/env bash
echo $DBUS_SESSION_BUS_ADDRESS
whoami
gsettings set org.gnome.desktop.interface color-scheme 'prefer-light'
gsettings get org.gnome.desktop.interface color-scheme

$ whoami
lamy

$ bash ./Theme.sh 
unix:path=/run/user/1000/bus
lamy
'prefer-light'

skeller · March 24, 2024, 12:34pm

This output looks correct. Is it not working?

lamyergeier · March 24, 2024, 5:19pm

No. The theme does not change! You can see from the following output itself (gsettings get shows immediately different value)

@skeller Please see similar issue I raised but facing similar problem: gsetttings not working from inside bashrc - Unix & Linux Stack Exchange

skeller · March 24, 2024, 5:46pm

Your script is working fine here. Did you maybe put some stuff in your .bashrc (or similar files) that would interfere with it?

lamyergeier · March 26, 2024, 10:56am

When I removed everything from ~/.bashrc, following commands when executed from terminal do nothing

$ gsettings set org.gnome.desktop.interface color-scheme 'prefer-dark'
$ gsettings set org.gnome.desktop.interface color-scheme 'prefer-light'

Also is it because of the following

$ ls -a -l ~/.config/dconf
lrwxrwxrwx. 1 lamy lamy 23 May 13  2023 /home/lamy/.config/dconf -> /mnt/Data/.config/dconf

Creating Alias works

Gsetting="org.gnome.Terminal.ProfilesList"
TerminalDarkProfile="b1dcc9dd-5262-4d8d-a863-c897e6d979b9"  # Theme is stored in dconf; get existing profiles by: `dconf dump /org/gnome/terminal/legacy/profiles:/`
TerminalLightProfile="3dd28c15-6ba4-4ba0-8289-ab023e6c88fc" # Theme is stored in dconf; get existing profiles by: `dconf dump /org/gnome/terminal/legacy/profiles:/`
alias tl="gsettings set org.gnome.desktop.interface color-scheme 'prefer-light'  && gsettings set "${Gsetting}" default "${TerminalLightProfile}""
alias td="gsettings set org.gnome.desktop.interface color-scheme 'prefer-dark'  && gsettings set "${Gsetting}" default "${TerminalDarkProfile}""

So why alias works but not function or separate bashscript?

yvs2014 · March 26, 2024, 5:57pm

Maybe if gsettings are handled asynchronously and a mounted resource extremly slow or broken, a result can depend on order of operations and so on. I’d try to test out that with double sync between set/get.

lamyergeier · March 26, 2024, 6:11pm

Could you please give the commands to execute for double sync? I am not sure what you mean as it doesn’t happen even after several minutes. I am using latest laptop with Gen 4 SSD and plenty of RAM (32 GB).

yvs2014 · March 26, 2024, 7:10pm

give the commands to execute for double sync

blablablacommand1; sync; sync; blablablacommand2

latest laptop with Gen 4 SSD

That was about /mnt/Data/.config… Is that resource on “latest laptop” or network resource somewhere? If that’s a remote resource, try to reproduce it with data on your local computer.

lamyergeier · March 26, 2024, 7:56pm

That resource is in same SSD, in a different logical volume but same volume group (LVM).

I did the following

#!/usr/bin/env bash
#set -xv
#echo "$DBUS_SESSION_BUS_ADDRESS"
#whoami
#gsettings set org.gnome.desktop.interface color-scheme 'prefer-dark'
gsettings set org.gnome.desktop.interface color-scheme 'prefer-light'
sync
sync
gsettings get org.gnome.desktop.interface color-scheme

Same issue as before, no change!

yvs2014 · March 26, 2024, 8:53pm

gsettings set org.gnome.desktop.interface color-scheme 'prefer-light'
sync
sync
gsettings get org.gnome.desktop.interface color-scheme

i.e. it displays ‘prefer-dark’ here, right?
Have you tested it with not mounted resource?

lamyergeier · March 26, 2024, 9:01pm

it displays ‘prefer-light’ (which is consistent with the original post) but the color theme doesn’t changes as mentioned in the original post.

But when executed directly in the terminal or with an alias (defined in ~/.bashrc) as described above, the color scheme actually changes.

yvs2014 · March 26, 2024, 9:10pm

If it’s not connected with asynchronous operations, then remained cause it’s different shell environment inside of script and outside. For example different XDG_CONFIG_HOME and/or DCONF_PROFILE. You can echo them inside and out of script to test it out. If not, I have no more suggestions what that is.

lamyergeier · March 27, 2024, 2:03pm

$ echo $XDG_CONFIG_HOME 

$ echo $DCONF_PROFILE

nbenitez · March 30, 2024, 12:31am

Being Fedora, be sure SELinux is not blocking your operation, more info in this link:

lamyergeier · April 1, 2024, 5:56pm

I ran the bash script and checked the audio daemon status and queried the Audit logs (here I show, the difference of log immediately after executing the bash script and immediately before executing the bash script from cwd: /mnt/Documents/Git/Project/Debug/Theme)

I am inexperienced but I don’t think there is a SELinux denial as per the logs. Am I correct?

$ bash ./Theme.sh 
'prefer-light'
$ gsettings get org.gnome.desktop.interface color-scheme
'prefer-dark'

$ sudo ausearch  -ts recent
time->Mon Apr  1 19:53:10 2024
type=USER_ACCT msg=audit(1711993990.288:11522): pid=177559 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="lamy" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/2 res=success'
----
time->Mon Apr  1 19:53:10 2024
type=USER_CMD msg=audit(1711993990.289:11523): pid=177559 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='cwd="/mnt/Documents/Git/Project/Debug/Theme" cmd=6175736561726368202D747320726563656E74 exe="/usr/bin/sudo" terminal=pts/2 res=success'
----
time->Mon Apr  1 19:53:10 2024
type=CRED_REFR msg=audit(1711993990.289:11524): pid=177559 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/2 res=success'
----
time->Mon Apr  1 19:53:10 2024
type=USER_START msg=audit(1711993990.293:11525): pid=177559 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/2 res=success'

$ systemctl status auditd.service 
● auditd.service - Security Auditing Service
     Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Tue 2024-03-26 09:35:34 CET; 6 days ago
       Docs: man:auditd(8)
             https://github.com/linux-audit/audit-documentation
   Main PID: 1206 (auditd)
      Tasks: 2 (limit: 38105)
     Memory: 1.5M
        CPU: 1.404s
     CGroup: /system.slice/auditd.service
             └─1206 /sbin/auditd

2024-03-26T09:35:34+0100 lamyer systemd[1]: Starting auditd.service - Security Auditing Service...
2024-03-26T09:35:34+0100 lamyer auditd[1206]: No plugins found, not dispatching events
2024-03-26T09:35:34+0100 lamyer auditd[1206]: Init complete, auditd 3.1.2 listening for events (startup state enable)
2024-03-26T09:35:34+0100 lamyer augenrules[1209]: /sbin/augenrules: No change
2024-03-26T09:35:34+0100 lamyer augenrules[1220]: No rules
2024-03-26T09:35:34+0100 lamyer systemd[1]: Started auditd.service - Security Auditing Service.

system · May 16, 2024, 5:56pm

This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.