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 <nls1...@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 <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
