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 <nls1...@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.mcvit...@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-moni...@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
> >
> >
_______________________________________________
gnome-shell-list mailing list
gnome-shell-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-shell-list
