4 ms·

Does the PRI formula seem nonsensical to anyone? Facility number * 8 + severity level = PRI. At first looking at the example, I was thinking it would be an easy

Does the PRI formula seem nonsensical to anyone? Facility number * 8 + severity level = PRI. At first looking at the example, I was thinking it would be an easy way to look at the last digit to determine severity (0-7), but since the result of facility number * 8 could contain any final digit, so that's a no go. Since severity is 0-7, and one multiplies facility by 8, no numbers would overlap, so one could eventually get used to the ranges and understand that, for example, PRIs 32-39 have something to do with auth (auth is facility 4, times 8 = 32, + 0 for emergency, up to +7 for debug), with 32 being an emergency and 39 being debug, but it seems unintuitive unless you're a sysadmin that sees these frequently. It seems like simply concating the facility and severity level would give a much more intuitive at a glance understanding of what's going on, and make it easier to awk all, say, emergency severity levels since they'd all end in 0, or awk for all cron facilities, as they would start with 09, or all FTP errors (FTP facility 11 + error 3, 113). Range would be 000 (for kernel, emergency) to 237 (for local 23, debug). Of course, I don't know anything about syslogs except what I learned in this article, so maybe this is totally off base.

benou 7y ago
Bitwise operations: PRI = (facility << 3) | level In term of readability, it becomes clear if you use octal and not decimal representation: the last digit is security level whereas the others are facility number.
- Someone 7y ago
  grepthisab’s comment is about the textual representation, which uses a decimal number < 192. A bit to my surprise, the textual representation also uses that for the ‘on the wire’ protocol (and that isn’t to keep the format a text format. The ‘MSG’ part of a syslog message can (but SHOULD NOT) contain arbitrary byte sequences (https://tools.ietf.org/html/rfc5424#section-6.4 https://tools.ietf.org/html/rfc5424#section-6.4). I would have expected this to be packed in a single byte there. So, we have potentially binary messages, _and_ a syslog parser must know quite a bit of Unicode. Fun :-)
knd775 7y ago
I think it's because they aren't really supposed to be human readable. It's trivial for an application to do (PRI % 8) to get the severity, and ((PRI - severity) / 8) to get the facility number. I'd assume that's why severity only goes to 7.
- grepthisab 7y ago
  This could make sense, but I don't see why being human readable wouldn't necessarily be a benefit. I do a lot of log shaping with sed, grep, awk, etc. and human readability has been a plus for me on things, but I may not be the norm. Regarding the second point, I believe the 7 is so ranges don't overlap. So for example facility X, severity 7 doesn't equal facility X + 1, severity 0.
  - loeg 7y ago
    > I don't see why being human readable wouldn't necessarily be a benefit That's the wire protocol, right? When rendered, this might show up as "2019-08-05T08:12:22Z <4.3> hostname ..."
- close04 7y ago
  > I'd assume that's why severity only goes to 7 I think it may be the other way around: with severity going up to 7, the multiplication factor was chosen to be 8.
andyjpb 7y ago
For the people down voting this post, please see https://xkcd.com/1053/ https://xkcd.com/1053/ The formula is like that because there are 3 bits of information in the Severity Level field: it has 8 values (0->7), and 2^3 = 8. Multiplying the Facility Number by 8 (or, equivalently, by 2^3 or by left shifting the number by 3), frees up the bottom 3 bits. This is the same operation as you are suggesting to do in base-10: multiply by 10^3 to free up the bottom 3 digits, but for base-2 (i.e. in binary). When the Facility Number has been moved out of the bottom 3 bits you can add in the Severity Level and get a combined value for both. It's true that it's not very intuitive when they then render the resulting number in base-10 / decimal, however, it does get you the most compact encoding given the size of the two fields. As another poster says, if the number had been rendered in octal (base-8) then the Severity Level would be the right-most number in the series.
- grepthisab 7y ago
  Hey thanks this is really helpful, appreciate you taking the time to explain.

benou 7y ago

Bitwise operations: PRI = (facility << 3) | level In term of readability, it becomes clear if you use octal and not decimal representation: the last digit is security level whereas the others are facility number.

Someone 7y ago
grepthisab’s comment is about the textual representation, which uses a decimal number < 192. A bit to my surprise, the textual representation also uses that for the ‘on the wire’ protocol (and that isn’t to keep the format a text format. The ‘MSG’ part of a syslog message can (but SHOULD NOT) contain arbitrary byte sequences (https://tools.ietf.org/html/rfc5424#section-6.4 https://tools.ietf.org/html/rfc5424#section-6.4). I would have expected this to be packed in a single byte there. So, we have potentially binary messages, _and_ a syslog parser must know quite a bit of Unicode. Fun :-)

knd775 7y ago

I think it's because they aren't really supposed to be human readable. It's trivial for an application to do (PRI % 8) to get the severity, and ((PRI - severity) / 8) to get the facility number. I'd assume that's why severity only goes to 7.

grepthisab 7y ago
This could make sense, but I don't see why being human readable wouldn't necessarily be a benefit. I do a lot of log shaping with sed, grep, awk, etc. and human readability has been a plus for me on things, but I may not be the norm. Regarding the second point, I believe the 7 is so ranges don't overlap. So for example facility X, severity 7 doesn't equal facility X + 1, severity 0.
- loeg 7y ago
  > I don't see why being human readable wouldn't necessarily be a benefit That's the wire protocol, right? When rendered, this might show up as "2019-08-05T08:12:22Z <4.3> hostname ..."
close04 7y ago
> I'd assume that's why severity only goes to 7 I think it may be the other way around: with severity going up to 7, the multiplication factor was chosen to be 8.

andyjpb 7y ago

For the people down voting this post, please see https://xkcd.com/1053/ https://xkcd.com/1053/ The formula is like that because there are 3 bits of information in the Severity Level field: it has 8 values (0->7), and 2^3 = 8. Multiplying the Facility Number by 8 (or, equivalently, by 2^3 or by left shifting the number by 3), frees up the bottom 3 bits. This is the same operation as you are suggesting to do in base-10: multiply by 10^3 to free up the bottom 3 digits, but for base-2 (i.e. in binary). When the Facility Number has been moved out of the bottom 3 bits you can add in the Severity Level and get a combined value for both. It's true that it's not very intuitive when they then render the resulting number in base-10 / decimal, however, it does get you the most compact encoding given the size of the two fields. As another poster says, if the number had been rendered in octal (base-8) then the Severity Level would be the right-most number in the series.

grepthisab 7y ago
Hey thanks this is really helpful, appreciate you taking the time to explain.