Hello:

Sorry for reviving an oldish thread but I just came across your post.
These days I seem to have more time to read unanswered posts ....   =-/

One of the things I like of how Devuan ascii is implemented is how console output is highlighted at boot time and when using commands such as dmesg.
Unfortunately, the output of dmesg | grep whatever gets written to the terminal without any highlighting.

Is there a way to fix/change this so that anything printed to the terminal has the same highlighted output/behaves in the same manner, irrespective of whatever comes after the command line instruction?

It would be nice to have it enabled by default.

Thanks in advance,

A.

Hello:

Yes, but ...

Samsung_M2020_Series groucho 3 [27/Nov/2018:16:41:51 -0300] 1 1 - localhost
Samsung_M2020_Series groucho 3 [27/Nov/2018:16:42:00 -0300] 2 1 - localhost
Samsung_M2020_Series groucho 4 [05/Dec/2018:08:29:39 -0300] 1 1 - localhost
                             | <- print job  page number -> | | <- pages printed

In the example above, we see two print jobs: print job 3 which outputs 1 copy of page 1 and 1 copy of page 2 and print job 4, which outputs 1 copy of page 1.
The awk stanza in my previous post will correctly tally the amount of pages printed, ie: 3 pages.

groucho@devuan:~/Desktop/awkcups$ awk '/groucho/{pages += $7} END {print pages}' /home/groucho/Desktop/awkcups/plog1
3
groucho@devuan:~/Desktop/awkcups$ 

Now, in a different scenario, where we have two digit print jobs with the rest being the same ...

Samsung_M2020_Series groucho 13 [27/Nov/2018:16:41:51 -0300] 1 1 - localhost
Samsung_M2020_Series groucho 13 [27/Nov/2018:16:42:00 -0300] 2 1 - localhost
Samsung_M2020_Series groucho 14 [05/Dec/2018:08:29:39 -0300] 1 1 - localhost

... the awk stanza previously applied gives an incorrect output, ie: 5 pages 

groucho@devuan:~/Desktop/awkcups$ awk '/groucho/{pages += $7} END {print pages}' /home/groucho/Desktop/awkcups/pg1log
5
groucho@devuan:~/Desktop/awkcups$ 

The same problem would arise if a print job is for 20 copies of a single page.

At the risk of stating the obvious, the same awk stanza parses the /var/log/cups/page_log file which (depending on how the printer is used) can have between one and four digits both in the print job number and the number of pages printed. I limit this to four digits because the size of cartdrige 2020W cartdrige won't ever print 9999 pages.   

I can't see how to solve this with awk and have searched all over the web for a script to do basic CUPS accounting to no avail.

Thanks for your input.

A.

Hello:

Yes, but thenI'd be running trim every time I booted the rig, which could be up to three or four times a day.

I'm looking to analyse the /var/log/trim files in a month or so to see what went on and then decide on weekly, monthly or something else.

There's a chap that wrote a daemon for running trim here:

https://github.com/dobek/fstrimDaemon

He argues that it would seem to be "more reliable to execute fstrim based on up time then cron table.".

Thanks for your input.

Cheers,

A.

Hello:

Right. (A bit late in life but I have vowed to try to stop using OK)

I see.

Hmm ...
I'll start looking again to see if I can find out just where it comes from.

I was just about to do that when I found trimmed_log.txt.

--- solved ---

From its content and name, it seemed (to me) that it could have been produced by fstrim.
But it turns out that it is not.   =-)

A search on the web brought up just three hits, one of them from a thread I (!) started here at Dev1.
So it turned out that it was right in front of me/us.

See here:
https://dev1galaxy.org/viewtopic.php?pid=20206#p20206

And here:
https://dev1galaxy.org/viewtopic.php?pid=20211#p20211

It was generated when I was trying to figure out how many pages my M2020W cartdrige had actually printed before running out.
Which I still have to figure out how to awk properly.

Thanks a lot for your input.

Cheers,

A.

Hello:

I posted and went to make myself an espresso which made my head work a bit better.

So:

groucho@devuan:~$ locate trim
/home/groucho/trimmed_log.txt
/sbin/fstrim
/usr/share/bash-completion/completions/fstrim
/usr/share/man/man3/malloc_trim.3.gz
/usr/share/man/man8/fstrim.8.gz
/usr/share/tools/trim26lst
groucho@devuan:~$ 

Seems that the fstrim util is in/part of the Devuan ascii distribution.
And from the locate printout, it also seems that it has been run before.

groucho@devuan:~$ cat /home/groucho/trimmed_log.txt
[30/Nov/2018:10:44:10-0300] 1
[08/Dec/2018:19:12:32-0300] 1
--- snip ---
[17/Feb/2020:13:44:14-0300] 1
groucho@devuan:~$ 

The trimmed_log.txt (which for some strange reason is not in /var/log) only gives date, time and what would be the trim (?).

But ...

I only installed the SSD yesterday, no SSDs before that, so fstrim was working on some other drive.
I speculate that it was on the SAS drive replaced with the Kingston SSD ie: boot drive. (?)

Q:
1. How is fstrim set up and started? 
2. Will it keep working now albeit on the SSD?

Some dates in /home/groucho/trimmed_log.txt are far apart and there are up to 30 entries with the same date (with trims as high as 24 so it does not seem to be a cron job.

So if it is not a cron job, what triggers it to run and how can it be modified?

Thanks in advance,

A.

Hello:

I don't think it is the case here.

Yes, I had read something about that.

I'll see if I can find if there is a utility that can log swap activity (I think I saw one once ...) over a set amount of time, say 30/60/120 days and evaluate the results.
I have enough relatively fast SAS 3.0Gb/sec rust so I could eventually set up an 8.0Gb swap partition on one of them.

Thanks for your input.

Cheers,

A.

Hello:

These two worked a charm.

This string awk '/A4/{print $4$5 " " $6}' /var/log/cups/page_log > trimmed_log.txt got me a list of what would seem to be all the print jobs up to today (172 between 30/11/18 and 13/02/2020). I'd just have to trim the ones up to the cartdrige change/refill.

groucho@devuan:~$ cat trimmed_log.txt
[30/Nov/2018:10:44:10-0300] 1
[08/Dec/2018:19:12:32-0300] 1
--- snip ---
13/Feb/2020:16:57:53-0300] 14
groucho@devuan:~$

And this other one awk '/A4/{pages += $6} END {print pages}' /var/log/cups/page_log gave me what would seem to be the sum of the pages printed (601). 

groucho@devuan:~$ awk '/A4/{pages += $6} END {print pages}' /var/log/cups/page_log
601
groucho@devuan:~$

No spreadsheet, which is a relief even though I would only do this once every so often.

Thank you both for taking the time to help me out with this, I will try harder to spruce up my CLI basics as I am (again, after so long) finding it to be not only interesting but very usefull.
So many years of GUI usage ...  =-/

Once again, thanks a lot.

Best,

A.

Edit:
There seem to be some discrepancies between the actual log and the output from the awk commands.
I'll check and report back.

Hello:

Hmmm ...

The data I'm looking for is the sum of a set of numbers whose values I ignore and are (in this case) listed in 400 consecutive lines, one line per print job.
I don't see how grep could help me.

I thought there could be some script or front end I have not been able to find that would use the log file as input and get the total pages printed.

Thanks for your input.

Cheers,

A.

Hello:

For those (more knowledgeable than I) able to opine, it would probably be important to see the contents/output of cat /etc/apt/sources.list.

Edit:

The output of cat /var/log/Xorg.0.log would be useful also.

Cheers,

A.

Hello:

Indeed ...
But I fear that (eventually) it will get worse.
To me it's just a question of time.

Why?
Because not enough people are paying attention to what is going on.

I've clocked roughly 20+ years of MS software use, ~5 years as a regular -> advanced user, the rest as first -> second tier support and on-site hardware service when needed, all at the different places where I made a living and from home when out of a job.

So my background is not that of a coder/developer or packager but someone who started late but who has seen all this first hand as a privileged/advanced user, like many others here.

IMO, there is a striking parallel between systemd in Linux and the registry in Windows OSs.

Systemd in Linux brings back memories of my difficult transition from W3.11 to W95, with the end of the familiar and usually well documented *.ini files I understood (and could tweak when things went foul) to the obscure workings of *the registry*, which took me a few years to get a minimal hold of, basically through unending trial and error grief.

After a few years (W95 to XPSP3) I understood what it was all about: a developer sanctioned virus running inside the OS, constantly changing and going deeper and deeper into the OS with every iteration and as a result, progressively putting an end to the possibility of knowing/controlling what was going on inside your box/the OS as it became more and more obscure.

When systemd appeared in Debian (I was already running Ubuntu) and saw what and how it did it, I realised that systemd was nothing more than a registry class virus which was infecting the Linux ecosystem at the behest of the developers involved and the complicity or indifference of most of the others.

So I moved from Ubuntu to PCLinuxOS and then on to Devuan.

Paranoid?

No. Just strongly convinced that there are people both inside and outside IT that actually want this systemd takeover to happen and are quite willing to pay shitloads of money to push that agenda, Poettering being a prime suspect but surely not the only recipient.

I don't see this MS cozying up to / barging into Linux and areas of influence (GitHub acquisition, WSLinux (!), etc.) in various ways as a coincidence: these things do not happen just because or on a senior manager's whim.

What I do see (YMMV) is systemd being a sort of a putsch to generate a convergence Windows with or into Linux, which is not good for Linux and will be its undoing.

But there's really nothing new here: it's just the well known MSbrace at work.
It's been going on for more than 30 years.

And no, I don't have an answer to this problem.

But I do think that it would probably be a good thing that the awesome manpower behind all the Linux projects scattered out there team up to find common ground instead of everyone of them wanting to do their own thing while mindlessly waving the flag of choice, a flag which they are set to lose if they do not react fast enough.

The writing has been on the wall for a long time now.
And it's well past the time to heed the warning.

Of course, nothing but my $0.02 and as always, YMMV.

To all Dev1  members/guests: Have a Happy New Year 2020.

Cheers,

A.