[WORKAROUND] Start onboard as a dbus system service

schard · 2020-12-01 15:49:53

I am trying to run onboard as a dbus system service.
My first attempt was:

$ cat /etc/systemd/system/onboard.service 
[Unit]
Description=Onboard on-screen keyboard
After=kioskbrowser.service
Wants=xorg-server.service

[Service]
Type=dbus
BusName=org.onboard.Onboard
User=digsig
Group=digsig
Environment=DISPLAY=:0
ExecStartPre=/usr/bin/setxkbmap de
ExecStart=/usr/bin/onboard -a -l Phone
Restart=always
RestartSec=5

[Install]
WantedBy=graphical.target

Resulting in:

Dez 01 16:34:42 934 systemd[1]: Starting Onboard on-screen keyboard...
Dez 01 16:34:42 934 onboard[846]: 16:34:42.732 WARNING OnboardGtk: D-Bus session bus unavailable  Onboard will start with reduced functionality. Single-instance check, D-Bus service and hover click are disabled.
Dez 01 16:34:42 934 onboard[846]: 16:34:42.740 WARNING Config: mousetweaks GSettings schema not found, mousetweaks integration disabled.
Dez 01 16:34:42 934 onboard[846]: Traceback (most recent call last):
Dez 01 16:34:42 934 onboard[846]:   File "/usr/bin/onboard", line 36, in <module>
Dez 01 16:34:42 934 onboard[846]:     ob = Onboard()
Dez 01 16:34:42 934 onboard[846]:   File "/usr/lib/python3.8/site-packages/Onboard/OnboardGtk.py", line 148, in __init__
Dez 01 16:34:42 934 onboard[846]:     self.init()
Dez 01 16:34:42 934 onboard[846]:   File "/usr/lib/python3.8/site-packages/Onboard/OnboardGtk.py", line 189, in init
Dez 01 16:34:42 934 onboard[846]:     self._init_delayed()
Dez 01 16:34:42 934 onboard[846]:   File "/usr/lib/python3.8/site-packages/Onboard/OnboardGtk.py", line 270, in _init_delayed
Dez 01 16:34:42 934 onboard[846]:     self.service_keyboard = ServiceOnboardKeyboard(self)
Dez 01 16:34:42 934 onboard[846]:   File "/usr/lib/python3.8/site-packages/Onboard/OnboardGtk.py", line 854, in __init__
Dez 01 16:34:42 934 onboard[846]:     ServiceBase.__init__(self, dbus.SessionBus(), self.NAME, self.PATH)
Dez 01 16:34:42 934 onboard[846]:   File "/usr/lib/python3.8/site-packages/dbus/_dbus.py", line 212, in __new__
Dez 01 16:34:42 934 onboard[846]:     return Bus.__new__(cls, Bus.TYPE_SESSION, private=private,
Dez 01 16:34:42 934 onboard[846]:   File "/usr/lib/python3.8/site-packages/dbus/_dbus.py", line 102, in __new__
Dez 01 16:34:42 934 onboard[846]:     bus = BusConnection.__new__(subclass, bus_type, mainloop=mainloop)
Dez 01 16:34:42 934 onboard[846]:   File "/usr/lib/python3.8/site-packages/dbus/bus.py", line 124, in __new__
Dez 01 16:34:42 934 onboard[846]:     bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
Dez 01 16:34:42 934 onboard[846]: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NotSupported: Using X11 for dbus-daemon autolaunch was disabled at compile time, set your DBUS_SESSION_BUS_ADDRESS instead
Dez 01 16:34:42 934 systemd[1]: onboard.service: Main process exited, code=exited, status=1/FAILURE
Dez 01 16:34:42 934 systemd[1]: onboard.service: Failed with result 'exit-code'.
Dez 01 16:34:42 934 systemd[1]: Failed to start Onboard on-screen keyboard.

I then changed the unit to a Type=default unit with dbus-run-session:

$ cat /etc/systemd/system/onboard.service 
[Unit]
Description=Onboard on-screen keyboard
After=kioskbrowser.service
Wants=xorg-server.service

[Service]
User=digsig
Group=digsig
Environment=DISPLAY=:0
ExecStartPre=/usr/bin/setxkbmap de
ExecStart=/usr/bin/dbus-run-session /usr/bin/onboard -a -l Phone
Restart=always
RestartSec=5

[Install]
WantedBy=graphical.target

Which makes onboard show up:

Dez 01 16:40:30 934 systemd[1]: Starting Onboard on-screen keyboard...
Dez 01 16:40:30 934 systemd[1]: Started Onboard on-screen keyboard.
Dez 01 16:40:30 934 dbus-run-session[1107]: dbus-daemon[1107]: [session uid=993 pid=1107] Activating service name='org.a11y.Bus' requested by ':1.0' (uid=993 pid=1108 comm="/usr/bin/python3 /usr/bin/onboard -a -l Phone ")
Dez 01 16:40:30 934 dbus-run-session[1107]: dbus-daemon[1107]: [session uid=993 pid=1107] Successfully activated service 'org.a11y.Bus'
Dez 01 16:40:30 934 dbus-run-session[1108]: 16:40:30.541 WARNING Config: mousetweaks GSettings schema not found, mousetweaks integration disabled.
Dez 01 16:40:30 934 dbus-run-session[1116]: dbus-daemon[1116]: Activating service name='org.a11y.atspi.Registry' requested by ':1.0' (uid=993 pid=1108 comm="/usr/bin/python3 /usr/bin/onboard -a -l Phone ")
Dez 01 16:40:30 934 dbus-run-session[1116]: dbus-daemon[1116]: Successfully activated service 'org.a11y.atspi.Registry'
Dez 01 16:40:30 934 dbus-run-session[1124]: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry

Unfortunately it is not accessible via dbus:

$ busctl call org.onboard.Onboard /org/onboard/Onboard/Keyboard org.onboard.Onboard.Keyboard Show
Call failed: The name org.onboard.Onboard was not provided by any .service files
$ busctl call org.a11y.Bus /org/onboard/Onboard/Keyboard org.onboard.Onboard.Keyboard Show
Call failed: The name org.a11y.Bus was not provided by any .service files

The following command get executed with returncode 0, but onboard will not show up again after being hidden:

$ /usr/bin/dbus-send --type=method_call --dest=org.onboard.Onboard /org/onboard/Onboard/Keyboard org.onboard.Onboard.Keyboard.ToggleVisible
$ /usr/bin/dbus-send --type=method_call --dest=org.onboard.Onboard /org/onboard/Onboard/Keyboard org.onboard.Onboard.Keyboard.Show
$ /usr/bin/dbus-send --type=method_call --dest=org.a11y.Bus /org/onboard/Onboard/Keyboard org.onboard.Onboard.Keyboard.ToggleVisible
$ /usr/bin/dbus-send --type=method_call --dest=org.a11y.Bus /org/onboard/Onboard/Keyboard org.onboard.Onboard.Keyboard.Show
$ /usr/bin/dbus-send --type=method_call --dest=org.a11y.Bus /org/onboard/Onboard/Keyboard org.onboard.Onboard.Keyboard.TotallyInvalidCommand

How can I start onboard as a system service, so that I can control it via dbus?

My goal is to run onboard on system startup as a specified user and as well as a timed service, that makes onboard show up again after it was hidden by a user through its GUI.

Workaround:
As suggested by @seth, I created a custom layout without the hide button.

Last edited by schard (2020-12-09 12:55:27)

seth · 2020-12-01 16:20:23

You need to tell dbus-send which bus to use and the UID (digsig) probably needs to hold the xauthority as well to access the bus.
What's the point of this and why don't you run it as user service?
Availability w/ the DM?

schard · 2020-12-01 16:39:06

Running it as a user service technically works.
But the service needs to start with the system.
So I'll need to work with lingering user sessions here.
Furthermore, the user digsig has no password set and is considered a system user.
So changing the user context from the administrative user I use over SSH to digsig with a woking systemd-logind session is a hassle.
I'd also rather not have it generate any user data, i.e. in ~/.config/systemd/user.
So iff there is another possibility to solve this on a system service-level, I'd prefer it.

The point of this whole stuff is to create a touchscreen-based kiosk browser system.
The on-screen keyboard is just one part of it.

Last edited by schard (2020-12-01 16:42:59)

seth · 2020-12-01 16:50:28

But the service needs to start with the system.

Why and who's the user digsig?
Which user is supposed to run dbus-send to talk to onboard? digsig?
If not, you'll have to grant your "administrative user" access to digsig's/onboards session bus (set permissions and export the socket)

Edit: ah, you want to run an noboad keyboard that the user can use but not control (kill the PID etc)?

Last edited by seth (2020-12-01 16:53:25)

schard · 2020-12-01 16:54:55

The service needs to start with the system because the point of this kiosk solution is to have a computer with a touchscreen, that starts a browser and and on-screen keyboard on a plain xorg-server when booted.
The digsig user is the user in whose context the kiosk programs (web browser and on-screen keyboard) should run. It is an abbreviation for "digital signage".
The dbus-send or busctl call commands should be run by digsig, yes.
The administrative user is there for system administration only. I just use it to login to the system via SSH and configure it. The production software should not run within its user context, but within digsig's.

seth wrote:

Edit: ah, you want to run an noboad keyboard that the user can use but not control (kill the PID etc)?

Also, yes. But primarily the goal of the system is to provide a kiosk system with only a touch screen as HID.

Normally I wouldn't care about this dbus stuff.
But I have tested all the keyboards from here.
Onboard is the only one, that vaguely meets my functional and aesthetic needs.
Unfortunately in all its layouts it has a button to hide it. So if a user presses this, following users won't be able to control the system.
Hence I need dbus to periodically tell the keyboard to show itself (again).

Last edited by schard (2020-12-01 17:01:23)

seth · 2020-12-02 08:57:39

I'd first and foremost remove the hide button from the layout - it's an xml file…

So digsig is the regular session owner, but the session probably has no session bus?

If you dbus-launch onboard, it's not run in the context of the system or session bus, so you'll have to alter the $DBUS_SESSION_BUS_ADDRESS when you want to talk to it (it's gonna be some "unix:abstract=/tmp/dbus-jV0mrw6oAh,guid=5269ab1d419b948b93f25ab15fc754b3") to dbus-send, but you could just have the digsig user run a regular session - dbus-send needs to know which socket to write.
If you don't want to use a user service, I'd just run onboard with whatever starts/sets up the digsig session (webbrowser etc.)

Arch Linux

#1 2020-12-01 15:49:53

[WORKAROUND] Start onboard as a dbus system service

#2 2020-12-01 16:20:23

Re: [WORKAROUND] Start onboard as a dbus system service

#3 2020-12-01 16:39:06

Re: [WORKAROUND] Start onboard as a dbus system service

#4 2020-12-01 16:50:28

Re: [WORKAROUND] Start onboard as a dbus system service

#5 2020-12-01 16:54:55

Re: [WORKAROUND] Start onboard as a dbus system service

#6 2020-12-02 08:57:39

Re: [WORKAROUND] Start onboard as a dbus system service

Board footer