You are not logged in.
I'm currently trying to set up a nice email workflow with mbsync, msmtp and notmuch.
My passwords are saved in the Gnome keyring "login", and I've configured mbsync to use secret-tool to retrieve them. Unfortunately when secret-tool is invoked from this systemd user service there is an error when it in turn tries to call dbus-launch.
Here is the error:
$ systemctl --user status -l mbsync.service
● mbsync.service - Synchronise IMAP folders
Loaded: loaded (/home/leo/.config/systemd/user/mbsync.service; static; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2015-05-10 20:10:56 BST; 17min ago
Process: 3691 ExecStart=/usr/bin/mbsync -a (code=exited, status=1/FAILURE)
Main PID: 3691 (code=exited, status=1/FAILURE)
May 10 20:10:55 think3 mbsync[3691]: (secret-tool:3696): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
May 10 20:10:55 think3 mbsync[3691]: secret-tool: Error spawning command line 'dbus-launch --autolaunch=388eb9d3cc5542d5922d60c8f9605b31 --binary-syntax --close-stderr': Child process exited with code 1
May 10 20:10:55 think3 mbsync[3691]: Skipping account ymail, password command exited with status 1
May 10 20:10:56 think3 mbsync[3691]: (secret-tool:3698): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
May 10 20:10:56 think3 mbsync[3691]: secret-tool: Error spawning command line 'dbus-launch --autolaunch=388eb9d3cc5542d5922d60c8f9605b31 --binary-syntax --close-stderr': Child process exited with code 1
May 10 20:10:56 think3 mbsync[3691]: Skipping account gmail, password command exited with status 1
May 10 20:10:56 think3 systemd[716]: mbsync.service: main process exited, code=exited, status=1/FAILURE
May 10 20:10:56 think3 systemd[716]: Failed to start Synchronise IMAP folders.
May 10 20:10:56 think3 systemd[716]: Unit mbsync.service entered failed state.
May 10 20:10:56 think3 systemd[716]: mbsync.service failed.The file mbsync.service is simply
[Unit]
Description=Synchronise IMAP folders
Wants=network-online.target
After=network-online.target
[Service]
Type=oneshot
ExecStart=/usr/bin/mbsync -aAny ideas how I can use secret-tool from within a systemd user service? The Wiki includes some information about DBus and systemd here but it looks a little outdated...
Last edited by curiousleo (2015-05-22 22:02:33)
Offline
Just after you log in as a user and into your graphical environment, post the output of:
$ systemd-cgls
And verify that '--autolaunch=388eb9d3cc5542d5922d60c8f9605b31' is really your machine id in /etc/machine-id.
Offline
Just after you log in as a user and into your graphical environment, post the output of:
$ systemd-cgls
Here it is: (rather long, but I can't tell what's important ...)
├─1 /sbin/init
├─system.slice
│ ├─dbus.service
│ │ └─284 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
│ ├─wpa_supplicant.service
│ │ └─537 /usr/bin/wpa_supplicant -u
│ ├─system-netctl\x2dauto.slice
│ │ └─netctl-auto@wlp3s0.service
│ │ ├─415 wpa_supplicant -B -P /run/wpa_supplicant_wlp3s0.pid -i wlp3s0 -D nl80211,wext -c/run/network/wpa_supplicant_wlp3s0.conf -W
│ │ ├─417 wpa_actiond -p /run/wpa_supplicant -i wlp3s0 -P /run/network/wpa_actiond_wlp3s0.pid -a /usr/lib/network/auto.action
│ │ └─668 dhcpcd -4 -q -t 30 -K -L wlp3s0
│ ├─accounts-daemon.service
│ │ └─424 /usr/lib/accountsservice/accounts-daemon
│ ├─colord.service
│ │ └─583 /usr/lib/colord/colord
│ ├─systemd-journald.service
│ │ └─155 /usr/lib/systemd/systemd-journald
│ ├─udisks2.service
│ │ └─568 /usr/lib/udisks2/udisksd --no-debug
│ ├─upower.service
│ │ └─467 /usr/lib/upower/upowerd
│ ├─systemd-timesyncd.service
│ │ └─280 /usr/lib/systemd/systemd-timesyncd
│ ├─packagekit.service
│ │ └─538 /usr/lib/PackageKit/packagekitd
│ ├─systemd-logind.service
│ │ └─286 /usr/lib/systemd/systemd-logind
│ ├─systemd-udevd.service
│ │ └─185 /usr/lib/systemd/systemd-udevd
│ ├─polkit.service
│ │ └─431 /usr/lib/polkit-1/polkitd --no-debug
│ ├─gdm.service
│ │ └─392 /usr/bin/gdm
│ ├─system-netctl\x2difplugd.slice
│ │ └─netctl-ifplugd@enp0s25.service
│ │ ├─ 290 /usr/bin/ifplugd -i enp0s25 -r /etc/ifplugd/netctl.action -bfIns
│ │ └─1141 dhcpcd -4 -q -t 30 -L enp0s25
│ ├─geoclue.service
│ │ └─755 /usr/lib/geoclue2/geoclue -t 5
│ └─rtkit-daemon.service
│ └─518 /usr/lib/rtkit/rtkit-daemon
└─user.slice
├─user-1000.slice
│ ├─user@1000.service
│ │ ├─670 /usr/lib/systemd/systemd --user
│ │ └─671 (sd-pam)
│ └─session-c2.scope
│ ├─ 620 gdm-session-worker [pam/gdm-password]
│ ├─ 675 /usr/bin/gnome-keyring-daemon --daemonize --login
│ ├─ 678 /usr/lib/gdm/gdm-x-session --run-script gnome-session
│ ├─ 680 /usr/lib/xorg-server/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -verbose 3
│ ├─ 682 xf86-video-intel-backlight-helper intel_backlight
│ ├─ 685 dbus-daemon --print-address 4 --session
│ ├─ 687 gnome-session
│ ├─ 697 /usr/bin/ssh-agent -- gnome-session
│ ├─ 700 /usr/lib/at-spi2-core/at-spi-bus-launcher
│ ├─ 703 /usr/bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3
│ ├─ 706 /usr/lib/at-spi2-core/at-spi2-registryd --use-gnome-session
│ ├─ 713 /usr/lib/gnome-settings-daemon/gnome-settings-daemon
│ ├─ 730 /usr/bin/pulseaudio --start --log-target=syslog
│ ├─ 733 /usr/lib/gvfs/gvfsd
│ ├─ 737 /usr/lib/gvfs/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes
│ ├─ 750 /usr/lib/pulse/gconf-helper
│ ├─ 752 /usr/lib/GConf/gconfd-2
│ ├─ 754 /usr/bin/gnome-shell
│ ├─ 758 syndaemon -i 1.0 -t -K -R
│ ├─ 761 /usr/lib/gnome-settings-daemon/gsd-printer
│ ├─ 777 /usr/lib/telepathy/mission-control-5
│ ├─ 779 /usr/lib/gvfs/gvfs-udisks2-volume-monitor
│ ├─ 789 /usr/lib/deja-dup/deja-dup/deja-dup-monitor
│ ├─ 790 /usr/bin/python3 /usr/share/system-config-printer/applet.py
│ ├─ 798 /usr/lib/dconf/dconf-service
│ ├─1069 /usr/lib/gvfs/gvfsd-metadata
│ ├─1194 gjs /home/leo/.local/share/gnome-shell/extensions/drop-down-terminal@gs-extensions.zzrough.org/terminal.js /home/leo/.local/share/gnome-shell/extensions/drop-down-terminal@gs-extensions.zzrough.org
│ ├─1199 gnome-pty-helper
│ ├─1200 tmux attach -t dropdown
│ ├─1203 tmux attach -t dropdown
│ ├─1204 -zsh
│ └─1324 systemd-cgls -l
└─user-120.slice
├─session-c1.scope
│ ├─439 gdm-session-worker [pam/gdm-launch-environment]
│ ├─448 /usr/lib/gdm/gdm-wayland-session /usr/bin/gnome-session --autostart /usr/share/gdm/greeter/autostart --session gnome-wayland
│ ├─450 dbus-daemon --print-address 3 --session
│ ├─451 /usr/bin/gnome-session --autostart /usr/share/gdm/greeter/autostart --session gnome-wayland
│ ├─457 gnome-shell --mode=gdm --wayland --display-server
│ ├─462 /usr/lib/gvfs/gvfsd
│ ├─466 /usr/lib/gvfs/gvfsd-fuse /run/user/120/gvfs -f -o big_writes
│ ├─499 /usr/bin/Xwayland :1024 -rootless -noreset -listen 4 -listen 5 -displayfd 6
│ ├─506 /usr/lib/at-spi2-core/at-spi-bus-launcher
│ ├─509 /usr/bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3
│ ├─512 /usr/lib/at-spi2-core/at-spi2-registryd --use-gnome-session
│ ├─517 /usr/bin/pulseaudio --start --log-target=syslog
│ ├─524 /usr/lib/pulse/gconf-helper
│ ├─526 /usr/lib/GConf/gconfd-2
│ ├─539 /usr/lib/gnome-settings-daemon/gnome-settings-daemon
│ └─566 /usr/lib/gvfs/gvfs-udisks2-volume-monitor
└─user@120.service
├─445 /usr/lib/systemd/systemd --user
└─446 (sd-pam) And verify that '--autolaunch=388eb9d3cc5542d5922d60c8f9605b31' is really your machine id in /etc/machine-id.
Yes, /etc/machine-id contains that exact hex string.
Last edited by curiousleo (2015-05-11 18:06:24)
Offline
It would have been better to provide a not ellipsized output (with the --full option).
But can you use secret-tool manually from a user terminal prompt?
Can you confirm that the user 120 is gdm? (I don't use Gnome DE)
Offline
It would have been better to provide a not ellipsized output (with the --full option).
Of course. I've updated the listing in my previous answer.
But can you use secret-tool manually from a user terminal prompt?
Yes, it works -- without having to enter a password since they're all stored in the "login" keyring.
Can you confirm that the user 120 is gdm? (I don't use Gnome DE)
Yes, according to /etc/passwd.
Offline
So when you run secret-tool inside the 'session-c2.scope', all is well.
But when you use a service inside 'systemd --user', it is run outside the 'session-c2.scope':
│ └─518 /usr/lib/rtkit/rtkit-daemon
└─user.slice
├─user-1000.slice
│ ├─user@1000.service
│ │ ├─670 /usr/lib/systemd/systemd --user
│ │ ├─671 (sd-pam)
│ │ ├─xxx <------------------------------------------------------your service will run here
│ └─session-c2.scope
│ ├─ 620 gdm-session-worker [pam/gdm-password]
│ ├─ 675 /usr/bin/gnome-keyring-daemon --daemonize --loginThat's why it has no access to the gnome dbus session inside the 'session-c2.scope'.
Any ideas how I can use secret-tool from within a systemd user service? The Wiki includes some information about DBus and systemd here but it looks a little outdated...
I don't know if following the wiki about creating a D-Bus user message bus for the 'systemd --user' daemon will work in this case.
Did you try it? It is not yet obsolete because kernel kdbus is not yet operational, if I understand correctly.
You could try this first; I will try to search if it's possible to access the gnome dbus session from 'systemd --user'...
Offline
Thanks for the pointer! I'm starting to suspect that my problem may have something to do with the fact that `gnome-keyring-daemon` (which is used by `secret-tool` to actually retrieve the key) is running in a different context than my user services. So I may need to fire up my own instance of the keyring daemon... I'll give that a try later.
└─user.slice
├─user-1000.slice
│ ├─user@1000.service
│ │ ├─670 /usr/lib/systemd/systemd --user
│ │ ├─671 (sd-pam)
│ │ └─... <-- mbsync user service
│ └─session-c2.scope
│ ├─ 620 gdm-session-worker [pam/gdm-password]
│ ├─ 675 /usr/bin/gnome-keyring-daemon --daemonize --login <-- here is my key!Offline
When 'secret-tool' is run inside 'systemd --user', it doesn't find a set 'DBUS_SESSION_BUS_ADDRESS' variable;
the one set in the gnome session is not directly accessible.
So it tries to start up a new session bus, but fails with this error:
secret-tool: Error spawning command line 'dbus-launch --autolaunch=<machine-id>
Reading 'man dbus-launch', I noticed:
If DBUS_SESSION_BUS_ADDRESS is not set for a process that tries to use D-Bus, by default the process will attempt
to invoke dbus-launch with the --autolaunch option to start up a new session bus
or find the existing bus address on the X display or in a file in ~/.dbus/session-bus/
I looked into the file in ~/.dbus/session-bus/, and it is written there:
# This file allows processes on the machine with id <machine-id> using
# display :0 to find the D-Bus session bus with the below address.
# If the DBUS_SESSION_BUS_ADDRESS environment variable is set, it will
# be used rather than this file.
# See "man dbus-launch" for more details.
...
So I wonder if giving the display in the 'mbsync.service' would be enough to find the gnome dbus session.
You could try to edit the service to:
[Unit]
Description=Synchronise IMAP folders
#Wants=network-online.target
#After=network-online.target
[Service]
Type=oneshot
Environment=DISPLAY=:0
ExecStart=/usr/bin/mbsync -aThe 'Wants=', 'After=' are useless here, because 'network-online.target' is started in the 'systemd --system' daemon.
And write the good DISPLAY value, if it is not ':0'.
I have not tried that, so I don't know if it will work; but you can test it, it's easy to try.
Last edited by berbae (2015-05-13 10:26:40)
Offline
Thanks berbae for your suggestions! Starting from adding the DISPLAY variable to the environment of mbsync, I dug a little deeper.
I found that the value of $DBUS_SESSION_BUS_ADDRESS in my terminal differed from the value given in /.dbus/session-bus/<machine-id>. As I understand it, the user service used the one from the file, but the keyring daemon could only be reached via the one in my terminal's environment.
My fix was to add
systemctl --user import-environment DBUS_SESSION_BUS_ADDRESSto ~/.profile. Now the systemd user service can talk to the dbus instance started for the session, and key retrieval works.
The explanation is definitely incomplete and maybe wrong, but that's my understanding of what is going on at this point.
So one little thing before I mark this closed:
Is ~/.profile the right file to put this command in? (It works, but is there some other standard location for this kind of thing?)
Last edited by curiousleo (2015-05-13 13:59:27)
Offline
I don't know when the .login file you're speaking about is executed and by what?
I am not in gdm/gnome.
How are you sure that the right 'DBUS_SESSION_BUS_ADDRESS' variable is set when .login is run?
I am not familiar with how gdm does the user logging under systemd.
I search another way to pass the 'DBUS_SESSION_BUS_ADDRESS' variable to the 'systemd --user' process.
But the difficulty is to be sure the variable is set before using a method to send its value to 'systemd --user' environment.
Is the exported variable, the same variable or just a copy into a new variable of the same name?
If it is the same variable (not a copy), then the command can be executed before the variable is set;
if not, it is necessary to be sure the original variable is set before copying it.
Edit:
After doing some tests, I found that the exported variable, for example by 'systemctl --user import-environment'
is a copy of the original, with the same name;
so it is necessary the right 'DBUS_SESSION_BUS_ADDRESS' variable be set before exporting it.
Last edited by berbae (2015-05-15 14:57:06)
Offline
The synchronisation of the exporting of the right 'DBUS_SESSION_BUS_ADDRESS' variable into 'systemd --user' environment,
and the start of the user service which needs this dbus access, is the main point of the problem of 'how to do the export'.
Could you explain please why you chose the '~/.login' file?
Because this may work, only by chance.
As your service only run one command, maybe using 'systemd-run' at the right time and with the variable in the '--setenv=' option
might be a more reliable way to get the result you want:
systemd-run --user --unit=mbsync --setenv=DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS /usr/bin/mbsync -a
This command should be run after the 'gnome-keyring-daemon' has started with the dbus session it uses.
If you really want a service file, I can suggest something else, but I'd prefer hearing from you about the '~/.login' choice before going on.
Thanks to provide feedbacks.
Offline
I don't know when the .login file you're speaking about is executed and by what?
The file name is `$HOME/.profile`. I honestly don't know when or by which program it is actually executed. This post suggests using .profile to set up things for systemd user services. It does not explain why it works though.
After doing some tests, I found that the exported variable, for example by 'systemctl --user import-environment'
is a copy of the original, with the same name;
so it is necessary the right 'DBUS_SESSION_BUS_ADDRESS' variable be set before exporting it.
Yes, that's right: the value of DBUS_SESSION_BUS_ADDRESS must have been set before the import-environment is executed. Again, I don't really understand when and by which program this environment variable is set.
So in short, for now things work they way they are supposed to (somehow DBUS_SESSION_BUS_ADDRESS is set and somehow some time after that my .profile is sourced) but I don't know why.
I still want to run this as a systemd user service because I want to use systemd's timer feature to run it in specified time intervals.
Offline
The thread you mentioned is almost 2 years old.
In the msthev's post #86, it happened that msthev used ~/.login to start X, it was his configuration, not a general rule;
at this time 'systemd --user' needed to be started; today it is automatically started at login.
Even him found that his way was 'inelegant'.
I think that this thread has many outdated infos.
So in your case, it's just by chance that what you've done works.
It just happens that the '~/.login' is run (probably by gdm, but not sure)
and the command in it is executed after the 'DBUS_SESSION_BUS_ADDRESS' variable is set with the right value.
I don't find that this is a good solution to this problem.
Nothing warrants that it will always work, because you don't control the synchronization.
And I think it's better to understand what we do, and not stop at 'it just works, I don't know why'.
It's how I see things about problems solving; it's my opinion.
The 'systemd-run' command can use a transient timer too, and the command is run as a transient service in the 'systemd --user' process.
But we can choose when it is run, at the right time.
With your way, how are you sure the service will always starts after the needed environment is set?
For me the good solution is to be sure the environment is set before the service is started. I don't think your solution can guarantee this.
Last edited by berbae (2015-05-15 22:01:46)
Offline
So in your case, it's just by chance that what you've done works.
You're right. My "solution" is pretty fragile and could just stop working at some point for reasons out of my control.
`systemd-run` may do the trick. I would like the command which starts the timer to run automatically when I log in. How would I do that?
Offline
For using 'systemd-run' with a transient timer, it is documented in 'man systemd-run'.
For example, to run the command 1min after 'systemd --user' started, and then every 30min:
systemd-run --user --on-startup=1min --on-calendar='*:0/30' --timer-property=AccuracySec=100ms --setenv=DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS /usr/bin/mbsync -aAs to 'how to run this command', I would like to see the gnome startup sequence on your machine;
so please could you post the output of 'journalctl -b' just after user login into gnome through gdm?
I would like to see when the 'systemd --user' process is started in the gnome session startup sequence.
Thanks.
Offline
Please could you post the output of 'journalctl -b' just after user login into gnome through gdm?
Sure thing. Here it is (I've cut out some stuff that obviously had nothing to do with the problem at hand):
May 17 17:17:11 think3 systemd[1]: systemd 219 running in system mode. (+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD +IDN)
May 17 17:17:11 think3 systemd[1]: Created slice Root Slice.
May 17 17:17:11 think3 systemd[1]: Starting Root Slice.
May 17 17:17:11 think3 systemd[1]: Created slice System Slice.
May 17 17:17:11 think3 systemd[1]: Starting System Slice.
May 17 17:17:11 think3 systemd[1]: Started Forward Password Requests to Wall Directory Watch.
May 17 17:17:11 think3 systemd[1]: Starting Forward Password Requests to Wall Directory Watch.
May 17 17:17:11 think3 systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
May 17 17:17:11 think3 systemd[1]: Starting Dispatch Password Requests to Console Directory Watch.
May 17 17:17:11 think3 systemd[1]: Reached target Login Prompts.
May 17 17:17:11 think3 systemd[1]: Starting Login Prompts.
May 17 17:17:11 think3 systemd[1]: Created slice User and Session Slice.
May 17 17:17:11 think3 systemd[1]: Starting User and Session Slice.
May 17 17:17:11 think3 systemd[1]: Reached target Slices.
May 17 17:17:11 think3 systemd[1]: Starting Slices.
May 17 17:17:11 think3 systemd[1]: Started Create System Users.
May 17 17:17:11 think3 systemd[1]: Created slice system-systemd\x2drfkill.slice.
May 17 17:17:11 think3 systemd[1]: Starting system-systemd\x2drfkill.slice.
May 17 17:17:11 think3 systemd[1]: Started Commit a transient machine-id on disk.
May 17 17:17:11 think3 systemd[1]: Started Daily verification of password and group files.
May 17 17:17:11 think3 systemd[1]: Starting Daily verification of password and group files.
May 17 17:17:11 think3 systemd[1]: Listening on D-Bus System Message Bus Socket.
May 17 17:17:11 think3 systemd[1]: Starting D-Bus System Message Bus Socket.
May 17 17:17:11 think3 systemd[1]: Reached target Sockets.
May 17 17:17:11 think3 systemd[1]: Starting Sockets.
May 17 17:17:11 think3 systemd[1]: Reached target Basic System.
May 17 17:17:11 think3 systemd[1]: Starting Basic System.
May 17 17:17:11 think3 systemd[1]: Starting Login Service...
May 17 17:17:11 think3 systemd[1]: Starting Permit User Sessions...
May 17 17:17:11 think3 systemd[1]: Started D-Bus System Message Bus.
May 17 17:17:11 think3 systemd[1]: Starting D-Bus System Message Bus...
May 17 17:17:11 think3 systemd[1]: Reached target Timers.
May 17 17:17:11 think3 systemd[1]: Starting Timers.
May 17 17:17:11 think3 systemd[1]: Started Permit User Sessions.
May 17 17:17:11 think3 systemd[1]: Starting GNOME Display Manager...
May 17 17:17:11 think3 systemd[1]: Started Login Service.
May 17 17:17:12 think3 systemd[1]: Started GNOME Display Manager.
May 17 17:17:12 think3 systemd[1]: Reached target Multi-User System.
May 17 17:17:12 think3 systemd[1]: Starting Multi-User System.
May 17 17:17:12 think3 systemd[1]: Reached target Graphical Interface.
May 17 17:17:12 think3 systemd[1]: Starting Graphical Interface.
May 17 17:17:12 think3 systemd-logind[293]: New seat seat0.
May 17 17:17:12 think3 dbus[301]: [system] Activating via systemd: service name='org.freedesktop.Accounts' unit='accounts-daemon.service'
May 17 17:17:12 think3 systemd[1]: Reached target User and Group Name Lookups.
May 17 17:17:12 think3 systemd[1]: Starting User and Group Name Lookups.
May 17 17:17:12 think3 systemd[1]: Starting Accounts Service...
May 17 17:17:13 think3 dbus[301]: [system] Activating via systemd: service name='org.freedesktop.PolicyKit1' unit='polkit.service'
May 17 17:17:13 think3 systemd[1]: Starting Authorization Manager...
May 17 17:17:13 think3 polkitd[443]: Started polkitd version 0.112
May 17 17:17:13 think3 polkitd[443]: Loading rules from directory /etc/polkit-1/rules.d
May 17 17:17:13 think3 polkitd[443]: Loading rules from directory /usr/share/polkit-1/rules.d
May 17 17:17:13 think3 polkitd[443]: Finished loading, compiling and executing 3 rules
May 17 17:17:13 think3 dbus[301]: [system] Successfully activated service 'org.freedesktop.PolicyKit1'
May 17 17:17:13 think3 polkitd[443]: Acquired the name org.freedesktop.PolicyKit1 on the system bus
May 17 17:17:13 think3 systemd[1]: Started Authorization Manager.
May 17 17:17:13 think3 accounts-daemon[436]: started daemon version 0.6.40
May 17 17:17:13 think3 dbus[301]: [system] Successfully activated service 'org.freedesktop.Accounts'
May 17 17:17:13 think3 systemd[1]: Started Accounts Service.
May 17 17:17:13 think3 systemd[1]: Created slice user-120.slice.
May 17 17:17:13 think3 systemd[1]: Starting user-120.slice.
May 17 17:17:13 think3 systemd[1]: Starting User Manager for UID 120...
May 17 17:17:13 think3 systemd-logind[293]: New session c1 of user gdm.
May 17 17:17:13 think3 systemd[1]: Started Session c1 of user gdm.
May 17 17:17:13 think3 systemd[1]: Starting Session c1 of user gdm.
May 17 17:17:13 think3 systemd[454]: pam_unix(systemd-user:session): session opened for user gdm by (uid=0)
May 17 17:17:13 think3 systemd[454]: Unit type .busname is not supported on this system.
May 17 17:17:13 think3 systemd[454]: Reached target Paths.
May 17 17:17:13 think3 systemd[454]: Starting Paths.
May 17 17:17:13 think3 systemd[454]: Reached target Timers.
May 17 17:17:13 think3 systemd[454]: Starting Timers.
May 17 17:17:13 think3 systemd[454]: Reached target Sockets.
May 17 17:17:13 think3 systemd[454]: Starting Sockets.
May 17 17:17:13 think3 systemd[454]: Reached target Basic System.
May 17 17:17:13 think3 systemd[454]: Starting Basic System.
May 17 17:17:13 think3 systemd[454]: Reached target Default.
May 17 17:17:13 think3 systemd[454]: Startup finished in 3ms.
May 17 17:17:13 think3 systemd[454]: Starting Default.
May 17 17:17:13 think3 systemd[1]: Started User Manager for UID 120.
May 17 17:17:13 think3 gnome-session[460]: glamor: EGL version 1.4 (DRI2):
May 17 17:17:13 think3 org.a11y.Bus[459]: Activating service name='org.a11y.atspi.Registry'
May 17 17:17:13 think3 org.a11y.Bus[459]: Successfully activated service 'org.a11y.atspi.Registry'
May 17 17:17:13 think3 org.a11y.atspi.Registry[518]: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry
May 17 17:17:14 think3 polkitd[443]: Registered Authentication Agent for unix-session:c1 (system bus name :1.9 [gnome-shell --mode=gdm --wayland --display-server], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_GB.utf8)
May 17 17:17:18 think3 gdm-password][674]: pam_unix(gdm-password:session): session opened for user leo by (uid=0)
May 17 17:17:18 think3 systemd[1]: Created slice user-1000.slice.
May 17 17:17:18 think3 systemd[1]: Starting user-1000.slice.
May 17 17:17:18 think3 systemd[1]: Starting User Manager for UID 1000...
May 17 17:17:18 think3 systemd[1]: Started Session c2 of user leo.
May 17 17:17:18 think3 systemd-logind[293]: New session c2 of user leo.
May 17 17:17:18 think3 systemd[1]: Starting Session c2 of user leo.
May 17 17:17:18 think3 systemd[717]: pam_unix(systemd-user:session): session opened for user leo by (uid=0)
May 17 17:17:18 think3 systemd[717]: Unit type .busname is not supported on this system.
May 17 17:17:18 think3 systemd[717]: Started Synchronise e-mails and create database dump once a day.
May 17 17:17:18 think3 systemd[717]: Starting Synchronise e-mails and create database dump once a day.
May 17 17:17:18 think3 systemd[717]: Reached target default.target.
May 17 17:17:18 think3 systemd[717]: Startup finished in 13ms.
May 17 17:17:18 think3 systemd[717]: Starting default.target.
May 17 17:17:18 think3 /usr/lib/gdm/gdm-x-session[725]: /etc/gdm/Xsession: Beginning session setup...
May 17 17:17:18 think3 /usr/lib/gdm/gdm-x-session[725]: localuser:leo being added to access control list
May 17 17:17:18 think3 /usr/lib/gdm/gdm-x-session[725]: /etc/gdm/Xsession: Setup done, will execute: /usr/bin/ssh-agent -- gnome-session
May 17 17:17:18 think3 /usr/lib/gdm/gdm-x-session[725]: Activating service name='org.a11y.Bus'
May 17 17:17:19 think3 /usr/lib/gdm/gdm-x-session[725]: Successfully activated service 'org.a11y.Bus'
May 17 17:17:19 think3 org.a11y.Bus[732]: Activating service name='org.a11y.atspi.Registry'
May 17 17:17:19 think3 org.a11y.Bus[732]: Successfully activated service 'org.a11y.atspi.Registry'
May 17 17:17:19 think3 org.a11y.atspi.Registry[756]: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry
May 17 17:17:19 think3 gnome-session[734]: SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
May 17 17:17:19 think3 gnome-session[734]: SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
May 17 17:17:19 think3 gnome-session[734]: GPG_AGENT_INFO=/run/user/1000/keyring/gpg:0:1
May 17 17:17:20 think3 polkitd[443]: Registered Authentication Agent for unix-session:c2 (system bus name :1.43 [/usr/bin/gnome-shell], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_GB.utf8)
May 17 17:17:20 think3 gnome-session[734]: Entering running state
May 17 17:17:21 think3 gnome-shell[804]: GNOME Shell started at Sun May 17 2015 17:17:20 GMT+0100 (BST)
May 17 17:17:52 think3 /usr/lib/gdm/gdm-x-session[725]: Activating service name='org.gnome.seahorse.Application'
May 17 17:17:52 think3 /usr/lib/gdm/gdm-x-session[725]: Successfully activated service 'org.gnome.seahorse.Application'
May 17 17:20:48 think3 /usr/lib/gdm/gdm-x-session[725]: Activating service name='org.gnome.seahorse.Application'
May 17 17:20:48 think3 /usr/lib/gdm/gdm-x-session[725]: Successfully activated service 'org.gnome.seahorse.Application'Offline
From looking at the gnome session startup sequence after user login in gdm, I see that 'systemd --user' is started early in this sequence;
and apparently so is the 'gnome-keyring-daemon'.
After that you have:
May 17 17:17:18 think3 /usr/lib/gdm/gdm-x-session[725]: /etc/gdm/Xsession: Beginning session setup...
...
May 17 17:17:18 think3 /usr/lib/gdm/gdm-x-session[725]: /etc/gdm/Xsession: Setup done, will execute: /usr/bin/ssh-agent -- gnome-sessionThis script is like the '~/.xinitrc' but for gdm.
Between the 2 messages above, the 'dbus-launch' command is run by these lines:
# run all system xinitrc shell scripts.
if [ -d /etc/X11/xinit/xinitrc.d ]; then
for i in /etc/X11/xinit/xinitrc.d/* ; do
if [ -x "$i" -a ! -d "$i" ]; then
. "$i"
fi
done
fiwhere there is the '30-dbus.sh' script which set the 'DBUS_SESSION_BUS_ADDRESS' variable for the session.
So I propose this way of running the 'systemd-run' command:
1) write a script '$HOME/run-mbsync.sh' like that:
#!/bin/bash
if systemctl --user --quiet is-system-running; then
echo "$0: Starting mbsync in systemd user manager"
systemd-run --user --on-active=1min --on-calendar='*:0/30' --timer-property=AccuracySec=100ms \
--unit=mbsync --description="A nice email workflow manager" \
--setenv="DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS" /usr/bin/mbsync -a
else
echo "$0: systemd user manager not running"
fiChange the timer parameters to your choices.
2) Then edit the '/etc/gdm/Xsession' script like that:
$ diff -U 10 Xsession.ori Xsession
--- Xsession.ori 2015-04-16 22:12:17.000000000 +0200
+++ Xsession 2015-05-19 11:11:09.852034794 +0200
@@ -150,20 +150,28 @@
# run all system xinitrc shell scripts.
if [ -d /etc/X11/xinit/xinitrc.d ]; then
for i in /etc/X11/xinit/xinitrc.d/* ; do
if [ -x "$i" -a ! -d "$i" ]; then
. "$i"
fi
done
fi
+if [ "x$command" = "xgnome-session" ] ; then
+ if [ -x "$HOME/run-mbsync.sh" ]; then
+ $HOME/run-mbsync.sh
+ else
+ echo "$0: Cannot find ~/run-mbsysnc.sh"
+ fi
+fi
+
if [ "x$command" = "xcustom" ] ; then
if [ -x "$HOME/.xsession" ]; then
command="$HOME/.xsession"
else
echo "$0: Cannot find ~/.xsession will try the default session"
command="default"
fi
fiThis file will be preserved by pacman when updating the gdm package.
Of course you can edit choices I made to your convenience.
I cannot test it here, because I don't use the same graphical environment as you do.
So it's just a suggestion that suppresses the chance parameter, I think.
That's only one possibility, some other ways could be found also.
Last edited by berbae (2015-05-19 10:04:11)
Offline
Nice detective work! It seems like /etc/gdm/Xsession is the key to setting up my keyrings properly.
I wasn't entirely happy with the solution you suggested: basically, I want my setup to be "backupable" and keep the structure as obvious as possible. In your solution you created a file "run-mbsync.sh" which essentially defines both a systemd timer and a service. I would prefer systemd services to be in .config/systemd/XYZ.service and timers to be in .config/systemd/XYZ.timer.
So here is what I came up with: I inserted the conditional execution into /etc/gdm/Xsession as you suggested. But instead of $HOME/run-mbsync.sh, it calls $HOME/.xgnome-session, a file with the following contents:
!/bin/sh
systemctl --user import-environment DBUS_SESSION_BUS_ADDRESS
systemctl --user start dbus.targetIt imports the bus address into the scope of the systemd user session (which is okay since 30-dbus.sh has been executed at the point where this is sourced from /etc/gdm/Xsession) and then activates the user "dbus" target.
This target is just a file .config/systemd/user/dbus.target containing the line "[Unit]". I then linked to the mbsync timer from .config/systemd/user/dbus.target.wants, so the whole directory looks like this:
$ tree .config/systemd/user
.config/systemd/user
├── dbus.target
├── dbus.target.wants
│ └── mbsync.timer -> /home/leo/.config/systemd/user/mbsync.timer
├── mbsync.service
└── mbsync.timerNow as far as I can tell, this is what happens:
I log in with GDM, which sources /etc/gdm/Xsession
/etc/X11/xinit/xinitrc.d/30-dbus.sh get sourced, which sets the environment variable DBUS_SESSION_BUS_ADDRESS
$HOME/.xgnome-session gets sourced, which imports DBUS_SESSION_BUS_ADDRESS into the user's systemd scope and starts the target "dbus"
All the things "wanted" by the "dbus" target are started. In this case that's my mbsync timer.
At some point later, the mbsync timer starts the mbsync service. This service, in turn, uses secret-tool to retrieve my passwords. secret-tool can talk to my keyring daemon via dbus because the environment variable DBUS_SESSION_BUS_ADDRESS is set and retrieves my passwords without problems.
Unicorns and rainbows!
Last edited by curiousleo (2015-05-21 22:07:10)
Offline
I feel like I haven't made this clear enough: the solution presented in my last post is slightly more involved (creating the extra "dbus.target" file, the ".wants" directory and the symlink) but it's a more general solution to the problem "how can I make sure that my systemd user service can use dbus?".
I'll probably write more user systemd services in the future which will depend on dbus in some way. Now I will be able to just write the dbus-dependent .service or .timer file and then symlink it from dbus.target.wants, knowing that the environment is set up when this target is called.
Offline
I'm happy you found a convenient way to solve this dbus access problem inside the systemd user manager, and to have contributed to your solution.
You could tag this thread as solved now.
See you again here later, maybe.
Offline
Thanks again for your help!
Offline