You are not logged in.
I'm sorry the title is so vague but I'm 2 character short from writing them both in the title - the forum cuts me off 2 characters before writing both questions as a title.
So,
Question 1: Is there a way to make pacman write its logs by date? For instance, one log for today, one for tomorrow, one for the day after tomorrow and so on till the end of time. The default setting is to put everything in one file which starts from the installation date (28.07.2023) till now and if you need something specific from the log, you could search forever. Separating the log by dates, if that's even possible, will make searching it a lot easier.
Question 2: Is there a way to make the log full? Meaning that it will write in the log every message and every question (and its answer by the user) exactly the way you see it in terminal? At the moment pacman writes only the actions it takes, not the messages and the questions.
Before you ask: I did Google for these things but Google shows me other things related to pacman's log, not what I need. I suspect nobody else has asked such questions and that's why Google can't show me what I need.
Offline
https://man.archlinux.org/man/core/util … cript.1.en
https://man.archlinux.org/man/core/logr … otate.8.en
one log for today, one for tomorrow, one for the day after tomorrow and so on
And what if you run pacman -Syu at 23:58 ?
Offline
And what if you run pacman -Syu at 23:58 ?
That rarely happens at this particular hour and minute but even if it does, it will finish writing the log before midnight. The largest system upgrade I've ever seen was 3 GB which downloaded in less than a minute (56 MB/s during the day, twice that speed from midnight till 12 at lunch) and the upgrade happened much faster than that. That's why I think that even if I run -Syu at 23:58 it will be done before 00:00, thus the log will be written for the same day, not for the next.
As for the links you posted: those look like CLI options. I was thinking more about permanent settings in pacman.conf, so that I won't have to write these options every time I run the upgrade command. That's what I had in mind when I asked the questions.
Last edited by Valso (2024-07-02 14:46:30)
Offline
... if you need something specific from the log, you could search forever.
Why would you search forever? What is an example of something specific you'd want from the log? Don't search forever, just grep, sed, or awk to get what you need instantly.
At the simplest, you can get the logs for a given date already quite simply, e.g., yesterday:
grep '^.2024-07-01' /var/log/pacman.log
Or more literally / generically "yesterday":
grep "^.$(date -d yesterday +%Y-%m-%d)" /var/log/pacman.log
Note though that this can split transactions that span midnight. You can turn pacman.log's date stamps into the start of the transaction time with the following sed script and then pipe that into grep if you need transaction-aware searches (spanning midnight):
sed -n '
/PACMAN/ {
h
s/\].*/]/
x
:loop
s/[^]]*\]//
H
g
s/\n//
p
s/\].*/]/
h
n
/transaction completed/ {
b end
}
b loop
:end
n
}
' /var/log/pacman.log
EDIT:
That rarely happens at this particular hour and minute but even if it does, it will finish writing the log before midnight. The largest system upgrade I've ever seen was 3 GB which downloaded in less than a minute (56 MB/s during the day, twice that speed from midnight till 12 at lunch) and the upgrade happened much faster than that. That's why I think that even if I run -Syu at 23:58 it will be done before 00:00, thus the log will be written for the same day, not for the next.
If you are active at your computer and potentially running pacman *anywhere near* midnight, it is bound to happen. It doesn't matter how fast the transactions are. Sure, if your start at 23:58 your average operation may be done before midnight - but that was just an example. How about if you enter your command at 23:59:59? There will be operations spanning midnight unless you are just never up and on your computer at all near that time.
Last edited by Trilby (2024-07-02 15:10:29)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
The suggestion to this by script does not imply that you need to run it manually.
You could write or use a script or a program that does this for you if there is one, and schedule it to run automatically every day or whatever. You could do that with a systemd timer or as a script that runs on login.
Last edited by Nikolai5 (2024-07-02 15:42:53)
Desktop: Ryzen 7 1800X | AMD 7800XT | KDE Plasma
MacbookPro-2012 | XFCE
Offline
As for the links you posted: those look like CLI options.
They look more like generic ways to log an entire console session (script) or automatically rotate log files (aptly named logrotate)
You'd rarely get this kind of specific behavior with a magic config key for random programs, but as Trilby pointed out - this is mostly an https://en.wikipedia.org/wiki/XY_problem
logrotate (or manual intervention) can help if your pacman log grows out of control and next to grepping the log, you could also try to throw https://lnav.org/ at it.
Offline
If I wanted what you're asking for, I'd write an alias with something like:
sudo pacman -Syu --color=always |& tee pacman-$(date '+%Y-%m-%d').log
Then to read it:
cat pacman-$(date '+%Y-%m-%d').log,
Or get rid of the colored output '--color=always' if you don't want to deal with color coding in the log. There's probably a reason this hasn't been suggested yet though. Perhaps someone can point out any pitfalls?
I'd also avoid cutting up /var/log/pacman.log, because doing so would cripple the capacities of it being one continuous log.
And to add an option for filtering pacman log, there's also 'paclog' in the 'pacutils' package.
Last edited by NuSkool (2024-07-02 18:24:25)
Offline
I already have an alias, I'll just add everything from the symbol | to the right.
I also have an alias for reading the log, so I'll just modify it, if the above works the way I need it.
Nobody has suggested this probably because nobody has thought of it yet. Or nobody needed such a thing, until now. I needed an answer to the second question (making the log full with everything you see in terminal) because of a weird problem I encountered just 2 days ago. I ran the update alias and during the update I saw a message "ffmpeg is removing ffmpeg4.4". Considering neither one is a dependency of the other, I wonder why it would do that. If I had a full log with all the messages/questions I ever saw in the terminal, I could use that to determine why ffmpeg removed ffmpeg4.4. I had to install ffmpeg4.4 manually cuz without it audacity becomes totally useless. I suppose I could add ffmpeg to the ignore list, so that it never updates again (it receives updates rarely anyway), thus avoiding the same thing from happening again, but I'd rather find the reason for which ffmpeg uninstalled ffmpeg4.4 and report it to the "proper authorities".
Trilby, I usually play a game between 6 PM and 3 AM, so the chances of me running the upgrade command at midnight are slim to none.
Offline
Keeping a log of messages sent to the screen as a response to not reading them carefully in the first place just further enables not reading them carefully in the first place.
Storing the full output may indeed provide a solution to some future problem - but only by first creating the problem.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I’d like to note that you don’t have to “search forever”, because even the simplest possible tool has an option to simply jump to a given date. With `less` you just type “/2024-07-01”, press enter, and you are on July 1st, 2024. From that you can either read or continue searching other phrases.
Sometimes I seem a bit harsh — don’t get offended too easily!
Offline
Nobody has suggested this probably because nobody has thought of it yet.
Or because capturing stio/err does not
write in the log every message and every question (and its answer by the user) exactly the way you see it in terminal
as it misses stdin, hence the suggestion to use script.
"ffmpeg is removing ffmpeg4.4". Considering neither one is a dependency of the other, I wonder why it would do that
It would be about "conflicts" or "replaces", neither being the case - please post your complete pacman log.
Offline
Keeping a log of messages sent to the screen as a response to not reading them carefully in the first place just further enables not reading them carefully in the first place.
Storing the full output may indeed provide a solution to some future problem - but only by first creating the problem.
When a message appears on the screen for 1 second and is then pushed out of the screen by another, how do you suggest I read the first message? I'm not Commander Data, I can't speed read.
Btw, that addition starting with " | tee" makes the computer extremely slow while updating. "Running build hooks" lines usually appear 1 line per second but with the tee addition they appear 1 line per 60 seconds, as if I'm still using my first computer of 2005. I guess there's no balance between separate logs and speed.
Offline
When a message appears on the screen for 1 second and is then pushed out of the screen by another, how do you suggest I read the first message?
Scroll up.
And here were getting to the X of the X-Y problem. Feeling like you might be missing something in output flying by is a valid concern to have, and there are many good ways of addressing that concern - scrolling up (in a vast majority of shells/terminal emulators) is the simplest, but only one of many. But starting with the Y-question of partitioning the pacman.log by date really took the thread in other directions that likely didn't get you what you really needed.
Last edited by Trilby (2024-07-03 16:04:21)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Off topic:
Btw, that addition starting with " | tee" makes the computer extremely slow while updating.
No. Coincidence? Can you replicate this? What if you run
sudo pacman -Syu --color=always |& tee /tmp/pacman-$(date '+%Y-%m-%d').log
nb. that the "|& tee" is correct for bash and zsh but will not be supported by all shells (eg. not by fish) and reversing it to "&| tee" is entirely wrong.
Offline