Hello:

Hmm ...
Please check the thread, specifically my second post:

chris2be8's suggestion to chmod 755 /var/log/lost+found could not be easier to implement as it stops the error messages generated by conky by allowing it to access the file.
These error messages were the sole cause of the huge .xsession.errors bloat, so it seems to me that it is the simplest solution. (as always, YMMV)

The crontab solution you suggest controls the size of the .xsession.errors file but generates another set of logfile entries (three lines in auth.log instead of the single line in .xsession.errors we had before) every time conky tries to read the file (every 2 sec.), so it actually makes things worse.

The alternative to stop logging sudo access to auth.log (would not know how to do it) does not seem healthy.

In any case, I set it up because it is a good idea to keep the .xsession.errors file at bay, in my case at 30 minute intervals, a max of 2Gb and min of 1000 lines which would seem to be more than adequate.

Thanks for your input.

Cheers,

A.

Hello:

I see ...

OK

Fortunately I recently learned (here) how to properly generate a sudoers file.
Done.

Just to check:

groucho@devuan:~$ conky
conky: desktop window (1800003) is subwindow of root window (728)
conky: drawing to desktop window
conky: No compatible double buffer extension found
conky: drawing to single buffer

Now my .xsession-errors file will not get filled up with 18Gb of '/var/log/lost+found': Permission denied errors.

Edit:
This solution, neat and efficient, has nevertheless spawned another log overpopulation problem:

Every time

exec sudo du -sch /var/log

is run (every 2s), three lines get written to auth.log.   
This makes absolutely perfect sense as it's exactly what auth.log is for but it also means that auth.log will grow three times fraster than .xsession-errors grew. (!)

Oct 13 12:17:49 devuan sudo:  groucho : TTY=unknown ; PWD=/home/groucho ; USER=root ; COMMAND=/usr/bin/du -sch /var/log
Oct 13 12:17:49 devuan sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Oct 13 12:17:49 devuan sudo: pam_unix(sudo:session): session closed for user root
--- snip ---

I think I may have seen a fix for this but I'll have to look and get back.

In the meanwhile, do you have any ideas as to how to cope with this?
I will temporarily go back to where I was before the fix to conky to keep log growth at bay.

Thanks in advance.

Best,

A.

Hello:

I sort of toyed with the idea before I realised it was way over my head.

I have the code that came with the *.deb I once downloaded.

Yes.
It seems to have been abandoned.

I once contacted the developer/maintainer/website and at first it seemed that something would happen, maybe just the necessary update so that it would be useful again.
But that did not go through.

Blackberry Desktop was only available under MSWindows and unbelievably did not have an address book, so you were stuck with syncing to POS Outlook Express and nothing else.

The grace of this very simple Barry Desktop app was that you could download -> edit/modify -> upload/sync the address book/contact information and even make a backup under Linux.
Maybe that was the reason it was dumped?

I recall that there were a set of libraries (OpenSync?) that stopped working at some time so that was a problem for some part of the app, but the download -> edit/modify -> upload/sync for the addrerss book worked fine.

Edit: (5' and some memory juggling later)
I now recall that the problem was with the syncing libraries due to the demise of the OpenSync framework (or something to that effect).
But you could browse, modify and save the contact database to the unit as well as make a backup so it was really very useful.

I don't get it ...
My trusty Palm IIIxe is still running strong and if anything breaks or I happen to lose it, I have an extra one + a box of full spare parts to put one together in under 20' if needed, just need 2xAAAs.

And j-Pilot is mature and still going strong at v1.8.2 with a great following.

As for the 9320 Curve, I just cleaned up three years worth of grime and replaced the case.
Good as new.

But it seems that I'm stuck with doing the XP/OE/BBD dance in my Devuan VBox.

Thanks for your input. 

A.

Hello:

Thanks for the fast reply. :^ )

I see.
I would have thought it was read from 'somewhere' in the filesystem.

Not to mention that the issue would rise once again on an update of said binary.

Done.
Not what I sought to do but it works.

groucho@devuan:~$ cat /var/log/Xorg.0.log | grep -i ww
[   509.446] xorg-server 2:1.19.2-1+deb9u2 (https://www.debian.org/support) 
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   509.447] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
[   509.447] (WW) Disabling Keyboard0
[   509.447] (WW) Disabling Mouse0
[   509.500] (WW) Unresolved symbol: fbGetGCPrivateKey
[   509.500] (WW) NVIDIA: The Composite and Xinerama extensions are both enabled, which
[   509.500] (WW) NVIDIA:     is an unsupported configuration.  The driver will continue
[   509.500] (WW) NVIDIA:     to load, but may behave strangely.
[   509.500] (WW) NVIDIA: Xinerama is enabled, so RandR has likely been disabled by the
[   509.500] (WW) NVIDIA:     X server.
[   510.975] (WW) NVIDIA(0): Not registering RandR
[   511.046] (WW) NVIDIA(1): Not registering RandR
[   511.174] (WW) NVIDIA(2): Not registering RandR
groucho@devuan:~$

groucho@devuan:~$ cat /var/log/Xorg.0.log | grep fonts
	/usr/share/fonts/X11/misc,
	/usr/share/fonts/X11/cyrillic,
	/usr/share/fonts/X11/100dpi/:unscaled,
	/usr/share/fonts/X11/75dpi/:unscaled,
	/usr/share/fonts/X11/Type1,
	/usr/share/fonts/X11/100dpi,
	/usr/share/fonts/X11/75dpi,
groucho@devuan:~$ 

Nah !

I fully agree that the warning is indeed harmless.
But I am one of those people that opine that if the warning is there, it is because whoever wrote the routine thought it best to put it there and label it as a warning (WW) and not as default setting (==), for example. So it should be taken care of.

These things are like dust: harmless but eventually they pile up too high and then they clog up something.

We're always bitching when some routine goes south and there's no indication of what went on.

Thanks for your input.

Cheers,

A.

Hello:

Welcome and thank you. :-)

OK.
Nice sampling.

Seems something common then?

I went Ubunbtu -> Mint --> CrunchBang --> PCLinuxOS, allways two at the same time and got here for the same reasons with the exception of # ! which Newborough (developer) gave up on. 

So I plan to stay here for the long run.

Same here.

But there's a problem at boot time, right before the desktop comes up: on two of my three monitors I get artifacts made up of a sort checkerboard type design in black, grey and white square/rectangular portions of different sizes which last a few seconds.

Apparently no big deal but it is rather annoying.

I think it is (?) a problem with the package or the driver version used in the package because I did not get them (error in dmesg or artifacts) when I ran PCLinuxOS on this same rig. ie: exactly the same hardware but using Mate instead of Xfce.

Do you get any artifacts like the ones I am attempting to describe?
Maybe it's an issue due to the three monitor setup?

Ideally it would be good to know the origin of the error and act upon that.

Thank you very much for your input.

Cheers,

A.

Hello:

Well ...

1.

2.
Once I found out that the one I wanted was Firefox-55.0.glibc2.3.4-x86_64, I went looking for it but the repo jumps from 52.9 to 60.4.

That's about it.

Cheers,

A.

Hello:

I've checked the release notes.
In particular, the part that refers to "Session management and policykit backends"

I was able to verify that my installation complies with all the requirements ie: the "recommended default
combination of login manager (either slim or lightdm) and session management system."

As to "Starting X from a console (TTY)", although I was being able to do it in the manner described ...  (in spite of having consolekit and not elogind installed)

... it was with the Shutdown and Restart options being greyed out, probably the effect of not having elogind installed.(?)

So I just in case, to comply with the Release Notes requisites, I installed SLiM (which I had previously removed) and reinstalled consolekit, in case it had become mucked up somehow.

The consequence was that the working desktop described above recovered the ability to Shutdown and Restart from the panel. =-)

Afterwards, looking closely at the screen output for a few reboot cycles made me aware of an issue regarding one of the services I had not been able to start.
The thread can be read here

It turns out that the service checkroot-bootclean.sh was failing to execute properly and, not seeing anything else that could have been giving me trouble, I went for it.

Being a script that apparently runs at boot and then exits (?) does not seem like a service to me, it looks more like what it is: a start up script.
No wonder querying it with service --status-all | grep -i checkroot- did not list it as running and me making a fuss over that.
Shouldn't there be a Script Starting Service with a list of scripts to check as needed?

But I digress ...
The fact was that it was being executed at boot and it was failing.

The graphical interface for Services was of no help whatsoever so I looked for the script and edited the .sh in the name. ie: *.sh -> *.old and rebooted.

Sure enough: it was the culprit.
Now I had recovered a fully working desktop.

Which meant that apparently, apt-get clean and apt-get autoclean were not at fault.
At least not this time.

But I was still getting boot time warnings about the bootclean script failing albeit with no apparent ill effects.

I tried to use chkconfig to sort that out, but could not find it: it seems to have been dropped from ASCII (I clearly recall using it in Jesse).

Then I found out about update-rc.d, which was installed.
I thought using it would clean things up for me and that would be it.

So I did update-rc.d -f /etc/init.d/checkroot-bootclean.sh remove but doing so left me without any screen output.  =^/

At that point this whole thing was getting old and I was needing my dose of espresso so I decided to take the easy way out.
But I'm not too happy about that.

I went to my Timeshift folder and recovered all the rcX.d folders in /etc from last saturday's snapshot and after renaming the existing ones as rcX.old, copied the backed up versions over to /etc and that was that. 

Things seem to be back to normal, whatever that is in this installation.

But I'd like to ask a couple of questions, if I may:

1. did I use update-rc.d correctly?
2. was it the proper approach to the problem at hand? ie: to clear out a script that I wanted to stop being run.
3. why can't the script be stopped with the graphical interface  ie: Applications -> System -> Services = [service]

Thanks in advance.

Cheers,

A.

Hello:

I see ...
Sort of like what was once known as (this dates me) CR or 'carriage return'.
Typing machines and telex terminals from long ago.

OK.

OK.

Indeed ...  =-)

groucho@devuan:~$ cat nonewline.txt
this is a test file made with jed without a final new_linegroucho@devuan:~$

groucho@devuan:~$ cat newline.txt
this is a test file made with jed with a final new_line 
groucho@devuan:~$ 

Yes.
But in a very ambiguous manner.
Why not just print "new line character missing"?

Exactly as you say:

1.
edit user_linssid

groucho ALL=(ALL) NOPASSWD:/usr/bin/linssid[cr]  <- this [cr] is the 'new line' character and % is edited out

2. Check with visudo -c

[root@devuan groucho]# visudo -c
/etc/sudoers: parsed OK
/etc/sudoers.d/README: parsed OK
/etc/sudoers.d/user_dmesg: parsed OK
/etc/sudoers.d/user_linssid: parsed OK
/etc/sudoers.d/user_shutdown: parsed OK
[root@devuan groucho]# 

Thank you very much for taking the time to explain this to me.
Much obliged.

Now I'm confident I'll be able to write files for /etc/sudoers.d/ as needed.

Cheers,

A.