How to keep your /tmp/xerrs.log file small.

[musher0]

~~ Note ~~~~~
Jan. 17, 2015. Since I opened this thread, I concocted a little tool that uses the
less utility and may help you monitor the /tmp/xerrs.log file effortlessly. Please
go to: http://murga-linux.com/puppy/viewtopic. ... ost#821855.
Enjoy! musher0
~~~~~~~~~~~~

Hello, all !

I hope you are having a happy Holiday Season!

The reason for this thread is that I was having some problems with error reporting
to xerrs.log in Slacko-6.0b -- but not only that Puppy, I have had such problems before.

It's not just me, either, since ttuxxx and technosaurus have also complained about
too many errors being logged in xerrs.log, at:
http://murga-linux.com/puppy/viewtopic. ... &start=750

Also argolance at:
http://www.murga-linux.com/puppy/viewtopic.php?t=85700
And many other advanced Puppyists have commented on errors in numerous other
threads on this forum. But I have not found a thread dedicated to the subject.
(flash, please prove me wrong?!) So I thought a specific thread would be helpful.

A word of caution: test before you use your "silencing" solution! Make sure
the script or program works properly with the error-reporting off. because some
programs simply won't.

Remember that the xerrs.log file is designed to be a helper in debugging your
Puppy, in hunting down and resolving any reported error. A xerrs.log that's small
and stays small means that you're a good hunter/debugger... As a result,
your Puppy will run more smoothly, and most likely, a tiny bit faster.

These are only the tricks that I've discovered. There are literally thousands of such
tips scattered over the Internet. You're more than welcome to provide your own tips
and/or adaptations below.

BFN.

musher0

[musher0]

Now for my little list.
~~~~~~~~~~~~~
* Getting numerous "Error: BadWindow blabla"
I realized that I had compiled pekwm-1.15 with the xorg parameter "on". My fault.
This particular compilation of pekwm searches for some xorg parameters in
/usr/share/X11 and doesn't find them,because Puppy's architecture is slightly
different.

I initially thought it might be the X driver for the video card, so I tried the 3 drivers
suggested by xorgwizard for my old card. But tough it out, man, it wasn't the video
card driver...

After hours searching and reading various suggestions about this on the Internet (it
seems to be relatively common on slackware related distros, BTW), it finally struck
me that the headache-free solution was to send any window manager errors to
/dev/null in the /root/.xinit file, like so:

Code: Select all

#
which $CURRENTWM && exec $CURRENTWM &>/dev/null
[ -x $CURRENTWM ] && exec $CURRENTWM &>/dev/null
exec jwm

###END###

Adapted from:
http://unix.aspcode.net/view/6353950870 ... with-binsh
(Found Dec 26 2014 at 11 pm.)

You launch your window manager the usual way, with

Code: Select all

xwin pekwm 

(or whatever WM) and the modified lines of the bottom
of the .xinitrc script take care of (actually cut off) error reporting.

~~~~~~~~~~~~
* Silencing conky output to xerrs.log
We actually don't need it, except the first few times, when we want to make sure
that we have the conky configuration right. After that, we use the -q parameter to
stop conky from always bragging about itself :

Code: Select all

conky -q -c <your.conky.configuration>

(From conky man file)
~~~~~~~~~~~
* Silencing errors not conky's fault!
You may think that there is not much to be done about error messages such as
"/usr/lib/that-lib.so.9 not exactly matching this or that" or whatever. Nevertheless,
this works in the case of conky:

Code: Select all

conky -q -c $CNK/.conky-1l-pek-haut &>/dev/null &

($CNK being a folder for conky configs in /root/.config)

conky itself remains quiet because of the -q parameter (see par. above), and we
finish shutting up its blabber concerning the library error with the universal quieting
trick: "&>/dev/null". Finally, we make sure that the script doesn't stop at this line
by adding an additional ampersand (the "&") at the very end of the line.
~~~~~~~~~~~
(More to come!)

~~~~~~~~~~~

BFN.

musher0

~~~~~~~~~~~
P.S. -- I just re-checked and now my xerrs.log file stays below 3k whereas before
applying the above tricks it was growing up to 75k in about 10 minutes.

[greengeek]

Hi musher - slightly off topic, but I recall reading somewhere that some programs that write to /dev/null run the risk of corrupting some system files. I don't know if that is true or not (I think it was in a thread about using arecord with VU meter...) but is there some alternative way to 'dump' data? Is there a "non-global" devnull like /dev/nullxxxx or /dev/null($random) or something??

[mikeb]

ah not just me then..... I just have xwin using > /dev/null 2>/dev/null...seems happy that way....too many apps seem to want to dump piles of text otherwise...mplayer was a good one for it.

Done if for years and no side effects and don't miss it either.

In real linux xerrs.log should be in /var/log anyway where the useful xorg.0.log resides.

mike

[musher0]

@mikeb: thanks for the comforting "testimony"!

Hi musher - slightly off topic, but I recall reading somewhere that some programs that write to /dev/null run the risk of corrupting some system files. I don't know if that is true or not (I think it was in a thread about using arecord with VU meter...) but is there some alternative way to 'dump' data? Is there a "non-global" devnull like /dev/nullxxxx or /dev/null($random) or something??

Hi, greengeek.

You're not off-topic at all, actually, you're right on!

First time I've heard of a possible damage with /dev/null. First time also I heard of
a "non-global" devnull. I'll research them, but if you could give me a starting URL, it
would be much appreciated.

BFN.

musher0

[greengeek]

First time I've heard of a possible damage with /dev/null. First time also I heard of
a "non-global" devnull. I'll research them, but if you could give me a starting URL

Hi musher0 - my suggestion of a "non-global" dev/null is just an idea bouncing round in my head - its not something that really exists. What I meant was a "localized data dump" - so that a script/program could dump data to its own 'rubbish bin' rather than to a "communal" rubbish bin which might be filled/contaminated or even kicked out of the room entirely by some other user.

The suggestion of damage being caused by improper use of /dev/null is noted in these links:

http://www.murga-linux.com/puppy/viewto ... 890#783890
http://murga-linux.com/puppy/viewtopic. ... 193#373193
http://mail.murga-projects.com/puppy/vi ... e8a#796990
http://www.murga-linux.com/puppy/viewto ... 295#787295


2009 mike! "Long time ago when the earth was green...."

[mikeb]

Ah that old chestnut.... the 'mono' fixed it at the time.

Hmm so one errant binary thats been sorted since..... bit of a one off and /dev/null should be sacred and not be messed up in this way so we can freely use it.... indeed it is very commonly used and 99.9 % of the time its happy.

well remembered by the way.....

mike.

Checked and thee world still seems fairly green out there though I am turning blue...need to cook some hot food....

[musher0]

Hi, guys.

Thanks for the feedback.

@greengeek
Many thanks for the references. I looked them up and they all have to do with one
executable: arecord. Or are there others?

As to creating a localized /dev/null for program x or y, I have to admit that I
wouldn't know how to do that.

Another concern is: is that desirable for general use? Of course, for any kind of
developement, it makes a lot of sense to be able to check what you or your
program are doing wrong in a particular file or folder. My point being that if a
program creates lots of errors, it shouldn't yet be offered to the general public.

@mikeb
Basically, if I re-write your message in my head , you're saying that the arecord
case is the exception to the /dev/null general rule?

BFN.

musher0

[musher0]

This note, for the record, is about bmpanel2, if anyone is interested.

This nice and versatile companion bar to pekwm is a fussy baby... Launched normally,
It complains to the xerrs.log file a lot. For example:

(2.1pre1/panel.c:769) Unknown XEvent (type: 65, win: 8389185)

and on and on and on... 3-4 lines every time you use it. The only thing that changes
is the "win:" number at the end.

Luckily, you can give him this pacifier :

Code: Select all

bmpanel2 --theme=blabla-blue.mod &>/dev/null &

That shuts him up.

BFN.

[mikeb]

Basically, if I re-write your message in my head Smile, you're saying that the arecord
case is the exception to the /dev/null general rule?

yes it appears so..... I might have been the bunny who discovered it... I was playing with the vu meter option of precord so the guilt may be on my head for that one

A bit like the gmplayer crash and puppy menues...a curious on off

mike

[musher0]

[...]
A bit like the gmplayer crash and puppy menues...a curious on off

mike

Oh ? And they complained to xerrs.log, I presume?

[mikeb]

No it just crashed ...reason why the gnome-mplayer was used ....

mplayer in general is quite versose unless you add the loglevel parameter....used to fill my tmpfs which was fun....

mike

[musher0]

First post edited with URL to monitoring script. musher0

[musher0]

Hello.

I had given up on silencing non-errors and simple anomalies in xerrs.log.
But this "arch-linuxian" suggested this, which explains a solution to
partially shut up the verbose "no listen" in xinit. See the last post there.

BFN.

musher0

[mikeb]

Funny you should bring this thread back up.

I was getting tired of endless whining messages in the terminal testing a gtkdialog script...which I assume would have ended up in xerrs if it existed.

These mainly came from glib...after all since gtk devs change functions every time they fart, warning messages have increased exponentially.

so I recompiled glib without warning messages only errors..you know the stuff that actually stops applications working. It worked...silence was golden.

Gtk2 itself also tends to spew them out so will try the same with that.

Now about those doodads warnings and 'oh there will be problems'.....

This was on lucid so I guess that and newer suffer from warning hell...me older distros are much quieter.

mike

[musher0]

Hi, mike.

Here's another one concerning the PANGO UTF-8 warnings. Solution # 1
in that list seems to work for me, mutatis mutandis:

Code: Select all

localedef -i fr_CA -f UTF-8 fr_CA.UTF-8

(instead of the man's original "pt_BR.UTF-8"). Fingers crossed... I did it
a few minutes ago.
You wrote:
> so I recompiled glib without warning messages only errors..you
know the stuff that actually stops applications working. It worked...
silence was golden.

Ahhh...

Looking at it from a psychological standpoint, we shouldn't be too mad:
in a manner of speaking, those verbose messages are a cry for help
from the poor developer.

The same said to the same developer, this time in non diplomatic,
straight language: "Enough of this, beef up your skills, man!"
(Not you, of course, I mean the "actual man" who did the original
compiling!)

And to the ghost of my mother: "No mom, I never wanted to learn
these patches, I just wanted to be a regular computer user." (sob, sob)

I stop -- or my pot will continue cracking...

BFN.

musher0

[mikeb]

Its ok....

actually the error that particularly was bugging me was telling me a function was deprecated...not so bad but the replacement function recommended had also now become deprecated...so the fix would have produced similar warnings anyway...chasing the wind is not my way.

Try a gtkdialog combo box and select an item while observing in a terminal.

To me gtk warnings mean...we cannot make up our minds and we like attention too....


mike

[musher0]

I'd venture to say that the people at gtk are under some kind of WhineDose
voodoo spell... By the time the user has adapted his system, gtk has a
new version that makes the user's work obsolete.

[mikeb]

For the paranoid whats to stop Microsoft having staff join projects such as gtk and mozilla?

mike

[musher0]

For the paranoid whats to stop Microsoft having staff join projects such as gtk and mozilla?

mike

Hi, mike.

Not sure about staff. It would be too obvious.

But what's to stop them from improving their code using opensource.
The name says it all: open source. Anybody, including people at
MacroHard, can read it and pluck from it.

Let's start the rumor that Windows 10 will actually be a rewrite of
Wine... Nah, that can't happen, can it?

My 2¢.

BFN.