GNOME.org
 

Re: Need GDBus Service file for org.gnome.Shell

Hello Norman,

thank you very much for your effort! Installing Arch just to reproduce
an issue, wow!
In order to reproduce it, I should add: This only happens when in the
privacy settings no lock screen is selected and there is an
automatically established network connection. I have it on two
completly different systems (Desktop with AMD+Nvidia, Laptop with
Intel).

But there is really good news: DeviousNull found a fix for the
flat-CPU-graph issue:
https://github.com/paradoxxxzero/gnome-shell-system-monitor-applet/pull/212

So no more need for a workaround!

Thank you again!
Bazon


2013/6/22 Norman L. Smith <nls1729 gmail com>:

Hello Bazon,

I found I had not clearly understood the sequence of events.
I re-read your earlier post of your need to restart the
extension after resume.

The reason the SLEEP... and RESUME... log messages did not
appear is the disconnect of the signals when the extension
was disabled.  If you don't disconnect, the signals are
caught even though the extension is disabled.  I apparently
erred in the code segment I posted.  I had commented out
the disconnects to track down where the signals occurred.

The signals are not of much use with your problem.

Note I could only get SLEEP... and RESUME... log messages
when the suspend was started with the Suspend item in the
user menu. If the Suspend menu item is used the sequence is:

The shell disables all enabled extensions.

The 'notify_sleep' signal fires.

Then the hardware sleeps.

When the suspended hardware is awaken by key press the
'notify_resume' signal fires.

The extension's enable is called.

If I use the computer's power button to initiate the
suspend I don't see signals but do see init of the
extensions. The sequence is:

hit power button..

extensions are disabled

hardware sleeps

hit power button..

extensions init and then enabled

I tested on Fedora 18 GS3.6.3 and Fedora 19 Beta GS3.8.3.
I could not duplicate your problem of flat-line CPU.
I read your post on the git site which indicated the
problem was with Arch Linux.

I put together a test system and loaded Arch with the gnome
and gnome-extra packages and updated to the latest updates.

I loaded the extension and could not duplicate the problem
with a new Arch install.

Arch is very much a "roll your own" distro.

I wonder if your problem is specific to your installed system.

Regards,
Norman


On Sat, 2013-06-22 at 11:31 +0200, Bazon Bloch wrote:

Hi Norman,

now I got time to try what you proposed:

const UPowerGlib = imports.gi.UPowerGlib; # in the declaration part of
the extension.js


this._upClient = new UPowerGlib.Client();
this._sigSleep = this._upClient.connect('notify_sleep',
Lang.bind(this, function()
       {
           log("SLEEP.................");
        }));
this._sigResume =
this._upClient.connect('notify_resume',Lang.bind(this, function()
        {
             log("RESUME.................");
         }));

in init() (I also tried enable())
and

this._upClient.disconnect(this._sigSleep);
this._upClient.disconnect(this._sigResume);

in disable() of the extension.js.

But it didn't work. I got no "SLEEP................." or
"RESUME................." messages in my log (which I called by
journalctl -b /usr/bin/gnome-session --since=today ).
I suppose, that's because of running systemd here?

Anyway, thanks! Let's hope the authoer of the extension finds the mistake...
(...I also tried to find it, but didn't succeed until now.)


Cheers
Bazon



2013/6/20 Norman L. Smith <nls1729 gmail com>:

Hello Bazon,

After reading this thread I became curious and poked
around the suspend/resume stuff in glib.  I put the
following bit of code in one of my extensions and
found that it worked to (1) notify of the suspend
sleep and (2) notify when the resume occurred.

const UPowerGlib = imports.gi.UPowerGlib;
.
.
. ...in a class init ...

        this._upClient = new UPowerGlib.Client();
        this._sigSleep = this._upClient.connect('notify_sleep',
Lang.bind(this, function() {
            log("SLEEP.................");
        }));
        this._sigResume = this._upClient.connect('notify_resume',
Lang.bind(this, function() {
            log("RESUME.................");
        }));
.
.
.... in the class destroy ...

        this._upClient.disconnect(this._sigSleep);
        this._upClient.disconnect(this._sigResume);

You may be able to attack your problem as Simon
suggests: "The correct solution is to fix the extension
so it doesn't need reloading."

Avoid the error by changing the state of your extension
on "sleep" and re-store its state on "resume".

Hope this is useful.

Good luck,
Norman



On Thu, 2013-06-20 at 13:31 +0200, Bazon Bloch wrote:

Aha, thank you.

But then is the question:
Why doesn't it reach Gnome-Shell? And what can be done to make it
reach Gnome-Shell?


Am 20.06.2013 13:15 schrieb "Simon McVittie"
<simon mcvittie collabora co uk>:
        On 20/06/13 11:24, Bazon Bloch wrote:
        > I got the Error:
        > "GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The
        name
        > org.gnome.Shell was not provided by any service files"

        That doesn't necessarily mean it *should* be provided by
        a .service
        file, just that something tried to communicate with
        gnome-shell and
        didn't find one. Creating a .service file is a way to cause
        the service
        to be started automatically, which is often appropriate for
        non-GUI
        services - but attempting to run a new copy of GNOME Shell is
        not the
        right thing to happen here.

        > I still got the flat-CPU-graph-problem
        > with
        https://extensions.gnome.org/extension/120/system-monitor/
        after
        > resume from suspend. Thanks to this list, I now how to
        restart that via
        > dbus:
        > gdbus call --session --dest org.gnome.Shell --object-path
        > /org/gnome/Shell --method
        org.gnome.Shell.Extensions.ReloadExtension
        > system-monitor paradoxxx zero gmail com

        Right, that's a workaround. The correct solution is to fix the
        extension
        so it doesn't need reloading.

        One possible route towards achieving this would be to have the
        extension
        watch the system bus for a signal indicating a resume from
        suspend, and
        do what it would have done when the Shell disabled and
        re-enabled it;
        the next refinement of that would be to reduce what is done
        after 10
        seconds to the absolute minimum to make it work, which would
        hopefully
        indicate what was wrong in a specific enough way to be able to
        fix it
        correctly.

        > I would like to have this executed automatically about 10s
        after each
        > resume, and so I created a systemd service:
        ...
        > Environment=DISPLAY=:0
        > ExecStart=/usr/bin/sh -c "/path/to/reload-sys-mon.sh"

        System-level services connecting to a user session service are
        not
        something that is, or should be, supported. Something in the
        user
        session (like the extension itself) should monitor the system
        bus to
        detect a resume.

        >   Process: 1548 ExecStart=/usr/bin/sh
        -c /path/to/reload-sys-mon.sh
        > (code=exited, status=0/SUCCESS)
        >    CGroup:
        name=systemd:/system/resume  service/resume carl service
        >            └─1554 dbus-launch
        > --autolaunch=0b13b59cd91045ad9b746f7b36da8550
        --binary-syntax --close-stderr

        The system service is creating a tiny user-level D-Bus session
        containing nothing except your shell script, and trying to
        talk to a
        GNOME Shell instance in that session. Your GNOME Shell is in a
        different
        session, created when you logged in. Creating a .service file
        would
        result in your script trying to start a second GNOME Shell
        instance,
        sharing the $DISPLAY with the real one, but in a different
        login session
        - that's never going to work very well.

            S

        _______________________________________________
        gnome-shell-list mailing list
        gnome-shell-list gnome org
        https://mail.gnome.org/mailman/listinfo/gnome-shell-list
_______________________________________________
gnome-shell-list mailing list
gnome-shell-list gnome org
https://mail.gnome.org/mailman/listinfo/gnome-shell-list
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]