Docs mention syslog, GUI refers to syslog, there's no syslog

although it's a bit messy to split discussions between two places like this, my two cents here as well
- the journal is for most intents and purposes the successor of syslog (both in the meta sense, as the default implementation/collector/provider of system logs on Linux, as well as in the most direct sense, since it is backwards compatible and *among other sources* also collects messages emitted over syslog(3))
- "syslog" does not imply at all that aggregation over multiple systems is taking place

the latter was (is?) one of the places where "traditional" (modern ;)) syslog was more featureful compared to journald, and this was one of the reasons why Debian had both enabled by default for a while (first with syslog being the persistent one, then with both, now only with journal in the default config).

but the "central syslog server" feature was never configured out of the box on PVE, the syslog API/UI tab was always node-specific and displayed the local log of that system, so this is only confusing if

- you are used to setting up a central syslog server
- somehow assume PVE would auto-detect this?

which seems kinda far fetched to be honest. if PVE came with such a feature out of the box (unlikely), the logs would not be under the node tab either, but under datacenter ;)

all of "system logs", "syslog" and "journal" are commonly used to refer to the same thing on modern (systemd as pid 1) Linux systems - the logs created by systemd and its managed services and the kernel on a particular system (as collected and archived by systemd-journald). I am not invested in the label, but I don't think "syslog" is somehow confusing in this context ;)
 
As Fabian pointed out, Dietmar's argument is not actually correct:
https://lists.proxmox.com/pipermail/pve-devel/2024-February/061787.html
Fiona, thanks. I do not really need to be "correct" on everything. I just get blunt when I think I am. I thought it would be of help users -> support/forum if it's named more in line of what it represents. BTW rsyslog can use imjournal and there's even systemd-journal-remote it all depends on what one is doing. Naming conventions sometimes matter a lot.
 
although it's a bit messy to split discussions between two places like this, my two cents here as well
- the journal is for most intents and purposes the successor of syslog (both in the meta sense, as the default implementation/collector/provider of system logs on Linux, as well as in the most direct sense, since it is backwards compatible and *among other sources* also collects messages emitted over syslog(3))

unless you want to aggregate logs meaningfully with plethora of existing solutions

- "syslog" does not imply at all that aggregation over multiple systems is taking place

the argument was that if someone says "found this in my syslog" on a system without any syslogd, one would assume they have that running out over the nework (except they are reading it off their GUI)

the latter was (is?) one of the places where "traditional" (modern ;)) syslog was more featureful compared to journald, and this was one of the reasons why Debian had both enabled by default for a while (first with syslog being the persistent one, then with both, now only with journal in the default config).

i will kill it all here again but the GUI term syslog was wrong all along since 2015 precisely

but the "central syslog server" feature was never configured out of the box on PVE, the syslog API/UI tab was always node-specific and displayed the local log of that system, so this is only confusing if


- you are used to setting up a central syslog server

like all admins

- somehow assume PVE would auto-detect this?

this is beyond scope of this thread even for me really (to argue this)

which seems kinda far fetched to be honest. if PVE came with such a feature out of the box (unlikely), the logs would not be under the node tab either, but under datacenter ;)

all of "system logs", "syslog" and "journal" are commonly used to refer to the same thing on modern (systemd as pid 1) Linux systems - the logs created by systemd and its managed services and the kernel on a particular system (as collected and archived by systemd-journald). I am not invested in the label, but I don't think "syslog" is somehow confusing in this context ;)

well i also would not spoil my lunch a with colleague over this ;)

Of all the three, syslog is the worst choice and that docs go on to add syslog traffic RFC into references ... I am not saying somehow reads it like a holy book, but it just tells me there was not much thought put into this when originally designed. And now here we are someone arguing against the grain of historical neglect.

(I don't care what is in the GUI, I do not even use it. I mean, I have a syslog server... the others post it here confusingly.)
 
Last edited:
The discussion with "developers" should have been reflected there with the rationale in the mailing list too.

@fiona Apologies, at the time I wrote this I only saw your last message in the thread about retracting the patch after a discussion, I did not know the discussion was part of the messages in the thread prior. See them now, replied there.
 
But other people would be confused by "System Log", because they won't know what kind of system log.

Standard Debian take on "the system log" - this man page used to look different very long time ago too:
https://manpages.debian.org/testing/bsdutils/logger.1.en.html

Code:
logger makes entries in the system log.


-n, --server server

Write to the specified remote syslog server instead of to the system log socket.


--journald[=file]

Write a systemd journal entry.

--rfc3164

Use the RFC 3164 <https://tools.ietf.org/html/rfc3164> BSD syslog protocol to submit messages to a remote server.

--rfc5424[=without]

Use the RFC 5424 <https://tools.ietf.org/html/rfc5424> syslog protocol to submit messages to a remote server.
 
Last edited:
@fiona Apologies, at the time I wrote this I only saw your last message in the thread about retracting the patch after a discussion, I did not know the discussion was part of the messages in the thread prior. See them now, replied there.

After reading the thread fully now, sorry to retract even this apology.

After discussing with other developers, the argument is that Syslog is more precise, because the messages are exactly those captured via the syslog standard/mechanism. "System Log" doesn't capture that fact and is worse in this regard. See: https://lists.proxmox.com/pipermail/pve-devel/2024-February/061764.html

There's only one source quoted in that whole discussion by the "developers" and that is ... Wikipedia ... that should be a discussion non-starter.
 
The systemd-journald actually listens on / reads:

Code:
/dev/kmsg
/dev/log -> /run/systemd/journal/dev-log
/run/systemd/journal/socket
/run/systemd/journal/stdout

And that's it on any normal PVE install nowadays. When I look at another scenario I have here a Bookworm which interestingly came with:

Code:
# systemctl list-sockets 

LISTEN                                    UNIT                             ACTIVATES                   
...
/run/systemd/journal/syslog               syslog.socket                    rsyslog.service
...

But that's because there's rsyslog and it's configured with imuxsock [1], but well that's all systemd-journal's work [2]:

Forwarding to traditional syslog daemons​

Journal events can be transferred to a different logging daemon in two different ways. With the first method, messages are immediately forwarded to a socket (/run/systemd/journal/syslog), where the traditional syslog daemon can read them. This method is controlled by the ForwardToSyslog= option.

And PVE doesn't have any of this.

Sorry guys, it is indeed confusing, let alone it's wrong.

[1] https://www.rsyslog.com/doc/configuration/modules/imuxsock.html
[2] https://www.freedesktop.org/softwar...html#Forwarding to traditional syslog daemons
 
So I don't know if it's just anachronism or I missed something but PVE is full of references to syslog, almost all wrong. If it was called system log, log(s) or journal (not my preference), I would not mind, but when I see e.g. syslog tab in GUI ... would have expected to see collated logs from the whole cluster there. Not the case. (I know it would be hard to do meaningfully.) There's no syslog by default on Debian to begin with.

The docs [1] have 11 references to "syslog", half of which are used semantically wrong.

Please don't tell me it's called that because every admin thinks of libc syslog(3) calls instead of syslog server.

The docs [1] at the end kind of try to save it with even reference to "Syslog protocol (RFC 5424)" and then go on to say "traffic" and UDP 514 - well, that's RFC 5426 and I have not found it anywhere in PVE.

I put it here before I file a bugreport so that everyone can tell me why I should not and how they have never gotten confused by this (not even the first time when they were to collect logs out of the cluster and found ... no syslog).

[1] https://pve.proxmox.com/pve-docs/pve-admin-guide.html
1. Syslog is just short for system log, what you mean i would call a "(remote) syslog server", syslog protocol is syslog protocol or remote syslogin my view
2. If you had a syslog server with a unified log under proxmox, it would be under Datacenter in the gui, NOT under the hosts
(which would aktually be nice to have, but hard to achieve in a cluster, (what happens to the central log while the node hosting it is down for maintenance?))
3. On a journald only system, i would call the journal the system log, or syslog for short.
 
1. Syslog is just short for system log, what you mean i would call a "(remote) syslog server", syslog protocol is syslog protocol or remote syslogin my view
2. If you had a syslog server with a unified log under proxmox, it would be under Datacenter in the gui, NOT under the hosts
(which would aktually be nice to have, but hard to achieve in a cluster, (what happens to the central log while the node hosting it is down for maintenance?))
3. On a journald only system, i would call the journal the system log, or syslog for short.

Thanks @ubu, I have a different opinion as probably best summarized in the BZ report as on to why. Dietmar had yet another in terms of the word being used for "mechanism" (this is also terminology rsyslog uses I think). Fabian then expanded all the other sources systemd-journal collects from, but mind you even previously on a system with a Syslog daemon one would find e.g. kernel ring buffer messages there despite they did not come through syslog(3) calls, obviously. Fiona pointed out there's no more /var/log/syslog on Bookworm to top it off. For me, it implies syslog server (somewhere) and since there's none on PVE, it could only mean aggregation.

If anything, suffice to say, the term is ambiguous and has a specific connotation (different) for different people which the above is a great testament to. I think Fabian mentioned it sort of became Kleenex, but the problem is that some people care what sort of tissue we are talking about. In this case those are all different things, so different term that is not misleading would help.

And that's why the BZ report.
 
Thanks @ubu, I have a different opinion as probably best summarized in the BZ report as on to why. Dietmar had yet another in terms of the word being used for "mechanism" (this is also terminology rsyslog uses I think). Fabian then expanded all the other sources systemd-journal collects from, but mind you even previously on a system with a Syslog daemon one would find e.g. kernel ring buffer messages there despite they did not come through syslog(3) calls, obviously. Fiona pointed out there's no more /var/log/syslog on Bookworm to top it off. For me, it implies syslog server (somewhere) and since there's none on PVE, it could only mean aggregation.

If anything, suffice to say, the term is ambiguous and has a specific connotation (different) for different people which the above is a great testament to. I think Fabian mentioned it sort of became Kleenex, but the problem is that some people care what sort of tissue we are talking about. In this case those are all different things, so different term that is not misleading would help.

And that's why the BZ report.
Some windows people even use syslog when they speak about the abomination that is EventLog ;)
 
Some windows people even use syslog when they speak about the abomination that is EventLog ;)
Yes, if it's someone wrongly using their terms, that's one thing, but if someone reads it off their screen with uppercase S from a GUI where there's no need for it (as it is already under System tab), it's another. I genuinely got confused when someone said this is in my syslog on the forum. 1) because there's no /var/log/syslog for them to get the idea; 2) I did not know it's called like that in GUI. The term is abused quite a bit, but GUI is not a reddit discussion.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!