Search code examples
google-cloud-platformgoogle-compute-enginegoogle-cloud-stackdrivergoogle-cloud-logging

ChromeOS errors in GCP Logging


I'm seeing errors in StackDriver logging for my Compute instance. The logs are showing repeated issues every hour, creating a lot of noise. I have a Spring Boot API deployed in a container to a VM in Compute Engine using latest stable version of Container OS.

I'm relatively new to GCP and don't understand what is causing this issue, searches have come up empty so far.

Failed to call method: org.chromium.SessionManagerInterface.RetrieveActiveSessions: object_path= /org/chromium/SessionManager: org.freedesktop.DBus.Error.ServiceUnknown: The name org.chromium.SessionManager was not provided by any .service files
CallMethodAndBlockWithTimeout(...): Domain=dbus, Code=org.freedesktop.DBus.Error.ServiceUnknown, Message=The name org.chromium.SessionManager was not provided by any .service file
Error calling D-Bus proxy call to interface '/org/chromium/SessionManager': The name org.chromium.SessionManager was not provided by any .service files

The same 3 lines are repeating every hour. Anyone aware of what might be causing this or how to fix/suppress these?


Solution

  • I looked into this error, and as per my findings:

    • The error message that you have been receiving is a manifestation of Chrome to reliably exit shortly after starting up.
    • The UI’s job (which encompasses Chrome, the session_manager and the window manager) gets shut down by upstart because of it's thrashing, and when the test tries to restart the session_manager, the session_manager cannot communicate it over to the D-Bus.

    The crash collection software in Container OS was originally for Chromebooks (The laptop using Chrome browser). So the code typically expects Chrome and some other related software on the system.

    However, Container OS is a server OS, and does not have Chrome. So if Chrome is missing, the software will report some errors. They are actually not real failures, just some verbose error messages.

    Overall, It is safe to ignore these logs and continue using your VM Instances.

    Hope this helps.