Gsettings does not work from inside a script

Desktop
,
1

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

2

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)?

3

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'
4

This output looks correct. Is it not working?

5

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

6

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

7

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?

8

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.

9

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).

10

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.

11

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!

12

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?

13

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.

14

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.

15 
$ echo $XDG_CONFIG_HOME 

$ echo $DCONF_PROFILE
16

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

17

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.