when i was open the ‘launch desktop’ it show me cannot connet to the server
the user log(ondemand/data/sys/dashboard/batch_connect/sys/bc_desktop/**/output/4716a39e-ca01-48a3-a4ec-5ff3064618d9):
system-config-printer-applet: failed to start NewPrinterNotification service
system-config-printer-applet: failed to start PrinterDriversInstaller service: org.freedesktop.DBus.Error.AccessDenied: Connection “:1.2006” is not allowed to own the service “com.redhat.PrinterDriversInstaller” due to security policies in the configuration file
Initializing caja-image-converter extension
Initializing caja-open-terminal extension
*** ERROR ***
TI:09:31:53 TH:0x11eb060 FI:gpm-manager.c FN:gpm_manager_systemd_inhibit,1784
@flybirdkh thanks for bringing the questions here.
To me this looks like the key line from the message you included:
There’s an answer on StackOverflow about DBus policies: policy - DBus SystemBus policies - Stack Overflow. It appears that you may need to either explicitly approve the service, or tweak the access control for the service. Copying Juan’s answer:
The simplest way to get going with the example above is to edit /etc/dbus-1/system.conf and add the following line:
<policy>
...
<allow own="org.testobj.service"/>
</policy>
I’ve just encountered this error as well. My user session log contains the much the same output, although no reference to dbus. Log output at end of comments. Major difference is that my system is reporting ‘nm-applet’ network manager not running. I’m not familiar with this, and will look into that now. No complaints about dbus in this case.
Our situation is that following performing the update from v1.5 -> v1.6, reverse proxy is not succeeding on our cluster, and generating the “PrinterDriversInstall” error. OnDemand was originally installed here with v1.3 in October 2018, and the reverse proxy to support interactive applications had been successfully installed soon thereafter. In Feb 2019 we cleaned up the system configuration by adopting the vnc script_wrapper approach (from .yml):
VNC support was pretty robust since February, and was not affected by the upgrade v1.3 -> v1.5.
Thanks all
from data/sys/dashboard/batch_connect/sys/bc_desktop/smaster/output/<long-hash>/output.log
(xfwm4:25494): xfwm4-WARNING **: 11:40:48.720: Error opening /dev/dri/card0: Permission denied
SELinux Troubleshooter: Applet requires SELinux be enabled to run.
/usr/share/system-config-printer/applet.py:44: PyGIWarning: Notify was imported without specifying a version first. Use gi.require_version('Notify', '0.7') before import to ensure that the right version gets loaded.
from gi.repository import Notify
system-config-printer-applet: failed to start NewPrinterNotification service
system-config-printer-applet: failed to start PrinterDriversInstaller service: org.freedesktop.DBus.Error.AccessDenied: Connection ":1.1985" is not allowed to own the service "com.redhat.PrinterDriversInstaller" due to security policies in the configuration file
(nm-applet:25509): nm-applet-WARNING **: 11:40:50.918: NetworkManager is not running
slurmstepd: error: *** JOB 13730687 ON compt162 CANCELLED AT 2019-08-12T14:17:35 ***
@flybirdkh The file /etc/dbus-1/system.d/com.redhat.PrinterDriversInstaller.conf is what you can modify and it comes from system-config-printer-libs package. If you don’t need that package it may be easier to just uninstall it. I don’t know enough about that particular dbus interface or dbus itself to know if it’s safe to change the policy for default context.
@flybirdkh a little bit of googling and I found that there are policy kits for mate, xfce and gnome. Do you have these packages installed on your system?
here’s the bug report with a stack trace that’s very similar to yours. Looks like that person had to get polkit, but you may or may not need all of those for the various flavors. That rpm -q was taken from our VNC/batch connect host.
@emily.dragowsky I don’t know off hand what’s going on with your site, but we’ll look into it. Off the top I’d guess what you did, look into this network manager applet and ensure it boots?
@emily.dragowsky after a little bit of reading, it looks like all those messages may be OK. They’re just applets after all, and if they fail to boot it shouldn’t stop gnome from booting. I also get the bit about not being able to read /dev/dri/card0 so that’s nothing also.
I would look in journalctl or /var/log/messages for something that may be killing the process(es). I’d also be interested in knowing what the exit status was. It doesn’t seem like anything was that wrong, then all the sudden it’s cancelled?
just solve the print error.
the “(mate-panel:518107): GLib-GObject-CRITICAL **: 09:31:54.569: g_object_unref: assertion ‘G_IS_OBJECT (object)’ failed” is the main error which is still here.
Hi, the suggestion to review the config files was useful.
The regex used in our local ‘ood_portal.yml’ had been changed (not sure what happened). Restoring that regex: ‘(comp)\d+’ --> ‘(compt)\d+’ resolved the issue. So the literal error presented in the webpage (URL not found) should have been taken more literally by myself. And I think that this broke the reverse proxy because this form (comp) of the hostnames was inconsistent with the submit files used with the interactive applications – but I’m not convinced that that is true. I’m not even convinced that I should think of this as having “broken the reverse proxy”. I mean it worked fine, but it the application was launched on compt143, and the ood_portal.yml could only supply comp143 for a request, is that truly a broken reverse proxy?
In any event, consistency is now restored in our environment.Our interactive apps are stable for the past day since having this realization.
And the selectable ‘quality’ and ‘compression’ have been exercised, and are appreciated, now that the apps are functional.
