gmane.comp.gnome.apps.gkrellm

[PATCH] gkrellmd doesn't play nicely with autofs

Gerard Neil — 2012-05-15T19:04:32

Under linux, running gkrellmd in combination with autofs will force
all auto-mounted filesystems to be mounted, and to stay mounted or
repeatedly unmount and remount.

Mount table entries of type "autofs" represent mount points under
control of the automount daemon; if the mount point directory is
accessed, then the daemon causes a real filesystem mount to occur.
After such an auto-mount, there will be two entries in the mount
table, one of type "autofs" and one for the newly mounted filesystem.

gkrellmd periodically scans mount points to support the filesystem
free-space monitoring. It treats mount points of type "autofs" as real
filesystems and attempts to determine their free space. This access
causes an automount to occur. If autofs has been configured to
automatically unmount after a timeout, then the gkrellmd polling will
either prevent the unmount occurring, or cause repeated mount, unmount
cycles, depending on the exact configuration.

The solution is trivial, simply ignore filesystems of type "autofs"
during filesystem polling.

Note that with this fix gkrellmd will still happily report on already
auto-mounted filesystems through their real mount entries, it just
won't cause the auto-mounts to occur. If the user wants to allow these
filesystems to auto-unmount, they must be careful to configure
gkrellmd's (n)fs-interval to be larger than twice the auto-unmount time.

-------------------------------------

--- gkrellm-2.3.5.old/src/sysdeps/linux.c 2010-10-06 03:27:33.000000000 +1100
+++ gkrellm-2.3.5/src/sysdeps/linux.c 2011-11-24 02:07:30.926450485 +1100
< at >< at > -1439,6 +1439,7 < at >< at >
  || !strcmp(type, "usbdevfs")
  || !strcmp(type, "usbfs")
  || !strcmp(type, "sysfs")
+ || !strcmp(type, "autofs")
    )
  continue;
  /* Strip trailing / from the directory.

______________________________________________
Gkrellm mailing list
gkrellm< at >lists.netservicesgroup.com
Read archives-join-leave-set RSS feed:
http://archive.lists.netservicesgroup.com
This service is provided by The Network Services Group:
http://www.netservicesgroup.com

[PATCH] gkrellm doesn't treat cifs as a network filesystem

Gerard Neil — 2012-05-15T18:43:43

gkrellmd knows that certain filesystem types are network filesystems;
it supports different free-space polling frequencies (or disabling of
polling) for network vs non-network filesystems via the configuration
parameters fs-timeout and nfs-timeout.
Filesystems of type "cifs" should be treated identically to those of type "smb".

----------------------

--- gkrellm-2.3.5.old/server/monitor.c2010-10-06 03:46:59.000000000 +1100
+++ gkrellm-2.3.5/server/monitor.c2011-11-24 02:01:30.871402778 +1100
< at >< at > -1329,7 +1329,8 < at >< at >
 static gchar *remote_fs_types[] =
 {
 "nfs",
-"smbfs"
+"smbfs",
+"cifs"
 };

 void
--- gkrellm-2.3.5.old/src/fs.c2010-09-15 02:25:51.000000000 +1000
+++ gkrellm-2.3.5/src/fs.c2011-11-24 02:00:17.347088370 +1100
< at >< at > -163,7 +163,8 < at >< at >
 static gchar *remote_fs_types[]=
 {
 "nfs",
-"smbfs"
+"smbfs",
+"cifs"
 };

______________________________________________
Gkrellm mailing list
gkrellm< at >lists.netservicesgroup.com
Read archives-join-leave-set RSS feed:
http://archive.lists.netservicesgroup.com
This service is provided by The Network Services Group:
http://www.netservicesgroup.com

[PATCH] gkrellmd plays badly with autofs

Gerard Neil — 2012-05-15T18:35:03

Under linux, running gkrellmd in combination with autofs will force
all auto-mounted filesystems to be mounted, and to stay mounted or
repeatedly unmount and remount.

Mount table entries of type "autofs" represent mount points under
control of the automount daemon; if the mount point directory is
accessed, then the daemon causes a real filesystem mount to occur.
After such an auto-mount, there will be two entries in the mount
table, one of type "autofs" and one for the newly mounted filesystem.

gkrellmd periodically scans mount points to support the filesystem
free-space monitoring. It treats mount points of type "autofs" as real
filesystems and attempts to determine their free space. This access
causes an automount to occur. If autofs has been configured to
automatically unmount after a timeout, then the gkrellmd polling will
either prevent the unmount occurring, or cause repeated mount, unmount
cycles, depending on the exact configuration.

The solution is trivial, simply ignore filesystems of type "autofs"
during filesystem polling.

Note that with this fix gkrellmd will still happily report on already
auto-mounted filesystems through their real mount entries, it just
won't cause the auto-mounts to occur. If the user wants to allow these
filesystems to auto-unmount, they must be careful to configure
gkrellmd's (n)fs-interval to be > twice the auto-unmount time.

---------

--- gkrellm-2.3.5.old/src/sysdeps/linux.c 2010-10-06 03:27:33.000000000 +1100
+++ gkrellm-2.3.5/src/sysdeps/linux.c 2011-11-24 02:07:30.926450485 +1100
< at >< at > -1439,6 +1439,7 < at >< at >
  || !strcmp(type, "usbdevfs")
  || !strcmp(type, "usbfs")
  || !strcmp(type, "sysfs")
+ || !strcmp(type, "autofs")
    )
  continue;
  /* Strip trailing / from the directory.

______________________________________________
Gkrellm mailing list
gkrellm< at >lists.netservicesgroup.com
Read archives-join-leave-set RSS feed:
http://archive.lists.netservicesgroup.com
This service is provided by The Network Services Group:
http://www.netservicesgroup.com

Re: Bug#630117: [PATCH] Check all battery variants when polling

Sandro Tosi — 2012-04-06T22:52:27

Hello Jörn,
thanks for looking into this!

I'm also forwarding your results on gkrellm mailing list, so upstream
authors can have a look at your patch and comment/commit it.

Dear gkrellm authors, attached is a patch to fix a problem with
battery level upon suspension; you can also have a look at the full
bug history to get a better idea of how Jörn reached to this patch:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630117

Cheers,
Sandro

On Sun, Apr 1, 2012 at 23:48, Jörn Engel <joern< at >logfs.org> wrote:

[gkrellm] nvidia-drivers 295.20 breaking gkrellm

linux_slacker — 2012-03-21T19:42:12

I (and a few others: 
http://forums.gentoo.org/viewtopic-t-912998-start-0.html 
http://forums.gentoo.org/viewtopic-t-912998-start-0.html ) 
noticed that monitoring the GPU temperature with the newer nvidia-drivers
(295.20 and above) breaks gkrellm.

Annoyingly, gkrellm works fine when run under gdb.  As the debug messages
show, it seems that it's able to get the initial temperature from nvidia
fine, but then segfaults from the command line.  Here are the debug
messages.  Both of these were run with: gkrellm --debug-level 0x3080 (from
gdb and command line):

gdb (working):

--- GKrellM 2.3.5 ---
        [gkrellm_connect_to: (2,1,6) 127.0.0.1:7634]
hddtemp_daemon_read (once a minute):
        |/dev/sda|WDC WD3200AAJS-00L7A0|35|C|
nvidia-settings: result=1  output=
1 GPU on hector:0

    [0] hector:0[gpu:0] (Quadro NVS 290)

 stderr=
nvidia-settings gpus = 1
nvidia-settings GPUCoreTemp: result=1  output=
  Attribute 'GPUCoreTemp' (hector:0.0): 66.
    'GPUCoreTemp' is an integer attribute.
    'GPUCoreTemp' is a read-only attribute.
    'GPUCoreTemp' can use the following target types: X Screen, GPU.


nvidia-settings GPUAmbientTemp: result=0  output=


nvidia-settings GPUAmbientTemp: result=0  output=


libsensors: init OK
coretemp:/sys/class/hwmon/hwmon0/device coretemp< at >0/temp2 1
coretemp:/sys/class/hwmon/hwmon0/device coretemp< at >0/temp3 1
coretemp:/sys/class/hwmon/hwmon0/device coretemp< at >0/temp4 1
coretemp:/sys/class/hwmon/hwmon0/device coretemp< at >0/temp5 1
load_font: Serif 11 0x72d920
load_font: Serif 9 0x72d8f0
load_font: Serif 8 0x72d860
load_sensors_config: <sensor_config_version> <1>
load_sensors_config: <sensor_sysdep_private> <2>
load_sensors_config: <sensor_float_factor> <10000>
load_sensors_config: <gkrellm_float_factor> <1000>
load_sensors_config: <"GPU> <C" "nVidia GPU Core" 10000 0 1 0>
load_sensors_config: <units_fahrenheit> <0>
load_sensors_config: <show_units> <0>
load_sensors_config: <volt_display_mode> <0>
nvidia-settings GPUCoreTemp: result=1  output=
  Attribute 'GPUCoreTemp' (hector:0.0): 66.
    'GPUCoreTemp' is an integer attribute.
    'GPUCoreTemp' is a read-only attribute.
    'GPUCoreTemp' can use the following target types: X Screen, GPU.


sensor_temp: GPU C GPUCoreTemp t=66.00
[New Thread 0x7fffeac7e700 (LWP 22534)]
sensor_temp: GPU C GPUCoreTemp t=66.00
nvidia-settings GPUCoreTemp: result=1  output=
  Attribute 'GPUCoreTemp' (hector:0.0): 66.
    'GPUCoreTemp' is an integer attribute.
    'GPUCoreTemp' is a read-only attribute.
    'GPUCoreTemp' can use the following target types: X Screen, GPU.


[Thread 0x7fffeac7e700 (LWP 22534) exited]
[New Thread 0x7fffeac7e700 (LWP 22536)]
sensor_temp: GPU C GPUCoreTemp t=66.00
nvidia-settings GPUCoreTemp: result=1  output=
  Attribute 'GPUCoreTemp' (hector:0.0): 66.
    'GPUCoreTemp' is an integer attribute.
    'GPUCoreTemp' is a read-only attribute.
    'GPUCoreTemp' can use the following target types: X Screen, GPU.


-----

command line (broken):

--- GKrellM 2.3.5 ---
        [gkrellm_connect_to: (2,1,6) 127.0.0.1:7634]
hddtemp_daemon_read (once a minute):
        |/dev/sda|WDC WD3200AAJS-00L7A0|35|C|
nvidia-settings: result=1  output=
1 GPU on hector:0

    [0] hector:0[gpu:0] (Quadro NVS 290)

 stderr=
nvidia-settings gpus = 1
nvidia-settings GPUCoreTemp: result=1  output=
  Attribute 'GPUCoreTemp' (hector:0.0): 66.
    'GPUCoreTemp' is an integer attribute.
    'GPUCoreTemp' is a read-only attribute.
    'GPUCoreTemp' can use the following target types: X Screen, GPU.


nvidia-settings GPUAmbientTemp: result=0  output=


nvidia-settings GPUAmbientTemp: result=0  output=


libsensors: init OK
coretemp:/sys/class/hwmon/hwmon0/device coretemp< at >0/temp2 1
coretemp:/sys/class/hwmon/hwmon0/device coretemp< at >0/temp3 1
coretemp:/sys/class/hwmon/hwmon0/device coretemp< at >0/temp4 1
coretemp:/sys/class/hwmon/hwmon0/device coretemp< at >0/temp5 1
load_font: Serif 11 0x25b1d20
load_font: Serif 9 0x25b1cf0
load_font: Serif 8 0x25b1c60
load_sensors_config: <sensor_config_version> <1>
load_sensors_config: <sensor_sysdep_private> <2>
load_sensors_config: <sensor_float_factor> <10000>
load_sensors_config: <gkrellm_float_factor> <1000>
load_sensors_config: <"GPU> <C" "nVidia GPU Core" 10000 0 1 0>
load_sensors_config: <units_fahrenheit> <0>
load_sensors_config: <show_units> <0>
load_sensors_config: <volt_display_mode> <0>
nvidia-settings GPUCoreTemp: result=1  output=
  Attribute 'GPUCoreTemp' (hector:0.0): 66.
    'GPUCoreTemp' is an integer attribute.
    'GPUCoreTemp' is a read-only attribute.
    'GPUCoreTemp' can use the following target types: X Screen, GPU.


sensor_temp: GPU C GPUCoreTemp t=66.00
sensor_temp: GPU C GPUCoreTemp t=66.00
gkrellm segmentation fault:  Sensors  (update_monitor)

-----

Any help would be much appreciated.

Re: gkrellm as a phone app for servers

Rio — 2012-03-20T09:04:08

computers
then
would
temps,


fantastic! thank you! now i can honestly say my phone will be taking the place of 89% of 
my computer's functions that i need for work. not sure if thats good or bad yet. but.... 
:D

Re: gkrellm as a phone app for servers

Maher Awamy — 2012-03-19T22:38:47

brilliant!!!
On Mar 20, 2012 1:31 AM, "Bill Wilson" <billw< at >dslextreme.com> wrote:

Re: gkrellm as a phone app for servers

Stefan Gehn — 2012-03-19T22:29:26

yes, me. But I think I'd rather finish the port to GIO first before more 
adding more networking candy ;)

Stefan

______________________________________________
Gkrellm mailing list
gkrellm< at >lists.netservicesgroup.com
Read archives-join-leave-set RSS feed:
http://archive.lists.netservicesgroup.com
This service is provided by The Network Services Group:
http://www.netservicesgroup.com

Re: gkrellm as a phone app for servers

Bill Wilson — 2012-03-19T22:27:32

On Mon, 19 Mar 2012 13:52:02 +0300
Maher Awamy <muhri< at >muhri.net> wrote:


There was one done a while back:
http://apps.androidguys.com/#android/akrellm/id/hu.monsta.akrellm

and there's a new one that may be coming - this seems to be an
announcement:

http://www.droidlab.se/en/content/gkrellm-client-new-project


Bill

______________________________________________
Gkrellm mailing list
gkrellm< at >lists.netservicesgroup.com
Read archives-join-leave-set RSS feed:
http://archive.lists.netservicesgroup.com
This service is provided by The Network Services Group:
http://www.netservicesgroup.com

Re: gkrellm as a phone app for servers

Dale Smith — 2012-03-19T11:47:48

Anyone ever think about using mdns (Avhai, Bonjour) to discover gkrellm servers?

-Dale

______________________________________________
Gkrellm mailing list
gkrellm< at >lists.netservicesgroup.com
Read archives-join-leave-set RSS feed:
http://archive.lists.netservicesgroup.com
This service is provided by The Network Services Group:
http://www.netservicesgroup.com

Re: gkrellm as a phone app for servers

Maher Awamy — 2012-03-19T10:52:02

I'd love to see such a thing....

On Mon, Mar 19, 2012 at 1:45 PM, Rio <rio< at >pathworx.com> wrote:

gkrellm as a phone app for servers

Rio — 2012-03-19T10:45:48

has anyone given thought to creating a gkrellm client android app to monitor computers 
running gkrellmd?

lots would have to be stripped but have it ask the server to monitor when starting, then 
just show the hardware reports from the server.  i doubt the classic inline display would 
be readable, but maybe a 'thumb through' setup page by page to view the processors, temps, 
processes, sensors, etc..

possible or a pipe dream?

Fw: Re: Plugins and remote monitoring

Bill Wilson — 2012-03-15T03:07:39

On Wed, 14 Mar 2012 20:32:42 +0000
Damien Moody <online< at >audiodef.com> wrote:


When you emerged gkrelltop, the local gkrelltop.so and a gkrelltopd.so intended
for a server was probably built, but the server gkrelltopd.so plugin needs to be
installed on the server machine and it needs to be enabled . 
So the requirements on the server are:
1) gkrelltopd.so in one of
~/.gkrellm2/plugins-gkrellmd
/usr/local/lib/gkrellm2/plugins-gkrellmd

2) Enable gkrelltopd.so on the server by having the line
plugin-enable gkrelltopd
in at least one of the files
~/.gkrellmd.conf
/usr/local/etc/gkrellmd.conf

On the server, run gkrellmd -plist to see what server plugins are installed
and gkrellmd -plog to see if it can load OK.

If the local and remote architectures are compatible, you can just copy over the
gkrellmtopd.so file from where it was built.  Otherwise you can build on the server
in the gkrelltop source directory with:

make gkrelltopd.so

You might then need to manually install gkrelltopd.so in an install directory because
it seems a make install will also try to build gkrelltop.so which you might not want on
the server.

Well, I think that should do it.  The latest gkrelltop version I know of is 2.2.6 but I
think the server gkrelltopd.so first appeared for the gkrelltop 2.2 or 2.2.1 version.

Bill
 

______________________________________________
Gkrellm mailing list
gkrellm< at >lists.netservicesgroup.com
Read archives-join-leave-set RSS feed:
http://archive.lists.netservicesgroup.com
This service is provided by The Network Services Group:
http://www.netservicesgroup.com

Re: Plugins and remote monitoring

Damien Moody — 2012-03-14T20:32:42

Hi Bill,

I've tried gkrelltop but have not gotten it to display remote
data. Do I need to install gkrelltop on both the remote and local
machines? 

Damien

On Wed, 14 Mar 2012 14:24:45 -0500
Bill Wilson <billw< at >dslextreme.com> wrote:



______________________________________________
Gkrellm mailing list
gkrellm< at >lists.netservicesgroup.com
Read archives-join-leave-set RSS feed:
http://archive.lists.netservicesgroup.com
This service is provided by The Network Services Group:
http://www.netservicesgroup.com

Re: Plugins and remote monitoring

Bill Wilson — 2012-03-14T19:24:45

On Wed, 14 Mar 2012 13:32:15 +0000
Damien Moody <online< at >audiodef.com> wrote:


A plugin has to be written to handle the server possibility.  This means a plugin
needs to written to have a gkrellmd server module and a corresponding
local gkrellm module that will check for the presence of its remote running
plugin counterpart.  Unfortunately, there just aren't many plugins written this way,
but off the top of my head, I can list at least gkrellmwho2 and gkrelltop that are.

Bill

______________________________________________
Gkrellm mailing list
gkrellm< at >lists.netservicesgroup.com
Read archives-join-leave-set RSS feed:
http://archive.lists.netservicesgroup.com
This service is provided by The Network Services Group:
http://www.netservicesgroup.com

Plugins and remote monitoring

Damien Moody — 2012-03-14T13:32:15

I seem to be unable to use plugins with remote monitoring. All the
builtins use remote data, but any plugins I add use local data, even
when starting with the -s switch. 

Is this a known issue? Can I fix this?

I use Gentoo, and I've installed gkrellm + various plugins via emerge. 

______________________________________________
Gkrellm mailing list
gkrellm< at >lists.netservicesgroup.com
Read archives-join-leave-set RSS feed:
http://archive.lists.netservicesgroup.com
This service is provided by The Network Services Group:
http://www.netservicesgroup.com

Re: gkrellmd problem

Andreas Hauffe — 2012-02-15T07:31:40

Hi,

thanks for your answer. The problem has gone for some time, but it's back 
again. 

Now to you questions:

What leaking means is shown in a screen shot I attached. All of the upper 
computer are running at 100% on all cores. But it seems that the client 
doesn't recieve information continuously.

A reconnection of the client doesn't resolve the problem. A new connection to 
the server is possible but take a while.

A restart of the daemon solves the problem. But I realy don't now what must 
happen to reproduce this behaviour. It's seems, that this happen when to many 
people connect and reconnect ovre the time.

Bye,
Andreas

Am Samstag, 31. Dezember 2011, 16:26:14 schrieb Stefan Gehn:

Re: gkrellmd problem

Stefan Gehn — 2011-12-31T15:26:14

Hi,

On 12/09/2011 10:09 AM, Andreas Hauffe wrote:

Disabling all timeouts is probably not a good idea, clients will never
reconnect in case of network problems.


What are you referring to with "leak"? Does the gkrellmd process consume
more memory over time or does it cause any high cpu-usage in this scenario?


Can new clients actually connect to the server or will it stop
accepting new connections?


In theory, clients blocking eachother should not happen, all
client-connections are set to non-blocking mode. I have started working
on porting gkrellmd to GIO-based networking but the code hasn't been
published yet. If you're willing to build gkrellmd yourself I can push
the current work in January so you can try out wether it improves your
situation.

Bye,
Stefan Gehn

______________________________________________
Gkrellm mailing list
gkrellm< at >lists.netservicesgroup.com
Read archives-join-leave-set RSS feed:
http://archive.lists.netservicesgroup.com
This service is provided by The Network Services Group:
http://www.netservicesgroup.com

gkrellmd problem

Andreas Hauffe — 2011-12-09T09:09:32

Dear Gkrellm developer,

we have a problem with gkrellmd. We use gkrellm to check if a computer idles and can be used for calculations. On each computer gkrellm is startet with:
/usr/bin/gkrellmd --pidfile /var/run/gkrellmd.pid --user nobody --group nogroup --max-clients 50 --update-hz 4 --port 19150 --allow-host 192.0.0.* --io-timeout 0 --reconnect-timeout 0 -d

Then up to six or seven people open there gkrellm client and connect to that server (gkrellmd). After some time the gkrellmd server seems to leak. For up to 30 second the client will get no information. Atfer data is send to the client for about 5 seconds and so on.

What could be the problem? A reconnection of the client doesn't resolve the problem. Only a restart of the daemon.

Best regards
Andreas Hauffe

----------------------------------------------------------------------------------------------------
Technische Universität Dresden
Institut für Luft- und Raumfahrttechnik / Institute of Aerospace Engineering
Lehrstuhl für Luftfahrzeugtechnik / Chair of Aircraft Engineering

01062 Dresden
Germany

phone : (++49)351 463 38496
fax : (++49)351 463 37263
mail : andreas.hauffe< at >tu-dresden.de
Website : http://tu-dresden.de/mw/ilr/lft
----------------------------------------------------------------------------------------------------

______________________________________________
Gkrellm mailing list
gkrellm< at >lists.netservicesgroup.com
Read archives-join-leave-set RSS feed:
http://archive.lists.netservicesgroup.com
This service is provided by The Network Services Group:
http://www.netservicesgroup.com

Re: Bug#630117: gkrellm: Incorrect battery level

Sandro Tosi — 2011-10-31T10:20:00

forwarded 630117 gkrellm< at >lists.netservicesgroup.com
thanks

Dear Gkrellm maintainers,
could you please look into this bug report from a debian user?

Cheers,
Sandro

On Thu, Sep 1, 2011 at 16:08, Christophe TROESTLER
<debian00+list< at >aliceadsl.fr> wrote:

Re: Re: Bug#638646: Could be built without gcrypt dependency

Stefan Gehn — 2011-08-27T15:06:55

Heya,

The hard dependency on Libgcrypt has been dropped in git commit
752e5965b197d70a9125dc3319a8c5e5673a8f8b and will be part of GKrellM 2.3.6.

FYI, GKrellM recently got a public git repo which is available at
http://git.srcbox.net/gkrellm

Bye,
Stefan

______________________________________________
Gkrellm mailing list
gkrellm< at >lists.netservicesgroup.com
Read archives-join-leave-set RSS feed:
http://archive.lists.netservicesgroup.com
This service is provided by The Network Services Group:
http://www.netservicesgroup.com