Yasp-Scripted (Systemmonitor) v1.0.8a

Plasma 4 Widgets

Source (link to git-repo or to original if based on someone elses unmodified work): Add the source-code for this project on opencode.net

24
8.2
Description:

Yes, Yet another systemmonitor plasmoid.
But still different from the others.
The only useful plasmoid systemmonitor i have found was Yasp. The problem with it was that it was not configurable enough.
So I came up with the idea, that everyone has its own imaginations of what belongs into a systemmonitor and what not. The birth of Yasp-scripted.
The name is similar to Yasp, because I use some modified code from that project.
The biggest advantage is that you can add things to the monitor or remove some, by just changing the script file and reparse it again...) No recompilation or something like that needed...
The scriptfile which comes with this applet is a scriptfile which fits exactly my system. You probably need to change it to fit your system (e.g. if you do not have a wireless lan card, you need to remove the wlan stuff from the script file).

You can send me your script, such that I can upload a whole bunch of scripts, the user could choose of later (maybe with a screenshot to see directly what the script does)

The scripts can be found in the directory yasp_scripts.
The 1st screenshot is systemmonitor_by_mtr.script, the 2nd screenshot is systemmonitor_by_patkoscsaba.script
and the 3rd screenshot is the script collection by duncan
(thx for the scripts).

If you want to align things, you should either use a monospace font, or use a t in the value.

If you are familiar with svg you maybe will create your own svg's for the bar-meter. Send them please to me to have a wider range of look and feel for the system monitor ;)
Last changelog:

8 years ago

1.0.8a - wrong folder prefix ;)

1.0.8 - bug fixed when reparsing (the kde-plasma-handle was deleted, but we should not delete it)

1.0.7 - bug fixed if engine-sensors contains a colon
- Added script by joseph (thx for the script)
- New script by aldo (thx for the script)

1.0.6 - stack keyword added to plotter (thx Chris99 for the patch)
- Script by mtr added (thx for the script)

1.0.5 - fix crash on reparsing in kde-4.5.2 (with 4.5.2 reparsing works again, but 4.5.1 and 4.5.0 have a bug)

1.0.4
- Label preferredSize setting correctly + sizePolicy changed

1.0.3
- meter sizePolicy changed (works now better in KDE-4.5)
- bugfix for KDE-4.5 such that it does not crash on removal

1.0.2
- workaround for problems with KDE-4.5 and meters (min_height parameter added)
- added script by aldo to the package (italian labels)
(- known issue: yasp-scripted crashes on reparsing in kde-4.5. This will be fixed in a later release)

1.0.1 - bug fixed if yasp is closed while parsing the script

1.0: - Reparsing should be more stable

dnarol

7 years ago

In KDE 4.6.5 for root partitions usedspace, use systemmonitor:partitions//usedspace:value instead of systemmonitor:partitions/root/usedspace:value and it works.

Report

EazyVG

8 years ago

Sorry for a stupid question, but do I install this, I like the 1st one and have openSUSE 11.4 with KDE 4.6.

Second: What I do to refrect quad core cpu info, if you can explain this perhaps the rest I will get it, as used to manually script for superkaramba.

Thank you.

Report

DuncanKDE

8 years ago

Installation:

For technical reasons, plasmoid binaries often must be built from sources to work with your specific distribution. That's the case here.

Download (and untar) the tarball, then, as is traditional for source tarballs, there's an INSTALL file included, with instructions. The assumption is that you already have a standard working development toolchain installed, plus cmake, standard for kde. If you don't, you'll likely have to install cmake and gcc, and possibly a few *-devel packages for kde related dependencies. (FWIW, I run Gentoo here, where the assumption is from-source, so such things are normally installed already, but I ran Mandrake 2001-2004, and remember well having to install various extra *-devel packages if I wanted to do anything from source.)

Yasp-scripted vs. superkaramba:

You mention that you're already familiar with superkaramba. =:^) That's a *huge* bonus, and yasp-scripted scripts should in fact look quite familiar indeed, as you'll quickly discover that yasp-scripted is in practice a mini-karamba, very similar, but with a rather simpler and thus somewhat less powerful syntax.

Which brings up the logical question: Since plasma natively supports superkaramba themes and you already understand it, why would you be interested in the simpler but less powerful yasp-scripted, given that it requires building and installing an additional plasmoid while superkaramba support is plasma-builtin, and yasp-scripted is in fact less powerful? (Yasp-scripted doesn't yet support theme/script nesting, for instance, and lacks superkaramba's positioning language features, so positioning is vertical-only, controlled by the order in the script. The horizontal positioning in the third screenshot (from me), is because I'm running multiple yasp-scripted plasmoids, lined up in a row on the same panel.)

Here, I used kde3's ksysguard to track system performance, and found the kde4 version buggy and unsuitable for the purpose, so when I switched to kde4, I needed something quickly to fill the gap. I researched superkaramba and in fact will probably upgrade to it eventually, but found its learning curve a bit too steep for immediate use when I switched. Yasp-scripted, having a simpler scripting language but still powerful enough to do the reporting I needed and more, was the easier "quick" solution, and I expect having learned it will greatly help when I upgrade to superkaramba. So it worked great for me and I in turn have tried to help others with it here as I can.

But I don't really understand what it would offer to someone already comfortable with superkaramba, especially since superkaramba support is already native to plasma, just (script if necessary and) install the appropriate theme, while yasp-scripted requires the additional binary plasmoid build and install, as well.

But since I'm coming from the yasp-scripted side, perhaps I'm missing something. Thus I'm not just asking the question for you, but for me too, as I always considered superkaramba the ultimate solution, for those who knew it, both because I believe it more powerful, and because of its native plasma support. If you see something in yasp-scripted that superkaramba can't do, I'd definitely like to know about it, as it could change my viewpoint and ultimate goal to learn superkaramba substantially.

Runtime script configuration:

As with superkaramba, yasp-scripted (mostly) simply provides a framework for the the graphical display and reporting of various scripted elements. A key thing to remember with both superkaramba and yasp-scripted is that neither one create their reports "out of thin air" as it were; they both require the data to be available elsewhere in the system. All they do is take that data from elsewhere, massage it a bit for graphical presentation, and then present it in the form chosen by the script/theme author.

You ask specifically about quad-core CPU info. I don't know as you didn't say, whether you're thinking about core-temps (°), simple use vs idle (%), more complex user/system/nice/wait/total vs idle (%), cpufreq (MHz/GHz), or... but all these are available on various system sensors if so configured for your system, and thus available to be presented by yasp-scripted and superkaramba. At least yasp-scripted (IDR for superkaramba) exposes some of these from the ksysguard/kde-systemmonitor engine... these are the same values available in ksysguard/kde-systemmonitor, with availability conditional on it understanding how to get them. However, that's just arguably the simplest method of getting the numbers. If the ksysguard/kde-systemmonitor engine doesn't understand the numbers, yet they're available as text elsewhere in the system, say from the "sensors" or "acpi" commands at the CLI and/or as exposed in files located in /proc or /sys, they're still available to yasp-scripted (and I believe superkaramba), which can take the STDOUT of various commands or command-pipes (using grep/sed/awk/cut/head/tail/etc as necessary), do math on it if necessary, and present the formatted output as text or as bar or line graphs.

What method you use to get that info will to some extent be system-specific, but you can check the scripts in the "duncan" subdir for how I got both temps and detailed user/system/nice/wait/total percentages, on my dual dual-core main system (dual Opteron 290s, each dual-core). The third screenshot includes the output from these scripts.

Since then, I've setup similar scripts on my Atom based netbook, line-graphing and text-reporting CPUFreq, which wasn't applicable on my main system. I also graph and text-report on battery status, if that's of any interest. But I've not turned that in, so ask if you're interested in that.

So while the answer is somewhat system-specific, you've a good likelihood of being able to grok it and figure out what changes you need for your system, if any, from one of the existing sample scripts... *PROVIDED* the numbers are either exposed in the ksysguard/kde-systemmonitor engine, or that you grok bash scripting well enough to figure out what's going on in the sample scripts and modify it as necessary. If you don't understand bash and it's not available in the ksysguard/kde-systemmonitor engine, then it'll be tough figuring out. But if you're familiar with superkaramba, you still might manage to do it, with a bit of muddling.

Report

64BitRulz

8 years ago

Hi,

First, thanks for a great plasmoid it's been working well for weeks. Now, suddenly, it cannot parse systemmonitor:partitions/root/freespace:value and simply freezes at this point. The same line for systemmonitor:partitions/home works fine which appears after this in the script. I am simply commenting out the root entries for now. Any ideas why this might be happening? I can't think of anything that has changed on my system.
Thanks in advance.

Report

C

finkandreas

8 years ago

I have no idea what happened there.
Can you start plasmaengineexplorer and check the systemmonitor dataengine? That's a good starting point to find the cause of your problem.

Report

64BitRulz

8 years ago

Thanks for the suggestion. I have been playing around with plasma engine explorer as you suggested. I see no entry in the partitions list for / or root only home and backup which I am able to read. How do I get it to see the / or root partition? Any idea why it could previosly see it but now cannot?
TIA
Dave

Report

DuncanKDE

8 years ago

It's a bit of a long shot as I'm not sure this info is affected and I'd normally think not, but... Did you possibly update your kernel recently?

The kernel folks have been strengthening "information leak" protections due to potential security issues recently (2.6.38, possibly 2.6.37), with the specific behavior being that certain values now appear as zero unless queried by root. I don't /know/ that partition sizes are affected, but it's possible.

Does running the "df" command from a shell (konsole window) report usable values? What about if you run it as root (su/sudo/whatever)? If a root df returns valid info but a user df only returns valid info for /home, not /, then we've found the problem -- stricter permissions on the / data. There should be a kernel option available to loosen those restrictions if indeed that's the problem. If not...

Report

64BitRulz

8 years ago

Hi Duncan

I am running kernel 2.6.37.2-15-desktop which comes from the Tumbleweed repository on openSUSE 11.3. The df command shows the following:
dave@opensuse113:~> df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda4 243668872 89560596 141730600 39% /media/backup
/dev/sdb1 240362656 76351556 151801300 34% /home
dave@opensuse113:~> sudo df
root's password:
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda4 243668872 89560596 141730600 39% /media/backup
/dev/sdb1 240362656 76351612 151801244 34% /home

which as you can see is the same for both the normal user and root. However, I will see if I can track down any settings that may affect the lack of / info as you suggest. In the mean time, are you aware of what permissions may be set and where?
Thanks for your input.
Dave

Report

DuncanKDE

8 years ago

As you note, the df for both root and user is the same, so that's not the problem. However, did you note that the / partition is missing there, too?

That suggests one of two things to me. Most likely, the rootfs remount stuff in your initscripts (or possibly simply the /etc/fstab entry for it) is screwed up, so the only root mount is the default rootfs mount, likely read-only, that the kernel does first, before starting any userspace (well, an initramfs/initrd changes that a bit, but anyway...). cat /proc/mounts (mount itself may report invalid info if inittab is stale due to read-only mounted rootfs). There should be TWO entries for /, the generic "rootfs" entry from the initial kernel mount, and if the system's remounting it correctly, a /dev/root entry that lists the real filesystem type (ext4 or whatever, I've used reiserfs here for years and will probably do until I switch to btrfs) and real mount options. If the second entry is missing or has strange mount options listed, that's probably why neither df nor kde can find it.

The other possibility would be some strange interaction with SELinux, AppArmor or similar security mechanism. That's well beyond me and the chance is rather small, but it's there if you're running such things, particularly with SELinux, which few enough people properly understand that most simply turn it off if it starts giving them problems.

I'd bet on the missing remount, tho, so the system doesn't see / in ordered for either df or kde's sysengine to be able to list it.

Report

64BitRulz

8 years ago

Hi Duncan

Thanks for all your help. I've actually fixed the issue. It appears it was simply a disparity in a start up script somewhere (don't exactly know where, but not bothered at this point :-) ). I did some more updates from the Tumbleweed repository that I mentioned earlier. This has fixed the issue and all is now functioning as it used to.

Again, many thanks for your help and insights, they actually provided me with the clue as to what may have happened.

Cheers
Dave

Report

64BitRulz

8 years ago

Hi Duncan,

Thanks for taking the extra time on this small issue. Unfortunately I'm a little out of my comfort zone at the moment. However:
cat /proc/mounts
rootfs / rootfs rw 0 0
devtmpfs /dev devtmpfs rw,relatime,size=2022132k,nr_inodes=505533,mode=755 0 0
tmpfs /dev/shm tmpfs rw,relatime 0 0
devpts /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0
/dev/sda1 / ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
obexautofs /mnt/host fuse.obexautofs rw,nosuid,nodev,noexec,relatime,user_id=0,group_id=0 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
/dev/sda4 /media/backup ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
/dev/sdb1 /home ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
obexautofs /mnt/host fuse.obexautofs rw,nosuid,nodev,noexec,relatime,user_id=0,group_id=0 0 0
proc /var/lib/ntp/proc proc ro,nosuid,nodev,relatime 0 0

Are the 2 root entries you expect to see there? I think they are from your description but it would be great if you could confirm. I have rebuilt the initrd just in case and rebooted prior to running the cat command above. The situation still remains the same. If I am missing something here then a pointer to the relevant documentation or action I could take to resolve would be great. I really appreciate the time you are taking to assist.
Best regards
Dave

Report

C

finkandreas

8 years ago

The systemengine is part of KDE and not part of yasp-scripted. I have no idea why it does not recognize your root partition anymore, but your home partition is recognized correctly.
Maybe you find sth in the kde bugzilla (search for systemmonitor dataengine), and if nothing is there, you could file a bug there.

I have no idea, why it does not work for you, but you could workaround it, by using the command "df" and parse the output...

Report

rangerGR

8 years ago

You have named the folder yasp-scripte instead of yasp-scripted.

Not big deal, but my PKGBUILD failed till I fixed it ;)

Thanks for the update

Report

C

finkandreas

8 years ago

Thx for report, I uploaded a 1.0.8a.
Unfortunately I had to pick a new version, coz kde-look.org does not allow to replace with the same filename...

Report

rangerGR

8 years ago

That was quick
Thanks again

Report

2handband

8 years ago

One other small thing; I can't figure out the syntax to cahnge the size of the display. I want to make it wider and a little bit taller.

Report

C

finkandreas

8 years ago

How about just resizing it? hover over the plasmoid, then the kde-plasmoid-bar should appear next to the plasmoid. Resize it. Finished.

I just realized, that there seems to be a bug in my plasmoid. After reparsing the script the kde-plasmoide-bar does not appear again. So you maybe need to restart your kde (or remove the plasmoid, and add it again, or restart plasma-desktop, or ...)

Report

2handband

8 years ago

Okay, another problem, one that's a showstopper unless you've got a solution. Reparsing the script, or logging into a session, causes plasma crashes. The screen goes completely black. i'm running KDE 4.6 on Arch.

Report

C

finkandreas

8 years ago

Some additional information to what duncan has already said:

- Try compiling it in debug mode, and get a backtrace. This is some information, I can work with. Telling me that it crashes on reparsing, is not really helpful, since I don't even know, if it always fails, or just from time to time.

- I think that starting with KDE-4.5 all plasmoids work in their own thread, so a stalling yasp, shouldn't stall your desktop (maybe you can configure it somewhere, I don't know exactly)

Report

2handband

8 years ago

Okay, fixed this one; it stemmed from an imperfect understanding of the script syntax.

Report

DuncanKDE

8 years ago

Two points:

1) I don't understand why, when everyone else (well, at least the browsers) are going separate processes in ordered to keep one applet/plugin from crashing the entire thing, plasma was /still/ designed with everything in the same process, even the same thread, so if one plasmoid crashes, it crashes the ENTIRE thing... if one stalls, it stalls the entire thing! It /does/ save memory, but come on, we're not running MS WormOS 3.1 with shared memory in 4 megabytes of RAM any more, and there's a /reason/ the browsers are spending all that work separating things from each other! </rant>

But at least in theory if it's actually crashing, there's another component of kde that's supposed to notice it and restart plasma automatically. I started noticing that with 4.5 and while I'm not sure 4.6 has crashed on me, it should be the same. So what I think is happening is that plasma is stalling, NOT crashing, stalling, waiting for something.

Which is where #2 comes in...

2) I've had yasp-scripted (and therefore all of plasma, due to the design I was ranting about above) stall out on me when I made a mistake, in my case a typo in a plotter use= phrase, so it pointed at a sensor name that didn't exist. When it tries to use a sensor that doesn't exist, it apparently locks up, thereby locking up all of plasma.

Try this to troubleshoot (it's what I did to find the problem line): First, start a konsole so you have somewhere to type commands when plasma goes haywire on you. Then, edit the script, commenting (leading #) each line. You should be able to then start plasma-desktop with the (now all comments) script running. You can then quit the desktop again. (I like the traditional killall plasma-desktop, the kde-specific method is kquitapp plasma-desktop, you can type it in the konsole window you opened.) Then edit the script, uncommenting /just/ the sensors (nothing using them, so no plotters, meters, values, or text lines using a sensor), and try running plasma-desktop again. My experience has been that sensors lines (at least as long as they don't use other sensors) shouldn't cause a stall, even if the command fails for whatever reason, because yasp-scripted is designed so it /should/ work around unresponsive sensors (if there's a typo in the line, causing bad format, say a missing set of quotes, that might still cause it). If that does NOT work, go back and try each individual sensors line until you find the bad one. If it DOES work, start uncommenting the plotters, values, etc, one or a group at a time, until you find the bad one.

As I said, it happened to me. I'll bet you find a bad line, and upon examining that line, you find a typo or something, possibly a use= pointing at a non-existent sensor (abbc instead of abc, or abcd instead of ab.cd, or the like, that was the problem I had, simple, stupid typo). Correct that and you should be in business. =:^)

Report

2handband

8 years ago

Hi, I just installed yast-scripted and it looks great! I'm using the systemmonitor_by_patkoscsaba.script script with a few slight modifications. Only problem I have is that my CPU temps are not showing up; there's no error messages, but no values appear in the appropriate places, either. I'm running an AMD Athalon II X2 245 processor. Is there something I can do to the script that'll make my CPU temps display?

Report

C

finkandreas

8 years ago

As duncan already mentioned it, you first need to find out, how you can get the temperature information on your computer. Yasp-scripted is in no way a magic box, which does work for you. It is a program which prints information on the desktop, but how the information is obtained has to be regulated by the user.

That said, you can try if you have lm_sensors installed, and execute the binary "sensors" and watch its output.
On modern kernel (and I think you as arch user, are on a modern kernel), you can look in /sys/class/hwmon, if you finde something that has temperature information.
For example this command-line will get the core temperatures on my laptop:
'cat /sys/class/hwmon/hwmon[01]/device/temp1_input'
The commandline can be very different for your computer, just checkout what directories you have in /sys/class/hwmon.

Report

2handband

8 years ago

Okay, I got it working. The problem had more to do with my very mediocre scripting skills than anything else. I really like this widget; great job!

Report

DuncanKDE

8 years ago

The command he uses for CPU temps is "sensors", piped to grep, etc, to filter it to just the desired coretemp data.

"sensors" is part of the lm_sensors package. Do you have it installed and configured, so that running it from a command prompt produces a bunch of output including the coretemps? If not, you won't get anything for that and might as well comment those lines (or install and configure the package). You'll also need the appropriate kernel modules available. They may be available by default or installed as dependencies of lm_sensors for many distribution kernels, but if you build your own kernel, you may well need to go into the kernel config and turn on the appropriate drivers, either as built-in or as modules (which would then normally be loaded by the lm_sensors initscript, once it's configured).

HOWEVER: Many modern laptops (and presumably more modern desktops than mine, as well) don't actually need or use lm_sensors, instead using acpi based information, directly. My netbook doesn't have lm_sensors installed, tho it does have specific kernel drivers for that model of netbook, but cpu speed, temps, battery, etc, are all available, using other commands.

Bottom line. That's system-specific configuration. You'll need it configured for your system before it'll work.

Report

8 years ago

1.0.8a - wrong folder prefix ;)

1.0.8 - bug fixed when reparsing (the kde-plasma-handle was deleted, but we should not delete it)

1.0.7 - bug fixed if engine-sensors contains a colon
- Added script by joseph (thx for the script)
- New script by aldo (thx for the script)

1.0.6 - stack keyword added to plotter (thx Chris99 for the patch)
- Script by mtr added (thx for the script)

1.0.5 - fix crash on reparsing in kde-4.5.2 (with 4.5.2 reparsing works again, but 4.5.1 and 4.5.0 have a bug)

1.0.4
- Label preferredSize setting correctly + sizePolicy changed

1.0.3
- meter sizePolicy changed (works now better in KDE-4.5)
- bugfix for KDE-4.5 such that it does not crash on removal

1.0.2
- workaround for problems with KDE-4.5 and meters (min_height parameter added)
- added script by aldo to the package (italian labels)
(- known issue: yasp-scripted crashes on reparsing in kde-4.5. This will be fixed in a later release)

1.0.1 - bug fixed if yasp is closed while parsing the script

1.0: - Reparsing should be more stable

12345678910
123
product-maker domryba Apr 16 2015 9 excellent
product-maker LeifErikson May 29 2013 9 excellent
product-maker XenoPL Nov 01 2012 9 excellent
product-maker Sweyn78 Aug 27 2012 9 excellent
product-maker matafleur Mar 05 2012 9 excellent
product-maker gerstavros Jan 15 2012 9 excellent
product-maker Heart Nov 14 2011 9 excellent
product-maker momonster Jul 02 2011 9 excellent
product-maker superpepo Jun 18 2011 9 excellent
product-maker yield65 May 29 2011 9 excellent
product-maker marcotangaro Mar 24 2011 9 excellent
product-maker theZest Feb 28 2011 9 excellent
product-maker bugmenot1234 Feb 27 2011 9 excellent
product-maker rangerGR Feb 25 2011 9 excellent
product-maker schleby Feb 14 2011 9 excellent
product-maker phiga2 Feb 11 2011 3 bad
product-maker srog Feb 01 2011 9 excellent
product-maker opera1818 Dec 17 2010 9 excellent
product-maker cialdo99 Nov 18 2010 9 excellent
product-maker deabru Nov 07 2010 9 excellent
product-maker schnelle Nov 05 2010 9 excellent
product-maker Vzlom Oct 27 2010 9 excellent
product-maker vatsok Oct 21 2010 9 excellent
product-maker SeaJey Oct 07 2010 9 excellent
product-maker Count: 4 Rating: 5.0

domryba

Apr 16 2015

xrooters

Jul 13 2013

LeifErikson

May 29 2013

XenoPL

Nov 01 2012

despot77

May 28 2012

Fred6681

Jul 02 2011

yield65

May 29 2011

marcotangaro

Mar 24 2011

extra

Nov 09 2010

Contrast

Aug 21 2010

poelzi

Feb 25 2010

hellblade

Feb 16 2010

Franksuse64

Feb 02 2010

DaiVied

Dec 19 2009

nicollivier

Dec 02 2009

Droopy159

Nov 18 2009

SeaJey

Nov 03 2009

Sibob

Nov 03 2009

DuncanKDE

Oct 22 2009

kanutron

Sep 18 2009

t3ddy

Sep 04 2009

Montblanc

Aug 28 2009

NForce

Aug 10 2009

Havoc65

Jul 31 2009
File (click to download) Version Description Downloads Date Filesize DL OCS-Install
Pling
*Needs ocs-url or ocs-store to install things
Details
license
version
1.0.8a
updated Feb 25 2011
added Jul 31 2009
downloads today
0
page views today 9