[opensuse] Where is my log message when use with `logger' command
From logger command man:
logger - a shell command interface to the syslog(3) system log module
So, I want to use this command to write log to syslog. following is a test: $: echo 'some special log output' |logger but, i could not found anything about my log in /var/log/. thanks. -- Geek, Rubyist, Emacser Homepage: http://zw963.github.io -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Billy.Zheng(zw963) wrote:
From logger command man:
logger - a shell command interface to the syslog(3) system log module
So, I want to use this command to write log to syslog.
following is a test:
$: echo 'some special log output' |logger
but, i could not found anything about my log in /var/log/.
From the man page:
logger [options] [message] For your test to work: $: echo 'some special log output' | xargs logger -- Per Jessen, Zürich (6.0°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/28/2016 10:35 AM, Per Jessen wrote:
Billy.Zheng(zw963) wrote:
From logger command man:
logger - a shell command interface to the syslog(3) system log module
So, I want to use this command to write log to syslog.
following is a test:
$: echo 'some special log output' |logger
but, i could not found anything about my log in /var/log/.
From the man page:
logger [options] [message]
For your test to work:
$: echo 'some special log output' | xargs logger
Yes, that, and have the settings in whatever you are using as a log daemon configured appropriately :-) -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-02-28 16:38, Anton Aylward wrote:
On 02/28/2016 10:35 AM, Per Jessen wrote:
Billy.Zheng(zw963) wrote:
For your test to work:
$: echo 'some special log output' | xargs logger
Yes, that, and have the settings in whatever you are using as a log daemon configured appropriately :-)
Meaning journalctl for most people ;-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlbTFkIACgkQja8UbcUWM1x5dAD+P+Zg4Mic4JrCMCnFuTNTCbkx 04eef0Ip+UF31eBxAdwBAJ2WcKW6XvG+SLTy3y3G++yb6GaqYQi8/37Imle47rK2 =bccu -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 28-02-16 16:35, Per Jessen wrote:
Billy.Zheng(zw963) wrote:
From logger command man:
logger - a shell command interface to the syslog(3) system log module So, I want to use this command to write log to syslog.
following is a test:
$: echo 'some special log output' |logger
but, i could not found anything about my log in /var/log/.
From the man page:
logger [options] [message]
For your test to work:
$: echo 'some special log output' | xargs logger
Could you explain why this xargs is needed? (because it seems to work without it, on my system....) opensuse:~ # echo 'TEST1' | logger opensuse:~ # echo 'TEST2' | xargs logger opensuse:~ # tail -2 /var/log/messages 2016-02-28T17:14:22.807347+01:00 opensuse luuk: TEST1 2016-02-28T17:14:33.648455+01:00 opensuse luuk: TEST2 opensuse:~ # -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Luuk wrote:
On 28-02-16 16:35, Per Jessen wrote:
Billy.Zheng(zw963) wrote:
From logger command man:
logger - a shell command interface to the syslog(3) system log module So, I want to use this command to write log to syslog.
following is a test:
$: echo 'some special log output' |logger
but, i could not found anything about my log in /var/log/.
From the man page:
logger [options] [message]
For your test to work:
$: echo 'some special log output' | xargs logger
Could you explain why this xargs is needed? (because it seems to work without it, on my system....)
Yep, you're right, according to the man page, logger defaults to reading from stdin when no message is specified and '-f' isn't used. That would suggest the OP just needs to look in the right places to find the messages logged. -- Per Jessen, Zürich (5.4°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
That would suggest the OP just needs to look in the right places to find the messages logged.
Where is the `correct place' to found the `logger' command message on openSUSE 42.1? Thanks. Per Jessen writes:
Luuk wrote:
On 28-02-16 16:35, Per Jessen wrote:
Billy.Zheng(zw963) wrote:
From logger command man:
logger - a shell command interface to the syslog(3) system log module So, I want to use this command to write log to syslog.
following is a test:
$: echo 'some special log output' |logger
but, i could not found anything about my log in /var/log/.
From the man page:
logger [options] [message]
For your test to work:
$: echo 'some special log output' | xargs logger
Could you explain why this xargs is needed? (because it seems to work without it, on my system....)
Yep, you're right, according to the man page, logger defaults to reading from stdin when no message is specified and '-f' isn't used.
That would suggest the OP just needs to look in the right places to find the messages logged.
-- Per Jessen, Zürich (5.4°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland.
-- Geek, Rubyist, Emacser Homepage: http://zw963.github.io -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 01/03/2016 19:29, Billy.Zheng (zw963) a écrit :
That would suggest the OP just needs to look in the right places to find the messages logged.
Where is the `correct place' to found the `logger' command message on openSUSE 42.1?
with Leap, use journalctl or dmesg jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/01/2016 10:36 AM, jdd wrote:
Le 01/03/2016 19:29, Billy.Zheng (zw963) a écrit :
That would suggest the OP just needs to look in the right places to find the messages logged.
Where is the `correct place' to found the `logger' command message on openSUSE 42.1?
with Leap, use
journalctl
or dmesg
There are still some things that insist on finding /var/log/messages. I've been adding the "syslog-ng" package on 13.1 and 13.2. Does this still work with Leap? Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I have install syslog-ng package for openSUSE leap 42.1. It's seem like work perfect well for 42.1. thanks. Lew Wolfgang writes:
On 03/01/2016 10:36 AM, jdd wrote:
Le 01/03/2016 19:29, Billy.Zheng (zw963) a écrit :
That would suggest the OP just needs to look in the right places to find the messages logged.
Where is the `correct place' to found the `logger' command message on openSUSE 42.1?
with Leap, use
journalctl
or dmesg
There are still some things that insist on finding /var/log/messages. I've been adding the "syslog-ng" package on 13.1 and 13.2. Does this still work with Leap?
Regards, Lew
-- Geek, Rubyist, Emacser Homepage: http://zw963.github.io -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
It's seem like dmesg is not work for `logger' command. could you explain how to view logger output with dmesg command ? I still not understood the difference about dmesg vs syslog. and when to use either of each. Thanks. jdd writes:
Le 01/03/2016 19:29, Billy.Zheng (zw963) a écrit :
That would suggest the OP just needs to look in the right places to find the messages logged.
Where is the `correct place' to found the `logger' command message on openSUSE 42.1?
with Leap, use
journalctl
or dmesg
jdd
-- Geek, Rubyist, Emacser Homepage: http://zw963.github.io -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Billy.Zheng(zw963) wrote:
It's seem like dmesg is not work for `logger' command.
could you explain how to view logger output with dmesg command ?
I still not understood the difference about dmesg vs syslog. and when to use either of each.
"man dmesg" - print or control the kernel ring buffer. A syslog daemon writes all kinds of messages to persistent storage, e.g. logfiles. -- Per Jessen, Zürich (3.6°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/02/2016 02:17 AM, Per Jessen wrote:
Billy.Zheng(zw963) wrote:
It's seem like dmesg is not work for `logger' command.
could you explain how to view logger output with dmesg command ?
I still not understood the difference about dmesg vs syslog. and when to use either of each.
"man dmesg" - print or control the kernel ring buffer.
A syslog daemon writes all kinds of messages to persistent storage, e.g. logfiles.
I would add to that: syslog is a network protocol, any device on the network can send syslog messages to a logging host. I have my routers, my main router, my wifi router, any voip device all send their syslog messages to may main network host. The kernel ring buffer logs kernel activity, that is activity internal to a single machine, and to the kernel at that. As the 'logger' command illustrates, syslog is, with few exceptions, an application level protocol. The kernel ring buffer is solely about kernel activity. Yes, kernel activity my be triggered by application level or outside world actions; system calls or inserting a pluggable device such as a USB stick. In addition, there's nothing to say that the kernel can't send syslog messages (as it does when I insert a usb stick, as I've just demonstrated to myself with "tail -f /var/log/messages" and inserting a usb drive and getting the same info). However, to the best of my knowledge, syslog can't send to the ring buffer. Hmm: if syslog could send to the ring buffer that would be an attack surface; a rouge/hijacked network device could send syslog messages with buffer overflow to the kernel of a host. If that were possible we have a very serious structural flaw! -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-03-02 15:58, Anton Aylward wrote:
Hmm: if syslog could send to the ring buffer that would be an attack surface; a rouge/hijacked network device could send syslog messages with buffer overflow to the kernel of a host. If that were possible we have a very serious structural flaw!
logger -p kern.info -t test "test message" (not exactly what it would seem, though) :-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlbXBGYACgkQja8UbcUWM1yJwwD+Nm6CbC1iW5VhGifzrubIUFmd 7NpdgDWZQAlcT0giYwkBAIYjRphAWZ3Y4RJnO34N2x295N0FMZ8stPk/dRjVz6Fx =yGMX -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/02/2016 10:19 AM, Carlos E. R. wrote:
On 2016-03-02 15:58, Anton Aylward wrote:
Hmm: if syslog could send to the ring buffer that would be an attack surface; a rouge/hijacked network device could send syslog messages with buffer overflow to the kernel of a host. If that were possible we have a very serious structural flaw!
logger -p kern.info -t test "test message"
(not exactly what it would seem, though)
:-)
Hmm? It sends to the syslog daemon, not to the kernel. The "-p" just makes it appear to come /from/ the kernel. Now if you had an elaborated already subverted machine where there was a socket that gave access to the kernel, then you could send syslog messages into it, but if the machine was already corrupted to set up such as 'service' in the first place this is cake dressing. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-02 16:28, Anton Aylward wrote:
On 03/02/2016 10:19 AM, Carlos E. R. wrote:
logger -p kern.info -t test "test message"
(not exactly what it would seem, though)
:-)
Hmm?
It sends to the syslog daemon, not to the kernel. The "-p" just makes it appear to come /from/ the kernel.
Exactly. That was the meaning of the comment ;-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Could you please tell me what version you use? Why 42.1 can not find /var/log/messages ? And, some service is not start correctly cause this file missing? Thanks. Luuk writes:
On 28-02-16 16:35, Per Jessen wrote:
Billy.Zheng(zw963) wrote:
From logger command man:
logger - a shell command interface to the syslog(3) system log module So, I want to use this command to write log to syslog.
following is a test:
$: echo 'some special log output' |logger
but, i could not found anything about my log in /var/log/.
From the man page:
logger [options] [message]
For your test to work:
$: echo 'some special log output' | xargs logger
Could you explain why this xargs is needed? (because it seems to work without it, on my system....)
opensuse:~ # echo 'TEST1' | logger opensuse:~ # echo 'TEST2' | xargs logger opensuse:~ # tail -2 /var/log/messages 2016-02-28T17:14:22.807347+01:00 opensuse luuk: TEST1 2016-02-28T17:14:33.648455+01:00 opensuse luuk: TEST2 opensuse:~ #
-- Geek, Rubyist, Emacser Homepage: http://zw963.github.io -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Billy.Zheng(zw963) wrote:
Could you please tell me what version you use?
Why 42.1 can not find /var/log/messages ?
And, some service is not start correctly cause this file missing?
Install a syslog daemon, as Carlos suggested - syslog-ng or rsyslog, for instance. -- Per Jessen, Zürich (3.8°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/02/2016 02:19 AM, Per Jessen wrote:
Billy.Zheng(zw963) wrote:
Could you please tell me what version you use?
Why 42.1 can not find /var/log/messages ?
And, some service is not start correctly cause this file missing?
Install a syslog daemon, as Carlos suggested - syslog-ng or rsyslog, for instance.
+1 If there is a basic *service* that cannot start because of the absence of /var/log/message please tell us what it is. I realise that there are going to be syslog scanning *applications* such as the venerable 'swatch' that are dependent on it, but that isn't a basic *service*. If there is some, for example, systemd triggered service in the basic distribution that depends on /var/log/messages rather than the journald mechanism, then yes it it a serious flaw. Please give details. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
there is some, for example, systemd triggered service in the basic distribution that depends on /var/log/messages rather than the journald mechanism, then yes it it a serious flaw.
No, sorry, I have very poor knowledge about how system log is worked. What i need is just a simple way to add application log to one file. My VPS use openSUSE 42.1, I deploy some application in it, with some self-defined boot start bash scripts, I want a simple way to write all application log to same file. start_some_application |logger I hope it logger output to one file which I familiar and commonly. the only I know from slackware is /var/log/messages. so, I don't know if some *service* is depend on /var/log/message. Thanks. Anton Aylward writes:
On 03/02/2016 02:19 AM, Per Jessen wrote:
Billy.Zheng(zw963) wrote:
Could you please tell me what version you use?
Why 42.1 can not find /var/log/messages ?
And, some service is not start correctly cause this file missing?
Install a syslog daemon, as Carlos suggested - syslog-ng or rsyslog, for instance.
+1
If there is a basic *service* that cannot start because of the absence of /var/log/message please tell us what it is.
I realise that there are going to be syslog scanning *applications* such as the venerable 'swatch' that are dependent on it, but that isn't a basic *service*.
If there is some, for example, systemd triggered service in the basic distribution that depends on /var/log/messages rather than the journald mechanism, then yes it it a serious flaw.
Please give details.
-- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon?
-- Geek, Rubyist, Emacser Homepage: http://zw963.github.io -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Billy.Zheng(zw963) wrote:
there is some, for example, systemd triggered service in the basic distribution that depends on /var/log/messages rather than the journald mechanism, then yes it it a serious flaw.
No, sorry, I have very poor knowledge about how system log is worked. What i need is just a simple way to add application log to one file.
My VPS use openSUSE 42.1, I deploy some application in it, with some self-defined boot start bash scripts, I want a simple way to write all application log to same file.
start_some_application |logger
Unless you have to write to a system log, surely "start_some_application
logfile" is easier ?
I hope it logger output to one file which I familiar and commonly. the only I know from slackware is /var/log/messages.
You only get log written to /var/log/messages when you have a syslog daemon active. openSUSE does not by default install a syslog daemon. It's easy to add - "zypper in syslog-ng" or "zypper in rsyslog". I favour syslog-ng, it does everything I want it to with a minimum of config effort. -- Per Jessen, Zürich (1.4°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-03 04:27, Billy.Zheng (zw963) wrote:
No, sorry, I have very poor knowledge about how system log is worked. What i need is just a simple way to add application log to one file.
My VPS use openSUSE 42.1, I deploy some application in it, with some self-defined boot start bash scripts, I want a simple way to write all application log to same file.
If you want to write to a single file, just write yourself to it. echo "some text" >> somefile
start_some_application |logger
Not the way to use it, IMHO.
I hope it logger output to one file which I familiar and commonly. the only I know from slackware is /var/log/messages.
The rest of the system will also write to it, not only you.
so, I don't know if some *service* is depend on /var/log/message.
No, nothing should depend on /var/log/message However, to have it you need to start a syslog daemon. |> A: Yes. |> > Q: Are you sure? |> >> A: Because it reverses the logical flow of conversation. |> >>> Q: Why is top posting frowned upon? -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 03/03/2016 03:47 AM, Carlos E. R. wrote:
On 2016-03-03 04:27, Billy.Zheng (zw963) wrote:
No, sorry, I have very poor knowledge about how system log is worked. What i need is just a simple way to add application log to one file.
My VPS use openSUSE 42.1, I deploy some application in it, with some self-defined boot start bash scripts, I want a simple way to write all application log to same file.
If you want to write to a single file, just write yourself to it.
echo "some text" >> somefile
Yes, but don't make "somefile" /var/log/messages. Doing so will probably corrupt the proper message stream.
start_some_application |logger
Not the way to use it, IMHO.
Agreed. For example, "ssh -vvv" produced more information. But that's about a single user trying to connect, it is NOT a system activity, thus ssh -vvv 2>~/ssh.log makes more sense in this context than using syslog.
I hope it logger output to one file which I familiar and commonly. the only I know from slackware is /var/log/messages.
This is not slackware. This is not the 20th century.
so, I don't know if some *service* is depend on /var/log/message.
No, nothing should depend on /var/log/message
I'd emphasise the 'should". There are probably many archaic programs that have not been dragged kicking and screaming into The Century of the Fruitbat, sorry, the 21st century, and still work by doing what amounts to "tail -f /var/log/messages" as did that old steadfast "swatch". http://linux.die.net/man/1/swatch But then swatch could be pointed at any file, including ~/ssh.log or included in a pipeline. So "journalctl -f | swatch" would work. I should note that the tool has been renamed to 'swatchdog' so as not to offend a Swiss watch company. it does not seem to have been updated to deal with journald directly. That being said, the kind of people who would have used 'swatch' in days of old probably now use the "Simple event correlator", https://sourceforge.net/projects/simple-evcorr http://simple-evcorr.github.io/ or similar. As it stands, journalctl is quite flexible. https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-vi... and http://0pointer.de/blog/projects/journalctl.html Which gets back to the question Why are you logging? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Sorry for my late reply. (disease, and missing lots of mail from thousands spam) I read you reply carefully. basically, the reason is, e.g. squid, though some like improper. because squid have own log builtin support when compile. 1. I want to use the last version squid in my VPS. so, i have to compile it myself. 2. I need a common startup script for squid to start. simply enough, I add one line in my crontab '@reboot /usr/local/bin/start_squid' `start_squid' is a bash script for start squid correctly. 3. i want to record log to file, for some net analysis. I am not a linux administrator, less experience for logger, i hope spend minimum cost to achieve a sysetm logger like service. function included following: - rotately automatically. - can be output real time if need. I often read log when in programming development, so i think log is useful in this case. The problem is: 1. What is the correct way to add my startup script log into journalctl or something else? (suppose not use opensuse squid package startup script or systemd service. because I want this script to be use in any linux distribution, e.g: debian) 2. if use `ssh -vvv 2>~/ssh.log' way, should i must to add rotately function myself ? is there exist convenient way for this? Thanks very much. Anton Aylward writes:
On 03/03/2016 03:47 AM, Carlos E. R. wrote:
On 2016-03-03 04:27, Billy.Zheng (zw963) wrote:
No, sorry, I have very poor knowledge about how system log is worked. What i need is just a simple way to add application log to one file.
My VPS use openSUSE 42.1, I deploy some application in it, with some self-defined boot start bash scripts, I want a simple way to write all application log to same file.
If you want to write to a single file, just write yourself to it.
echo "some text" >> somefile
Yes, but don't make "somefile" /var/log/messages. Doing so will probably corrupt the proper message stream.
start_some_application |logger
Not the way to use it, IMHO.
Agreed.
For example, "ssh -vvv" produced more information. But that's about a single user trying to connect, it is NOT a system activity, thus
ssh -vvv 2>~/ssh.log
makes more sense in this context than using syslog.
I hope it logger output to one file which I familiar and commonly. the only I know from slackware is /var/log/messages.
This is not slackware. This is not the 20th century.
so, I don't know if some *service* is depend on /var/log/message.
No, nothing should depend on /var/log/message
I'd emphasise the 'should". There are probably many archaic programs that have not been dragged kicking and screaming into The Century of the Fruitbat, sorry, the 21st century, and still work by doing what amounts to "tail -f /var/log/messages" as did that old steadfast "swatch". http://linux.die.net/man/1/swatch But then swatch could be pointed at any file, including ~/ssh.log or included in a pipeline.
So "journalctl -f | swatch" would work.
I should note that the tool has been renamed to 'swatchdog' so as not to offend a Swiss watch company. it does not seem to have been updated to deal with journald directly.
That being said, the kind of people who would have used 'swatch' in days of old probably now use the "Simple event correlator", https://sourceforge.net/projects/simple-evcorr http://simple-evcorr.github.io/ or similar.
As it stands, journalctl is quite flexible. https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-vi... and http://0pointer.de/blog/projects/journalctl.html
Which gets back to the question
Why are you logging?
-- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon?
-- Geek, Rubyist, Emacser 程序员中的牛逼运维， 运维中的牛逼程序员。 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I must say personally I feel "logger" is quite convenient, but you don't get to specify any alternative log file. I know my "logger" messages end up in both /var/log/syslog and journalctl. Personally I would prefer a more custom made or personal thing that logs only stuff that I want personally to be logged. And not system wide or in that system wide log file. Is there really not any simple way to achieve a modicum of features instead of outputting to a file directly? Of course I could simply log to syslog (using logger, I didn't even know it existed) but here is the thing: * if the log is voluminous, you would probably want something that is not into syslog, and that rotates * if the log is not voluminous, you won't need rotation as much, and maybe simple file redirect would be sufficient. So the moment you want more features, you probably have more log output, and when you have more log output, you probably don't want to log to syslog. Solution? :-/. Regards. Billy.Zheng(zw963) schreef op 08-04-16 16:51:
Sorry for my late reply. (disease, and missing lots of mail from thousands spam)
I read you reply carefully.
basically, the reason is, e.g. squid, though some like improper. because squid have own log builtin support when compile.
1. I want to use the last version squid in my VPS. so, i have to compile it myself.
2. I need a common startup script for squid to start. simply enough, I add one line in my crontab '@reboot /usr/local/bin/start_squid' `start_squid' is a bash script for start squid correctly.
3. i want to record log to file, for some net analysis. I am not a linux administrator, less experience for logger, i hope spend minimum cost to achieve a sysetm logger like service. function included following: - rotately automatically. - can be output real time if need.
I often read log when in programming development, so i think log is useful in this case.
The problem is:
1. What is the correct way to add my startup script log into journalctl or something else?
(suppose not use opensuse squid package startup script or systemd service. because I want this script to be use in any linux distribution, e.g: debian)
2. if use `ssh -vvv 2>~/ssh.log' way, should i must to add rotately function myself ? is there exist convenient way for this?
Thanks very much.
Anton Aylward writes:
On 03/03/2016 03:47 AM, Carlos E. R. wrote:
On 2016-03-03 04:27, Billy.Zheng (zw963) wrote:
No, sorry, I have very poor knowledge about how system log is worked. What i need is just a simple way to add application log to one file.
My VPS use openSUSE 42.1, I deploy some application in it, with some self-defined boot start bash scripts, I want a simple way to write all application log to same file.
If you want to write to a single file, just write yourself to it.
echo "some text" >> somefile
Yes, but don't make "somefile" /var/log/messages. Doing so will probably corrupt the proper message stream.
start_some_application |logger
Not the way to use it, IMHO.
Agreed.
For example, "ssh -vvv" produced more information. But that's about a single user trying to connect, it is NOT a system activity, thus
ssh -vvv 2>~/ssh.log
makes more sense in this context than using syslog.
I hope it logger output to one file which I familiar and commonly. the only I know from slackware is /var/log/messages.
This is not slackware. This is not the 20th century.
so, I don't know if some *service* is depend on /var/log/message.
No, nothing should depend on /var/log/message
I'd emphasise the 'should". There are probably many archaic programs that have not been dragged kicking and screaming into The Century of the Fruitbat, sorry, the 21st century, and still work by doing what amounts to "tail -f /var/log/messages" as did that old steadfast "swatch". http://linux.die.net/man/1/swatch But then swatch could be pointed at any file, including ~/ssh.log or included in a pipeline.
So "journalctl -f | swatch" would work.
I should note that the tool has been renamed to 'swatchdog' so as not to offend a Swiss watch company. it does not seem to have been updated to deal with journald directly.
That being said, the kind of people who would have used 'swatch' in days of old probably now use the "Simple event correlator", https://sourceforge.net/projects/simple-evcorr http://simple-evcorr.github.io/ or similar.
As it stands, journalctl is quite flexible. https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-vi... and http://0pointer.de/blog/projects/journalctl.html
Which gets back to the question
Why are you logging?
-- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon?
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/08/2016 11:35 AM, Xen wrote:
I must say personally I feel "logger" is quite convenient, but you don't get to specify any alternative log file.
I know my "logger" messages end up in both /var/log/syslog and journalctl.
Personally I would prefer a more custom made or personal thing that logs only stuff that I want personally to be logged.
And not system wide or in that system wide log file.
Is there really not any simple way to achieve a modicum of features instead of outputting to a file directly?
Of course I could simply log to syslog (using logger, I didn't even know it existed) but here is the thing:
* if the log is voluminous, you would probably want something that is not into syslog, and that rotates
* if the log is not voluminous, you won't need rotation as much, and maybe simple file redirect would be sufficient.
So the moment you want more features, you probably have more log output, and when you have more log output, you probably don't want to log to syslog.
Solution? :-/.
I'm sorry, I don't see that you have a problem, other than what might be termed "failure of imagination". I don't mean that as a insult, its an observation I make very often, for example when MS-Windows peoeple say that Linux is unusable because it doesn't have MS-Office or MS-Money or Notepad. The fact of the matter is that the config file for the older syslog tools was remarkably flexible. For example, rsyslogd(8) points out there are vary many modules available, some of them relating to storage. If you dump the output into a sql database then you have a lot of GUI tools available to manipulate and report on that data, construct queries, set up triggers and filters. Personally I thin that's a bit heavy for home use, but in a corporate setting its a delight. Rsyslog can also read its input from plain text files. If that's all your application can do then you can 'convert' it to syslog style logging, perhaps to feed your database as above. Its also possible to take input from UNIX Sockets, which gets back to things that don't do syslog calls, but that's getting rather esoteric. But the most important aspect of rsyslog is that you can define output channels and the rules for what gets sent to them. This gives almost infinite flexibility. The simple case is to filter and send output to a tty port. I dump everything ("*.*") to tty12. YMMV. But quite apart from filtering the facility and level, you can also use a fifo or names pipe, and from there apply any tool such as grep, awk or similar. The filtering is a lot more than I can describe here, it really is a RTFM case. I'll just note that setting up regex is quite straight forward. The complete documentation can be found in the doc folder of the rsyslog distribution or online at http://www.rsyslog.com/doc After reading that you may come to see that rsyslog has a complete programming languages! Also see http://www.rsyslog.com/doc/v8-stable/configuration/modules/omprog.html http://www.rsyslog.com/doc/v8-stable/configuration/modules/ommail.html Personally I'd like a filter that ran the message stream though an external program then back into rsyslog to be sent elsewhere. Finally you an send the output of any of the above, fitlers and all, to a specific user. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Xen wrote:
I must say personally I feel "logger" is quite convenient, but you don't get to specify any alternative log file.
Yes, it writes to syslog, which by default is the systemd journal. If you want it written to a file, you need to install a syslog daemon and configure it to do that.
Personally I would prefer a more custom made or personal thing that logs only stuff that I want personally to be logged.
And not system wide or in that system wide log file.
Is there really not any simple way to achieve a modicum of features instead of outputting to a file directly?
Of course I could simply log to syslog
A log is just a file, no more, no less. The issue is how you write to it. Do you use the syslog() interface or do write directly to your own file. How you decide between them depends on what you're logging and from where, I would say.
* if the log is voluminous, you would probably want something that is not into syslog, and that rotates
* if the log is not voluminous, you won't need rotation as much, and maybe simple file redirect would be sufficient.
So the moment you want more features, you probably have more log output, and when you have more log output, you probably don't want to log to syslog.
Solution? :-/.
You don't seem to have presented us with a problem yet? Log to syslog, then have your favourite syslog daemon write it to your favourite logfile. If you need to rotate it, add a config to /etc/logrotate.d. /Per -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen schreef op 09-04-16 10:50:
Xen wrote:
I must say personally I feel "logger" is quite convenient, but you don't get to specify any alternative log file.
Yes, it writes to syslog, which by default is the systemd journal. If you want it written to a file, you need to install a syslog daemon and configure it to do that.
So I guess Carlos said you can have multiple destinations in your syslog daemon configuration. Otherwise.
You don't seem to have presented us with a problem yet? Log to syslog, then have your favourite syslog daemon write it to your favourite logfile. If you need to rotate it, add a config to /etc/logrotate.d.
Otherwise it could mean you would need an additional syslog daemon for every program you want to log. That defeats the purpose of having a centralized (local) daemon. It also makes it impossible for any *user* to create logging without being the system administrator. All not very flexible and I guess. I have said many times before perhaps: there is no middle ground between root and a regular user in a regular linux system. What if I write an application and I want to run it on a shell server on which I am just a guest. I want it to do logging within my personal user space. Now what? For me these are real uses cases (or could very well be, become). Now I need to ship my application with its own syslog daemon and logrotate facility? Maybe actually log4j also does those things so I don't need anything for java applications. Log4j obviously can provide asynchronous logging where the thread that writes to disk, is not the same as the thread that does the logging. But on Linux, I seem to be required to use existing daemons that are system-wide, I don't know. Logrotate, I've seen it, thanks. I could probably get it running with a custom config, and then use cron with a user crontab (even that I don't like). Ideally, if I wanted to deploy this and I could not depend on any java solution for instance, I would ship with my own versions of these programs as part of my package and try to get it running as a user. Just the way it would happen for me I guess. In the meantime I keep writing my own logging system (more or less) in every bash script I write, because I require different levels etc. Thus far I have never changed system-wide configs, because ... well.... they are system wide! And anything I do might not want to interfere with that :-/. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Xen wrote:
Per Jessen schreef op 09-04-16 10:50:
Xen wrote:
I must say personally I feel "logger" is quite convenient, but you don't get to specify any alternative log file.
Yes, it writes to syslog, which by default is the systemd journal. If you want it written to a file, you need to install a syslog daemon and configure it to do that.
So I guess Carlos said you can have multiple destinations in your syslog daemon configuration. Otherwise it could mean you would need an additional syslog daemon for every program you want to log.
Yes, the default syslog-ng setup comes with at least 10 different destinations.
It also makes it impossible for any *user* to create logging without being the system administrator. All not very flexible and I guess.
As a regular user, I would just write to a file. syslog() is really meant for system users, not regular users.
I have said many times before perhaps: there is no middle ground between root and a regular user in a regular linux system.
Wouldn't privileged users fit in between root and regular users?
What if I write an application and I want to run it on a shell server on which I am just a guest. I want it to do logging within my personal user space. Now what?
Just write to a file?
Now I need to ship my application with its own syslog daemon and logrotate facility? Maybe actually log4j also does those things so I don't need anything for java applications.
Why would you need your own syslog daemon and logrotation?
But on Linux, I seem to be required to use existing daemons that are system-wide, I don't know.
Applications that don't fit into to the syslog categories/facilities should probably just write their own logs. Examples - mysql, squid, apache, vsftp, zypper, snmp, plenty of them. Perhaps you can describe the problem in some more detail, I'm not sure I've really understood it. -- Per Jessen, Zürich (8.3°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen schreef op 09-04-16 17:49:
Xen wrote:
Wouldn't privileged users fit in between root and regular users?
Those would be users that have specific sudo access right. Other than that? And those users would be privileged to run commands as root, or just a few of those.
What if I write an application and I want to run it on a shell server on which I am just a guest. I want it to do logging within my personal user space. Now what?
Just write to a file?
The whole point was features remember.
Now I need to ship my application with its own syslog daemon and logrotate facility? Maybe actually log4j also does those things so I don't need anything for java applications.
Why would you need your own syslog daemon and logrotation?
Log4J actually provides the kind of formatting and logrotation as an embedded program library in pretty much the same way that syslogd and logrotation do. Except that it is now a simple system call (API call) to some jar file that gets shipped with the application. So the answer to your question is really simple: to have those features as part of my program instead of as part of the system on which the program runs.
But on Linux, I seem to be required to use existing daemons that are system-wide, I don't know.
Applications that don't fit into to the syslog categories/facilities should probably just write their own logs. Examples - mysql, squid, apache, vsftp, zypper, snmp, plenty of them. Perhaps you can describe the problem in some more detail, I'm not sure I've really understood it.
There is a different between writing your own logs without any kind of functionality, and writing your own logs when an API for that is already present as part of existing libraries. An application should be able to control what file its output goes to -- or even what remote syslog, database, etc. Now what the OP asked for was really that: a version of the "logger" program that can do that stuff without requiring system configuration. Or at least, that would be very advanteous to me. And the simple fact is that this log4j also provides that. That means e.g. that you could probably write a front-end to log4j and have these features with minimal effort (but it would be a java program). The only effort would be in creating the front-end interface (command line options, etc.). Again, it is simply about having features but not having them located in the system, but closer to the application. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2016-04-09 at 19:24 +0200, Xen wrote:
Per Jessen schreef op 09-04-16 17:49:
Xen wrote:
Wouldn't privileged users fit in between root and regular users?
Those would be users that have specific sudo access right.
Other than that? And those users would be privileged to run commands as root, or just a few of those.
Once configured, the user only needs read access to the log files. ...
The only effort would be in creating the front-end interface (command line options, etc.).
Again, it is simply about having features but not having them located in the system, but closer to the application.
A user application has to write its own log files in his own user space. Completely under his control. Either he writes the code completely, or uses some library or system that already exists, such as that log4j. Many applications do this. He can instead use the system facilities, but then he doesn't have full control. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlcJPo4ACgkQtTMYHG2NR9VWLACeKkWZUsmxmHMkgXNjie2dlD4H uqcAn3ype6JVVMUcwtjDXDC/V3DRYL5y =mPa9 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Xen wrote:
What if I write an application and I want to run it on a shell server on which I am just a guest. I want it to do logging within my personal user space. Now what?
Just write to a file?
The whole point was features remember.
No, I'm sorry, I was not aware. Features of what?
Now I need to ship my application with its own syslog daemon and logrotate facility? Maybe actually log4j also does those things so I don't need anything for java applications.
Why would you need your own syslog daemon and logrotation?
[snip]
So the answer to your question is really simple:
to have those features as part of my program instead of as part of the system on which the program runs.
That still does not explain why you _need_ your own syslog daemon and logrotation.
But on Linux, I seem to be required to use existing daemons that are system-wide, I don't know.
Applications that don't fit into to the syslog categories/facilities should probably just write their own logs. Examples - mysql, squid, apache, vsftp, zypper, snmp, plenty of them. Perhaps you can describe the problem in some more detail, I'm not sure I've really understood it.
There is a different between writing your own logs without any kind of functionality, and writing your own logs when an API for that is already present as part of existing libraries.
Not much of a difference, I submit. Whether you use your own write2log() call or that of an existing library does not make a real difference, except in the packaging (if you plan to distribute your code). -- Per Jessen, Zürich (6.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen schreef op 09-04-16 23:52:
Xen wrote:
What if I write an application and I want to run it on a shell server on which I am just a guest. I want it to do logging within my personal user space. Now what?
Just write to a file?
The whole point was features remember.
No, I'm sorry, I was not aware. Features of what?
Are you being wilfully thick? I'm sorry for the word. I mean that you mention those features yourself down below.
Now I need to ship my application with its own syslog daemon and logrotate facility? Maybe actually log4j also does those things so I don't need anything for java applications.
Why would you need your own syslog daemon and logrotation?
[snip]
So the answer to your question is really simple:
to have those features as part of my program instead of as part of the system on which the program runs.
That still does not explain why you _need_ your own syslog daemon and logrotation.
Nobody ever needs anything. Do you need education? No, you can just keeping working the farm all of your life. Do you want education? Well maybe the answer could be yes. Maybe you want to get ahead in life. Could you use education? Well most assuredly so. But do you need it? No. So why not ask why someone would want it or could use it. The answer could be much clearer then.
There is a different between writing your own logs without any kind of functionality, and writing your own logs when an API for that is already present as part of existing libraries.
Not much of a difference, I submit. Whether you use your own write2log() call or that of an existing library does not make a real difference, except in the packaging (if you plan to distribute your code).
I did not compare two equivalent modes of functionality. I compared one mode of functionality that is meagre, because you need to write it yourself for your application yourself. The other one is rich, because other people have written it with the idea of being used by a lot of people. The difference is they call him king, the difference frightens me. What I mean is very simple, and you already know the answer. 1. Anything you write yourself you will have to write from scratch if you cannot reuse someone else's code. 2. This will take a lot of energy and is less efficient than reusing existing code if you agree with that code. You DO understand why libraries exist in the first place right? So not everyone has to constantly reinvent the wheel. I mean are you just purposefully being thick here? I mean pretending not to understand so you won't have to reach a certain conclusion? So no, the difference is not packaging, the difference is effort required to reach a certain level of functionality. That's WHY you use existing libraries. Now if those libraries don't exist, you have a problem. A certain feature in the system ecosystem is missing. And if existing syslogd and logrotate do not fit your purposes, then what? Are there situations where a programmer could /use/ application-level logging functionality instead of system-wide features? Definitely. Why not? Why wouldn't there be? After all, you've notice that this is the raison d'être of Log4j in the first place. Why would it exist if there was no use for it? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Xen wrote:
There is a different between writing your own logs without any kind of functionality, and writing your own logs when an API for that is already present as part of existing libraries.
Not much of a difference, I submit. Whether you use your own write2log() call or that of an existing library does not make a real difference, except in the packaging (if you plan to distribute your code).
I did not compare two equivalent modes of functionality.
I compared one mode of functionality that is meagre, because you need to write it yourself for your application yourself. The other one is rich, because other people have written it with the idea of being used by a lot of people.
Right.
The difference is they call him king, the difference frightens me.
What I mean is very simple, and you already know the answer.
1. Anything you write yourself you will have to write from scratch if you cannot reuse someone else's code. 2. This will take a lot of energy and is less efficient than reusing existing code if you agree with that code.
In principle this is absolutely true, in practice for a write2log() call, less so. Unless that call was part of a framework I wanted to use in my application anyway, I would not bother. It would take me less time to write my own than to learn how to use a foreign one.
You DO understand why libraries exist in the first place right? So not everyone has to constantly reinvent the wheel. I mean are you just purposefully being thick here? I mean pretending not to understand so you won't have to reach a certain conclusion? So no, the difference is not packaging, the difference is effort required to reach a certain level of functionality. That's WHY you use existing libraries.
Would you like to be a little less condescending?
Now if those libraries don't exist, you have a problem. A certain feature in the system ecosystem is missing.
If they don't exist, you have no option but to write them yourself. I don't see a problem here.
And if existing syslogd and logrotate do not fit your purposes, then what?
1) invent your own wheel or, 2) change your purpose to suit the wheels at hand
Are there situations where a programmer could /use/ application-level logging functionality instead of system-wide features? Definitely. Why not?
That what I keep saying. It's called write(). see "man 2 write". -- Per Jessen, Zürich (8.9°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen schreef op 10-04-16 10:19:
The difference is they call him king, the difference frightens me.
What I mean is very simple, and you already know the answer.
1. Anything you write yourself you will have to write from scratch if you cannot reuse someone else's code. 2. This will take a lot of energy and is less efficient than reusing existing code if you agree with that code.
In principle this is absolutely true, in practice for a write2log() call, less so. Unless that call was part of a framework I wanted to use in my application anyway, I would not bother. It would take me less time to write my own than to learn how to use a foreign one.
Probably, but that depends on how complex those other ones are, and whether you can use it with a few simple command calls. For instance "logger" is clearly not a complex tool. If it had a little more functionality, the same interface would be very easy to use in a script (or program).
You DO understand why libraries exist in the first place right? So not everyone has to constantly reinvent the wheel. I mean are you just purposefully being thick here? I mean pretending not to understand so you won't have to reach a certain conclusion? So no, the difference is not packaging, the difference is effort required to reach a certain level of functionality. That's WHY you use existing libraries.
Would you like to be a little less condescending?
Most of what you write is condescending to begin with. And I apologized for the word thick, I just don't know how to express it.
Now if those libraries don't exist, you have a problem. A certain feature in the system ecosystem is missing.
If they don't exist, you have no option but to write them yourself. I don't see a problem here.
The question was whether they exist. Logrotation and asynchronous writing and all of that is not that easy to implement. Sure, if you spend a few hours to a few days on it, sure you might have something. The whole purpose of me asking was to help the OP (and myself) to see if something might not be missing here. If every application writes its own logging framework, that's a lot of wasted effort. Apparently you want me to start exploring the source of e.g. squid to see how it does it. I would think people would know about these answers.
And if existing syslogd and logrotate do not fit your purposes, then what?
1) invent your own wheel or, 2) change your purpose to suit the wheels at hand
Yes, you're being thick. The question was clearly intended to find a solution that did agree with the purpose. Changing your purpose is like changing the question and reason for asking, and as such it means not getting an answer. Writing it yourself means spending an amount of time you were trying to avoid to see if something else did not already exist. I mean you don't have to answer questions you don't understand by assuming or insinuating that the person asking the question is somehow too stupid to come up with these answers himself. How do I view a webpage? 1. Write an operating system. 2. Write networking software. 3. Write a desktop GUI 4. Write a web browser Now you can view a webpage. (Facepalm). I KNOW that I could write any piece of missing functionality myself, if I had the time. I KNOW I can create my own logging framework and market or distribute it. If I had the time, the ability, the purpose, and the convenience. I KNOW that that would be a solution. But if a solution currently does not exist it is also because of people who cannot understand that anyone would want it. It's like there only being two kinds of apples on the market: very small ones, and very big ones. And then someone comes and says "why are there not any medium ones?" And people answer "Why do you need a medium one? You can just eat lots of small ones right? Or chop a big one in half?" This is the problem with most Linux people, they cannot conceive of anything new coming into being. When you say "why are there no medium apples?" they cannot understand why anyone would want a medium apple. When you say "why is there no logging framework?" they say "you can use the big one or the small one, right? Why do you have a need for a medium one?" Maybe "why" is a meaningless question, but I did not really ask that. I asked whether anything of the kind existed, and tried to explain the reasons why. "And if existing syslogd and logrotate do not fit your purposes, then what?" This question was clearly intended to open up the space where solutions could be found. Not a denial of any kind of answer with a collapse into non-creative "use what is available or do it yourself" answers. The whole point was to inquire into what more could be available. Such inquiries can transform into a creative approach, but you don't start designing your own meant-for-broader-use system either unless and until you have explored the existing landscape. You will first want to know if anyone else has done it, before you start doing it yourself, mostly. "Use what is available or do it yourself" is not the kind of answer that contains any information. The answer is so generic that it applies to everything, or rather, that it does not apply to anything. I was not asking for the well-traveled road, as we say in Dutch. I was curious whether something did actually not really exist. Then when you (Per) asked why I would even want it, I tried to explain.
Are there situations where a programmer could /use/ application-level logging functionality instead of system-wide features? Definitely. Why not?
That what I keep saying. It's called write(). see "man 2 write".
This is about as condescending as you can get without using explicit words for it. You really feel the need to tell someone about the most primitive system call to write text to a file???? Insulting people or someone by pretending, assuming or insinuating that person would not have been able to come up with that himself? This is what you do constantly Per. You give answers I do not need because apparently you do not understand that I am looking for something more. It is like saying "how can I write a thesis about global economies and their interrelationship?" and you say "grab a pen and paper". Clearly the person did not inquire into that sort of information. You are not doing that person a service okay. You also don't need to tell me what grep is or what a file redirect could be. You also don't need to tell me how to use a keyboard to write commands. I was asking for a certain kind of solution and whether it existed or not, and I expressed some incredulity that apparently in fact it doesn't -- or you people would probably know about it (but I can't be sure). I don't need to be told that I can change my purpose or write the thing I need from scratch. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/10/2016 06:55 PM, Xen wrote:
For instance "logger" is clearly not a complex tool. If it had a little more functionality, the same interface would be very easy to use in a script (or program).
And what 'extra' functionality do you think it SHOULD have? And how would that make it easier to use? Can you be specific, please. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward schreef op 11-04-16 01:15:
On 04/10/2016 06:55 PM, Xen wrote:
For instance "logger" is clearly not a complex tool. If it had a little more functionality, the same interface would be very easy to use in a script (or program).
And what 'extra' functionality do you think it SHOULD have? And how would that make it easier to use?
Can you be specific, please.
I already explained at the beginning: In short: a logging library or program (for a shell script, you could not use a library, you need to have a command line tool). That could do what logrotate and syslog do, without requiring logrotate and syslog. Logrotate is not actually an administrator-specific tool. And there are things like user crontabs. But setting up the target of e.g. "logger" implies having sysadmin access or someone that can do it for you, because it depends on syslog, which cannot be configured by a user in any way. If I write a program that needs to be portable from system to system and that requires local logging to take place, Then I need to be able to package its logging system together with the application. Now Log4J does that, but supposing not everything I do is Java. I will need a logging library of certain functionality that cron, logrotate and syslog already provide. The very same features: * rotation * gzipping of old logs, possibly deletion of very old logs * possibly asynchronous writing, but not very important at this point. * support for different levels (info, debug, etc.) And yes I can write this, I was just curious whether it already existed. Maybe I should just repackage cron, logrotate and syslog as user-level programs/daemons ;-). You know, have your program have a /bin directory that contains those programs, just they run as your (program) user and may have different names and they do not need access to the full / trees. So your program could be packaged in a : /bin /etc /lib Of its own, and the programs you supply together with the program use that. Then you simply write to your own daemon instead of the system-wide daemon. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2016-04-11 at 21:06 +0200, Xen wrote:
Anton Aylward schreef op 11-04-16 01:15:
On 04/10/2016 06:55 PM, Xen wrote:
For instance "logger" is clearly not a complex tool. If it had a little more functionality, the same interface would be very easy to use in a script (or program).
And what 'extra' functionality do you think it SHOULD have? And how would that make it easier to use?
Can you be specific, please.
I already explained at the beginning:
In short:
a logging library or program (for a shell script, you could not use a library, you need to have a command line tool).
That could do what logrotate and syslog do,
without requiring logrotate and syslog.
Wait. The specific question here is what do you find missing in "logger". Remember that logger requires a syslog daemon (can be systemd journal), with all the wistles, including rotating. You are talking about a tool that does not exist or that we have not found, to log to file by users, not "logger". So, the question: what do you find missing in the existing logger, aimed at syslog? - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlcM3OEACgkQtTMYHG2NR9W7RwCfZDJiEe0wYbe2nqujtoYLftPc g94AnitB117ELLwE9+29cJVSHBO0tY+y =Xmgz -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/12/2016 07:32 AM, Carlos E. R. wrote:
Wait. The specific question here is what do you find missing in "logger". Remember that logger requires a syslog daemon (can be systemd journal), with all the wistles, including rotating.
You are talking about a tool that does not exist or that we have not found, to log to file by users, not "logger".
So, the question: what do you find missing in the existing logger, aimed at syslog?
Indeed! Focus, focus, focus. Xen, you are good at rambling discussions of perceived shortcomings, but you lack specifics, both about what the exact shortcomings are and actual suggestions about remediation. Rather than rambling, get down to specifics. Give a LIST of the shortcoming without the rambling discussion. The, for each item on that lit, suggest a remediation, again without rambling. Please, no rambling. Focus, Focus, Focus. The ramblings do not add to your case, they defocus your arguments and end up in the TL;DR bin. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. schreef op 12-04-16 13:32:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday, 2016-04-11 at 21:06 +0200, Xen wrote:
Anton Aylward schreef op 11-04-16 01:15:
On 04/10/2016 06:55 PM, Xen wrote:
For instance "logger" is clearly not a complex tool. If it had a little more functionality, the same interface would be very easy to use in a script (or program).
And what 'extra' functionality do you think it SHOULD have? And how would that make it easier to use?
Can you be specific, please.
I already explained at the beginning:
In short:
a logging library or program (for a shell script, you could not use a library, you need to have a command line tool).
That could do what logrotate and syslog do,
without requiring logrotate and syslog.
Wait. The specific question here is what do you find missing in "logger". Remember that logger requires a syslog daemon (can be systemd journal), with all the wistles, including rotating.
You are talking about a tool that does not exist or that we have not found, to log to file by users, not "logger".
So, the question: what do you find missing in the existing logger, aimed at syslog?
I have no interest in a logger that can only log to syslog. Although, of course, you could run your own user-created syslog daemon that you configure and specify as a user, and then you could log to it using -n and -P tags/flags. As to Anton, you are trying to derail the discussion. I never had any interest in logger as a real solution unless I can tweak it to my usage. I have stated numerous times: * Functionality akin to logger/syslog/logrotate/cron that I can control completely as a general non-privileged user on any system. If I can just fire up my own syslog daemon instance, call logrotate on its output, use logger to send data to it, and have a way to automate some of that (either by using cron or as an activation check in the script/program) then in a general sense that is problem solved. It does require starting the daemon as your program (script) starts, and shutting it down when you finish, which is a bit weird for scripts, but perhaps doable for real programs. It is really only necessary (theoretically) if you require asynchronous logging though. You could also consider that some system administrator might not like you running something like that :p. I don't even know what system I have in mind. If I just use java, and maybe some java-python plugin (jPython?) I won't even be dealing with scripts. I cannot imagine requiring async logging for something that is nothing more than a (big) shell script. What remains is real Linux programs (I mean C/C++) and I have no intent really of writing any yet. Also firing up daemons of your own might not be very nice. It can be a thread or child of your program though. If I wrote anything for Linux myself it would probably be Python at first. I'm sure there is some logging library for it that I could use. So I'm not sure what the real practical issue is. Anything requiring real complex logging is going to be something more than a script. Regardless, I'm interested in this because it relates to the "your program as its own package" concept in which a program install doesn't impact the rest of the system as much. In OS X most programs are entirely self-contained. I like that concept. The package format contains information on what the main process (executable file) of the package is, much like a Jar perhaps (not sure). These programs, you just double-click them (or whatever) or just drag them to your dock, and all this time they are still just that package. The package is not even unpacked in some sense. I don't like that completely, but I would like to be able to provide "own tree" solutions where a program is just in its own subdirectory while still being accessible. For instance, you could imagine a "user" set of programs where all executables are just symlinks. Say what would amount to a /usr/local/bin but all files are symlinks to the real programs. Then you could have a user-local package installation system that does not require total root access in order to install programs. Then you could scope the rest of the system to hide much from the user and only show what she wants to see. Something like that, I don't know. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/12/2016 07:41 PM, Xen wrote:
Carlos E. R. schreef op 12-04-16 13:32:
On Monday, 2016-04-11 at 21:06 +0200, Xen wrote:
Anton Aylward schreef op 11-04-16 01:15:
On 04/10/2016 06:55 PM, Xen wrote:
For instance "logger" is clearly not a complex tool. If it had a little more functionality, the same interface would be very easy to use in a script (or program).
And what 'extra' functionality do you think it SHOULD have? And how would that make it easier to use?
Can you be specific, please.
I already explained at the beginning:
In short:
a logging library or program (for a shell script, you could not use a library, you need to have a command line tool).
Many CLIs - zypper is a good example - are libraries with wrappers. The issue is the functionality, not whether it is a library or a CLI wrapper for that library. Its this kind of fuzzy thinking, last of a precise REQUIREMENT and specification that has taken this into a rambling and unhelpful discourse. If you can't see that very basic aspect of programming, that even the CLIs are made up on top of libraries that can be used elsewhere, then its "abandon hope and discard this thread".
So, the question: what do you find missing in the existing logger, aimed at syslog?
I have no interest in a logger that can only log to syslog.
You must be, as Whitman observed, vast, vaster than the rest of us here, since you contradict yourself. What functions you do describe can be carried out by the logger libraries and configuration files. A visit to Perl's CPAN will give some edification in this area too.
Although, of course, you could run your own user-created syslog daemon that you configure and specify as a user, and then you could log to it using -n and -P tags/flags.
I don't know why you want to make things so complicated. The already existing rsyslog mechanism not only supports programmability and templates, but listens on sockets. All that is specified in config file. You can have up to 50 concurrent sockets, and thanks to the programmability of rsyslog, your custom config file can turn these on and off according to your own programatically defined needs. At this point 'facility' and 'priority' loose their classical meaning and are just additional parameters for your custom tool. They can be used to trigger specific 'templates'. The important thing here is that a "daemon' listens on a specified socket. Which one? well that's what the config file is for.
As to Anton, you are trying to derail the discussion. I never had any interest in logger as a real solution unless I can tweak it to my usage.
My point is that you can 'tweak' it; you should know that if you'd actually RTFM, and if you had a clearer idea of what you were trying to achieve, rather than just denouncing Linux as you seem to keep doing. The people who designed many of these components had a good vision, and all you are doing with this argumentative approach and dodging around is showing that you have (a) failed to do proper research into the matter and (b) are committing the error of fuzzy thinking by not clarifying what you actually want and playing stupid "yes-but" games. There is no malice, just an emergent property of the fuzzy thinking.
I have stated numerous times:
* Functionality akin to logger/syslog/logrotate/cron that I can control completely as a general non-privileged user on any system.
If you had RTFM and experimented a bit based on what is documented you'd know that is possible.
It does require starting the daemon as your program (script) starts, and shutting it down when you finish, which is a bit weird for scripts, but perhaps doable for real programs. It is really only necessary (theoretically) if you require asynchronous logging though.
I don't see an objection or problem here. There are many database services that don't need a "daemon" beyond the lifetime of the user running the application. Back in the days of email carried by UUCP there was no continuously running "email daemon". We accept the continuously running email daemon today becuase it need to carry a lot of traffic, but there is no reason wht it *has* to be continually running. A low volume site could have a "sender" that is only triggered by a user pressing "send" causing another program to execl. The XinetD could have a configuration for a receiver that is only spawned when someone comes knocking on port 25. In the days before we had CUPS (or even is SVR4 predecessor) there was no line printer daemon, just a driver programme for a printer hanging off a tty port :-) It lived only as long as it took to drive the line printer.
You could also consider that some system administrator might not like you running something like that :p.
I can't see why. What's wrong with creating your own named pipes? (aka sockets). Why do you think 'mknod' is in '/usr/bin/ and not /sbin/? Its so ordinary users cam run mknod -p <filename> In fact FIFO mode is the only truly portable and user available mode of mknod. See the various man pages for the reason for that. Of course you may prefer 'mkfifo'
I don't even know what system I have in mind. If I just use java, and maybe some java-python plugin (jPython?) I won't even be dealing with scripts.
The boundary between what is a script and what is 'just' a program when it come to interpretive languages is fuzzy. Java and Python you can clearly save the intermediate code. Perl and Ruby are a bit ambiguous in this regard. The Bash shell is very unambiguously what is termed a 'throw-away compiler-interpreter' (nomenclature due to P. J. Brown of Oxford and Canterbury) in that it build the parse tree but doesn't retail the source, but the parse tree is inaccessible. (Of course there are hacked versions where that's available for debugging purposes, but such are outside the scope of this.) Yes, you can view Java/Python as a 'throw-away' where the source is thrown away but the parse tree has been complied to a reloadable module, where as the similar module doesn't exist for Bash. They are still both interpreters and are still both scriptable.
I cannot imagine requiring async logging for something that is nothing more than a (big) shell script.
Right now you can't :-) But after you've used the setup for a year and published it you, or someone else, will end up with that as a requirement. Maybe you're doing a client/server thing like SSH and need to log both ends.
What remains is real Linux programs (I mean C/C++) and I have no intent really of writing any yet. Also firing up daemons of your own might not be very nice.
*sigh* I can't see why its any more "not nice" than any other form of non-trivial shell scripting (or scripting in Perl or Python or Ruby).
If I wrote anything for Linux myself it would probably be Python at first. I'm sure there is some logging library for it that I could use.
I use Perl and Ruby and there is for both; I can't imagine Python is crippled and doesn't have one.
For instance, you could imagine a "user" set of programs where all executables are just symlinks. Say what would amount to a /usr/local/bin but all files are symlinks to the real programs.
Ahm, I can do that already. I can unpack RPMs into ${HOME|/bin and ${HOME}/lib. I do this at one of my ISPs where I need a later version of Ruby and its libraries for a RubyOnRails application I have. I know it can be done, so please don't tell me it can't be done. I just have to have my own version in the $PATH and ${LD_LIBRARY_PATH} ahead of the system defined values.
Then you could scope the rest of the system to hide much from the user and only show what she wants to see.
Something like that, I don't know.
I do. BTDT. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-04-13 03:18, Anton Aylward wrote:
On 04/12/2016 07:41 PM, Xen wrote:
I don't know why you want to make things so complicated. The already existing rsyslog mechanism not only supports programmability and templates, but listens on sockets.
He wants it to be all run and configured as plain user, not as root. It can not be the system syslog. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlcNofUACgkQja8UbcUWM1xM+QD8D9Ypk2HNThimPExx6s3rUYQB sX0kKJ8EelDvhyBcBE8A/jIF0odf2dasPiltgeAIjuWO3hyY59KSi0yYxm53p3jQ =BSVs -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/12/2016 09:33 PM, Carlos E. R. wrote:
On 2016-04-13 03:18, Anton Aylward wrote:
On 04/12/2016 07:41 PM, Xen wrote:
I don't know why you want to make things so complicated. The already existing rsyslog mechanism not only supports programmability and templates, but listens on sockets.
He wants it to be all run and configured as plain user, not as root. It can not be the system syslog.
Indeed, and it need not be. Yes, systemd (or sysvinit if you are still using that) runs the SYSTEM syslog daemon. But there is no reason you can't start another instance of "a" syslog server with your own defines config file as a user. In fact the model I suggest is there already, read the script "rsyslog-service-prepare" which sets up the possible additional sockets for the system level rsyslog to listen on. Of course 'out of the box' that set is empty for there is only the socket in /var/run/rsyslog since there are no more defined in /etc/config/syslog. Yes a user side daemon would need its own start up script and start up parameters and config file. So what? Strictly speaking its only necessary to have your (or the system level) rsyslog daemon read from a file, the imfile module and its parameter list, which is amazingly flexible does this. You can list multiple files each with their own characteristics. Some may simply be read once; some mail be read as 'tail -f'. And of course some can be pipes :-) In general, see http://www.rsyslog.com/ Specific to sockets http://www.rsyslog.com/doc/v8-stable/configuration/modules/imuxsock.html http://www.rsyslog.com/doc/v8-stable/configuration/modules/omuxsock.html Also note a thread that I haven't explored, the ability to have rsyslog use arbitrary external programs, even user defined scripts: http://www.rsyslog.com/doc/v8-stable/configuration/modules/omprog.html You'll see in that a note: "... especially if it is not running as root...". Now why would it not be running as root? The system-level (systemd spawned) server runs as root, so the alternative must be a user initiated server. As I said, this is a very flexible tool. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-04-13 01:41, Xen wrote:
So, the question: what do you find missing in the existing logger, aimed at syslog?
I have no interest in a logger that can only log to syslog.
But the tittle of this thread is about the "logger" command. You also said that the logger command was lacking. It is very difficult to follow your meaning! You also said on other posts that you want a system fully as user, which means that it can not be "logger" at all. Thus your statement that you wanted more functionality in logger, is impossible to do. You need something that is not "logger" at all. The applications I know do their own log system, possibly from scratch. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlcNpA0ACgkQja8UbcUWM1wAMgD/ftyZ8XupHpx7fnRzH1EBqhKF pd7NKbVfjRErdjI/RiIBAI7Mu9Up2l2VJ6gp2Tk5XH1gjNpOtbgd+oUMxv9Q7Bbw =FD1w -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-04-11 00:55, Xen wrote:
Per Jessen schreef op 10-04-16 10:19:
In principle this is absolutely true, in practice for a write2log() call, less so. Unless that call was part of a framework I wanted to use in my application anyway, I would not bother. It would take me less time to write my own than to learn how to use a foreign one.
Probably, but that depends on how complex those other ones are, and whether you can use it with a few simple command calls.
For instance "logger" is clearly not a complex tool. If it had a little more functionality, the same interface would be very easy to use in a script (or program).
What else do you want it to do? I use it often in scripts, that's what it is for.
The question was whether they exist. Logrotation and asynchronous writing and all of that is not that easy to implement. Sure, if you spend a few hours to a few days on it, sure you might have something. The whole purpose of me asking was to help the OP (and myself) to see if something might not be missing here.
If every application writes its own logging framework, that's a lot of wasted effort. Apparently you want me to start exploring the source of e.g. squid to see how it does it. I would think people would know about these answers.
I gave you a dozen examples of programs you could examine. Yes, if I'm going to create a complicated application, certainly I will examine code examples I may reuse!
Writing it yourself means spending an amount of time you were trying to avoid to see if something else did not already exist.
I use my own log often enough in my scripts. As simple as a simple function that calls "echo" with a timestamp and a file destination, that's all. I don't see the difficulty... You said, I think, you coded in Delphi. Then have a look at Lazarus, it is a multiplatform remake of Delphi. Just write to a text file with a cache. Or look in the examples to find something else... - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlcK7eQACgkQja8UbcUWM1wz3wD8CgUaGnOHzaPpI2/kLiknxi/Y 9XuCrKCxSlUveTr9nNUA/0fXteLE+cuHFh1Olb2Rs6Re57uyZS2m1+p++E3f/VVR =GYRY -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
In principle this is absolutely true, in practice for a write2log() call, less so. Unless that call was part of a framework I wanted to use in my application anyway, I would not bother. It would take me less time to write my own than to learn how to use a foreign one.
Probably, but that depends on how complex those other ones are, and whether you can use it with a few simple command calls.
For instance "logger" is clearly not a complex tool. If it had a little more functionality, the same interface would be very easy to use in a script (or program).
What else do you want it to do? I use it often in scripts, that's what it is for.
Ditto & ditto. logger has been around for more than 20 years, I guess it might be getting old :-) -- Per Jessen, Zürich (7.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. schreef op 11-04-16 02:20:
For instance "logger" is clearly not a complex tool. If it had a little more functionality, the same interface would be very easy to use in a script (or program).
What else do you want it to do? I use it often in scripts, that's what it is for.
Well of course it writes to the system syslog. I want something that can write to a file without having to configure it in syslog.
If every application writes its own logging framework, that's a lot of wasted effort. Apparently you want me to start exploring the source of e.g. squid to see how it does it. I would think people would know about these answers.
I gave you a dozen examples of programs you could examine. Yes, if I'm going to create a complicated application, certainly I will examine code examples I may reuse!
Well okay. But the reason for me asking was to discover whether that be necessary to begin with. See if you use log4j, there is no need for you to do anything. You can use it to log synchronously, asynchronously, to any database, to a syslog server, in any format you want, etc. etc. etc. But you understand.
Writing it yourself means spending an amount of time you were trying to avoid to see if something else did not already exist.
I use my own log often enough in my scripts. As simple as a simple function that calls "echo" with a timestamp and a file destination, that's all. I don't see the difficulty...
Of course, but the inquiry was about having more advanced features that syslog also provides. Without requiring syslog. If there is something easy to use, then I might be able to more easily incorporate it into my own scripts. Makes them less portable, but so be it. I have seen one such script I must say. I came across it when I was researching scripts that provide a more complete rsync experience. One of those scripts used its own logger script that was quite complete, I believe. Not sure though. Maybe I was mistaken and it just used the regular logger, which I did not know about.
You said, I think, you coded in Delphi. Then have a look at Lazarus, it is a multiplatform remake of Delphi. Just write to a text file with a cache. Or look in the examples to find something else...
No my friend, I do not need help into very basic logging principles, I was just inquiring whether something more fully developed would exist for Linux that was not the triade of syslog/cron/logrotate. If most people generally just go with syslog/cron/logrotate then no one might ever have found a need (or desire) for it. However if you say that many programs do bring their own system, then maybe we're missing something. Basic rotation would not be hard to implement in your own script, I concur, but it needs the work in any case and usually (thus far) I am not willing to put that much work into it. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-04-11 21:14, Xen wrote:
Carlos E. R. schreef op 11-04-16 02:20:
You said, I think, you coded in Delphi. Then have a look at Lazarus, it is a multiplatform remake of Delphi. Just write to a text file with a cache. Or look in the examples to find something else...
No my friend, I do not need help into very basic logging principles, I was just inquiring whether something more fully developed would exist for Linux that was not the triade of syslog/cron/logrotate.
Well, I simply have not needed anything of the sort in the programs I have made on Linux. Otherwise, I would investigate, or do my own.
If most people generally just go with syslog/cron/logrotate then no one might ever have found a need (or desire) for it.
However if you say that many programs do bring their own system, then maybe we're missing something.
Several have the configuration option to use the system syslog, or files directly handled by the application.
Basic rotation would not be hard to implement in your own script, I concur, but it needs the work in any case and usually (thus far) I am not willing to put that much work into it.
Logrotate I think could be called as user, by giving it a separate configuration file than the system one. I have not investigated it, but my educated guess is that it can do that. It then can be called via cron, which a plain user has access to (unless the admin denies it). - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlcMSwAACgkQja8UbcUWM1y5ugD/bsFSCEskvw629camQJhCxZnx fmPPNjhU2R1HFgOTq+gA/27EmTyu9/IHltNlVOrqcv1VqDG3Fqmd0DijvqxF9qJ7 =ALbu -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Xen wrote:
I want something that can write to a file without having to configure it in syslog.
At some point you'll have to explain why write() doesn't suffice for that :-)
If every application writes its own logging framework, that's a lot of wasted effort. Apparently you want me to start exploring the source of e.g. squid to see how it does it. I would think people would know about these answers.
I gave you a dozen examples of programs you could examine. Yes, if I'm going to create a complicated application, certainly I will examine code examples I may reuse!
Well okay. But the reason for me asking was to discover whether that be necessary to begin with.
See if you use log4j, there is no need for you to do anything.
You can use it to log synchronously, asynchronously, to any database, to a syslog server, in any format you want, etc. etc. etc. But you understand.
Your question could perhaps have been better written as "is there a non-java equivalent of log4j?" -- Per Jessen, Zürich (9.1°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen schreef op 12-04-16 08:20:
Xen wrote:
I want something that can write to a file without having to configure it in syslog.
At some point you'll have to explain why write() doesn't suffice for that :-)
That's the same question as saying why "echo BLA >> file" doesn't suffice for that. Again, it is about having the features of (say, syslog/logrotate/cron) something a tad more advanced without having to write it yourself. Something that makes you say "hey, this is easy, now I can use that! :D". Anything that is going to be elegant requires a bit of investment, you know that. So to spell it out once more: * a library or platform or application that provides features that are similar to what syslog/logrotate/cron provides (at the very least, but it is also sufficient probably, depending on what you want) without depending on the system administrator to be able to use it in conjunction with your program. Anton responded with something but instead of explaining he just said it already exists and that he is the allpowerful user that already has everything I want ;-).
You can use it to log synchronously, asynchronously, to any database, to a syslog server, in any format you want, etc. etc. etc. But you understand.
Your question could perhaps have been better written as "is there a non-java equivalent of log4j?"
No because that question would imply that any solution for any language would suffice. The question was more about components that can also be used by Bash scripts, and it does not nearly need to be as advanced as log4j. See, the situation seems to be such that since system administrators can already use the existing solutions that require a bit of administrator intervention, nobody really has any desire for something else. I think Anton said that you can also run rsyslog(d) on some configuration file of your own? The features I asked for or was interested in learning existed, was really not something radically difficult or something. How difficult is it to consider that someone might have a need for something that already exists (but is used in a different way?). I mean you are really looking to make it harder than it is. Sometimes what a person wants is just exactly what he says. This draft is a bit older, I had forgotten about it a bit. Apologies for not completing it right away, I had to log out or reboot for some reason. I hate saving drafts ;-). I feel it is an injustice to the people I'd be sending my message to ;-). ! Whenever I want something in Linux, it is probably going to be a bit different ;-). In this case nobody would have a hard time understanding my requirements unless that person would think that my requirements were wrong. Like I mentioned in the thing that became the other thread, I would really like to be less dependent on root. Just yesterday someone posted a link of a guy who wiped all this backups and his files. With a single error in a shell script that was executed as root on a system that did not prevent that thing from happening. In Linux there are just two types of users (root and non-root) and a fun analogy is perhaps...... that I just read that in the Intel architecture there are 4 rings. But the Linux kernel only uses 2 of those: supervisor and normal user. There are four available and you only use two. Interesting. But the management model is equally primitive. A system in which you need to regularly use rm -rf as often as washing your hands, and yet that hand washing can destroy the entire building block in which you live. *not exactly well designed*. In GNU Linux apparently you are safeguarded because rm will normally not work on /. *what great safety, now I feel so safe*. Now by mistake I have to do rm -rf /* instead of rm -rf /. The backup administrator we talked about would have prevented that. But on this subject, I don't know what the OP wants anymore after we've written all of this. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Xen wrote:
Per Jessen schreef op 10-04-16 10:19:
The difference is they call him king, the difference frightens me.
What I mean is very simple, and you already know the answer.
1. Anything you write yourself you will have to write from scratch if you cannot reuse someone else's code. 2. This will take a lot of energy and is less efficient than reusing existing code if you agree with that code.
In principle this is absolutely true, in practice for a write2log() call, less so. Unless that call was part of a framework I wanted to use in my application anyway, I would not bother. It would take me less time to write my own than to learn how to use a foreign one.
Probably, but that depends on how complex those other ones are, and whether you can use it with a few simple command calls.
For instance "logger" is clearly not a complex tool. If it had a little more functionality, the same interface would be very easy to use in a script (or program).
logger consists of about 3 lines of C code: openlog(facility); syslog(prio,text); closelog(); My imagined write2log() might be roughly the same: f=open(file,O_APPEND|O_WRONLY); write(f,buffer,snprintf(buffer,sizeof(buffer),"text", vars)); close(f);
Now if those libraries don't exist, you have a problem. A certain feature in the system ecosystem is missing.
If they don't exist, you have no option but to write them yourself. I don't see a problem here.
The question was whether they exist. Logrotation and asynchronous writing and all of that is not that easy to implement. Sure, if you spend a few hours to a few days on it, sure you might have something. The whole purpose of me asking was to help the OP (and myself) to see if something might not be missing here.
Okay, although there's virtually always room for improvement, writing to a log is a fairly simply thing in 99% of cases. The last 1% - I'm not sure what they might be, maybe it's about performance or response time when writing thousands of lines per second or some such. You or the OP would need to add your input here.
If every application writes its own logging framework, that's a lot of wasted effort.
Absolutely. I don't think that is what happens either. I think most applications use something like this: write(f,buffer,snprintf(buffer,sizeof(buffer),"text", vars)); possibly with a nice macro WRITE2LOG(prio,format,vars...).
Apparently you want me to start exploring the source of e.g. squid to see how it does it. I would think people would know about these answers.
No, actually I was interested in understanding which logging features you are missing. [snip - gobbledegook]
But if a solution currently does not exist it is also because of people who cannot understand that anyone would want it.
Often there is no solution when there is no problem. Sofar I believe you have failed to describe the problem. Or maybe I'm just too thick.
"And if existing syslogd and logrotate do not fit your purposes, then what?"
This question was clearly intended to open up the space where solutions could be found.
How can anyone propose a solution when you have not presented a problem?? All you said was "existing syslogd and logrotate do not fit my purposes". Please explain your purposes, otherwise we'll never get anywhere. -- Per Jessen, Zürich (6.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2016-04-09 at 16:06 +0200, Xen wrote:
Per Jessen schreef op 09-04-16 10:50:
Xen wrote:
I must say personally I feel "logger" is quite convenient, but you don't get to specify any alternative log file.
Yes, it writes to syslog, which by default is the systemd journal. If you want it written to a file, you need to install a syslog daemon and configure it to do that.
So I guess Carlos said you can have multiple destinations in your syslog daemon configuration. Otherwise.
Yes, it can be asingle file or multiple. Typically it is one file for verbose entries, one for very important entries, and then others for some specific types: firewall, mail, news...
You don't seem to have presented us with a problem yet? Log to syslog, then have your favourite syslog daemon write it to your favourite logfile. If you need to rotate it, add a config to /etc/logrotate.d.
Otherwise it could mean you would need an additional syslog daemon for every program you want to log.
No you don't. There is only one system syslog daemon.
It also makes it impossible for any *user* to create logging without being the system administrator. All not very flexible and I guess.
Users have to use the system syslog, if the admin allows access to read the files for him, or writes their own files. There are 7 user facilities.
What if I write an application and I want to run it on a shell server on which I am just a guest.
I want it to do logging within my personal user space.
Do it yourself, with write statements in your program. Or use journalctl, which allows for user logs, I think (I don't know for sure, I haven't tried).
Just the way it would happen for me I guess. In the meantime I keep writing my own logging system (more or less) in every bash script I write, because I require different levels etc.
Yes, that's what everybody does. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlcJNyYACgkQtTMYHG2NR9XBjgCcC5ZRAOedOvSRVibgNDffRPf+ 1rYAnA03KQKGmgXMYCOhU7DL1Vz3rhJ7 =IzTz -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. schreef op 09-04-16 19:08:
There are 7 user facilities.
But the user cannot configure the target on his own right, he needs the cooperation of the system administrator.
What if I write an application and I want to run it on a shell server on which I am just a guest.
I want it to do logging within my personal user space.
Do it yourself, with write statements in your program.
To the syslog daemon?
Or use journalctl, which allows for user logs, I think (I don't know for sure, I haven't tried).
Buh. That is like going through Russia in order to arrive at Germany (starting from the Netherlands) ;-). That's my whole issue with SystemD. Instead of going straight at the easiest and most sensible solution, you first have to pay 6 intermediaries for their reference.
Just the way it would happen for me I guess. In the meantime I keep writing my own logging system (more or less) in every bash script I write, because I require different levels etc.
Yes, that's what everybody does.
Well that is not a very happy situation is it?? Including stuff in Bash scripts is annoying, otherwise I would already have found myself a logger script probably. Eventually I will though. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2016-04-09 at 19:32 +0200, Xen wrote:
Carlos E. R. schreef op 09-04-16 19:08:
There are 7 user facilities.
But the user cannot configure the target on his own right, he needs the cooperation of the system administrator.
Yes, that is so.
What if I write an application and I want to run it on a shell server on which I am just a guest.
I want it to do logging within my personal user space.
Do it yourself, with write statements in your program.
To the syslog daemon?
No, to files.
Or use journalctl, which allows for user logs, I think (I don't know for sure, I haven't tried).
Buh. That is like going through Russia in order to arrive at Germany (starting from the Netherlands) ;-).
:-)
Yes, that's what everybody does.
Well that is not a very happy situation is it??
Why not? :-o It is the same in any computing system, as far as I know.
Including stuff in Bash scripts is annoying, otherwise I would already have found myself a logger script probably.
Eventually I will though.
It might be another process. I don't know well how to communicate data from one process to another, without using the disk somehow (named pipes?) - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlcJQgMACgkQtTMYHG2NR9Ut0wCfZb4PapQPmGKd0aNOVrvQ4LOi RBkAnjgIFH6GL0+aZEWT/CKhm4s3TF1w =7Obv -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. schreef op 09-04-16 19:55:
On Saturday, 2016-04-09 at 19:32 +0200, Xen wrote:
Carlos E. R. schreef op 09-04-16 19:08:
But the user cannot configure the target on his own right, he needs the cooperation of the system administrator.
Yes, that is so.
There are many systems where this is not possible. Webhosts are one -- even webhosts running shell servers and the ability to execute programs.
Do it yourself, with write statements in your program.
To the syslog daemon?
No, to files.
Yes, that's what everybody does.
Well that is not a very happy situation is it??
Why not? :-o
It is the same in any computing system, as far as I know.
Including stuff in Bash scripts is annoying, otherwise I would already have found myself a logger script probably.
Eventually I will though.
It might be another process. I don't know well how to communicate data from one process to another, without using the disk somehow (named pipes?)
From the other email:
A user application has to write its own log files in his own user space. Completely under his control. Either he writes the code completely, or uses some library or system that already exists, such as that log4j. Many applications do this.
He can instead use the system facilities, but then he doesn't have full control.
So the question really is: where is that library? Is there such a library? Apparently and probably not because everyone believes we should use syslogd. So what is really going on in this thread is stating a use case that is not catered for. What does not exist is application-level logging facilities for Linux. There is no reason whatsoever that logging, asynchronous logging, or logrotation of any kind, should be a thing limited to the system administrator. There is also no reason why the system administrator would admonish against it, since this feature is nothing special at all. Consequently, there is no real reason why it would require administrator intervention, but then, a regular user normally cannot install programs either. (Except by compiling himself/herself). That's really the whole issue. It is black and white. The "user" that installs programs does not exist. On public shell servers, users always run programs. They often install their own programs. The user "space" is not really well defined or understood in Linux. There is no middle ground. Something that is readily availabe in Java does not even exist in Linux. Maybe it does. That's why we're asking right. I am deeply annoyed by the amount of times I need root access. This is most strongly so with e.g. packages or applications that get set up system-wide, but that do not belong there (such as wikis). On Debian et al, for instance "DokuWiki" is installed in /etc/dokuwiki, /var/lib/dokuwiki, and /usr/share/dokuwiki. The main package as per the maintainer combines this all into one. Now it runs as a package on a system and it is unmaintainable. For instance: /userstyle.css/ is a file that needs to be edited by the system administrator in /etc/dokuwiki. Now I need to be ROOT to change a stylesheet of a small wiki. If I remove the package and install it in /usr/local (for instance) I lose the benefits of the Debian package configurator. It runs in conjunction with Apache (or Lighttpd) which is nothing more than a few apache entries (probably one file in the required directory) but that's really the only thing you need administrator access for. There is no reason the application itself (/usr/share/dokuwiki) or its main configuration (/etc/dokuwiki) or its database (/var/lib/dokuwiki) should run under root. The program itself runs as www-data, but that is a group. And a user. But you cannot login to that user or work as that user. Personally I feel we need a concept of user-controlled filesystem space (outside of FHS in that sense) being managed by group rights where files are group writable by default and inherit group ownership upon creation. The g+s sticky bit. The setgid bit. This area would be maintained by "staff" group and would not impede on the operation of the system in itself. In a certain sense, that would also require a group of ports that is not privileged (1-1024) but semi-privileged (1025-2048). This "in between" just does not exist, wherever you look at it. It is either user or root. Or the program gets started as root and then relinquishes privs to become a decicated user for that program. Why not a "group" layer in between? Why not a class of users that can install programs but only in what would be considered /usr/local? It might not even be difficult to create packages that could be both installed system-wide, and as a local thing. But the concept would need to be introduced. For instance, on Debian the program "apt-file" will create a system-wide cache when run as root, or a user-created cache when run as a user. If we had a platform for this, it would be very easy. This in turn would turn the installation of many programs into something that would not even require root privs (possibly). I mean I have been doing this since like forever. I would create substed volume letters based off off trees such as C:\Programs\Games would become E:, for instance. I always created my own area. Anyway, Need to go. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-04-09 22:19, Xen wrote:
Carlos E. R. schreef op 09-04-16 19:55:
So the question really is: where is that library?
Is there such a library? Apparently and probably not because everyone believes we should use syslogd.
You forget that there are many applications in Linux that use their own logging systems.
The user "space" is not really well defined or understood in Linux. There is no middle ground. Something that is readily availabe in Java does not even exist in Linux.
Well, no. Linux, or rather Unix, was designed with a single admin with full powers. It is not that simple to modify this basic idea. On the other hand, it is quite feasible for the designer of any application to allow it to be administered by another user. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlcJkXoACgkQja8UbcUWM1x6cQD8DVt7TCmYd8Ry5m6dV5MO5h6d Fp4iCwpIqvup2fLPLMkA/3OuSBOMg46hnTEZn3kdq1ot8m3aopsZste93SZkPGC5 =YE6L -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. schreef op 10-04-16 01:34:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2016-04-09 22:19, Xen wrote:
Carlos E. R. schreef op 09-04-16 19:55:
So the question really is: where is that library?
Is there such a library? Apparently and probably not because everyone believes we should use syslogd.
You forget that there are many applications in Linux that use their own logging systems.
Which one? Or do they all reinvent the wheel?
The user "space" is not really well defined or understood in Linux. There is no middle ground. Something that is readily availabe in Java does not even exist in Linux.
Well, no. Linux, or rather Unix, was designed with a single admin with full powers. It is not that simple to modify this basic idea.
I know, but I'm trying anyway. Cause the current system causes groups to not be used, and causes problems for me. So I need to get around it anyway. At this point I still need to create a diff of changes I made against an older version of DokuWiki, then upgrade the package (on my NAS) and reapply my changes and get it working again. Then find a way to actually use the newest version so I am current with the developments. Then, try to decide how I am going to do it in my debian host....... But I'm definitely just going to get rid of the package probably and move it into its own directory where everything is tied together instead of existing in 3 trees. Then I will try to enforce group-writability on the data and see how that works out.
On the other hand, it is quite feasible for the designer of any application to allow it to be administered by another user.
You mean with a setuid program or something of the kind? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Xen wrote:
Carlos E. R. schreef op 10-04-16 01:34:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2016-04-09 22:19, Xen wrote:
Carlos E. R. schreef op 09-04-16 19:55:
So the question really is: where is that library?
Is there such a library? Apparently and probably not because everyone believes we should use syslogd.
You forget that there are many applications in Linux that use their own logging systems.
Which one? Or do they all reinvent the wheel?
See "man 2 write". If that is not enough for you, why don't you try to explain the issue you have, maybe someone will have a good idea. -- Per Jessen, Zürich (9.1°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-04-10 01:55, Xen wrote:
Carlos E. R. schreef op 10-04-16 01:34:
Is there such a library? Apparently and probably not because everyone believes we should use syslogd.
You forget that there are many applications in Linux that use their own logging systems.
Which one? Or do they all reinvent the wheel?
As I'm not a Linux programmer, I can't say if a library for the purpose exists or not. For example, procmail uses its own system. At the start of the config, you define where: LOGFILE=$HOME/procmail.log Another one: fetchmail. At the start of the config you tell it whether to use syslog or not: set syslog alternatively, use "nosyslog" and "logfile". Another. Amavis-new. I see this in the configuration (there is no man page for a quick search): $do_syslog = 1; # log via syslogd (preferred) Another one: YaST. Or zypper. That makes two. Wait! Looking at /var/log/ I notice some more: apache, consolekit, apparmor, audit, cacti, cups, gdm, lightdm, mysql, nagios, ntop, sa, samba, smpppd, snort, vmware... I notice them because they have their own log directories. There are a few more that use distinct files under /var/log/, without a separate directory, but differentiating which are used by syslog and which not is a bit more difficult. The first one is now extinct: SaX. But Xorg is not. There are some that log in binary: lastlog And I see more... Just look for yourself. :-)
The user "space" is not really well defined or understood in Linux. There is no middle ground. Something that is readily availabe in Java does not even exist in Linux.
Well, no. Linux, or rather Unix, was designed with a single admin with full powers. It is not that simple to modify this basic idea.
I know, but I'm trying anyway. Cause the current system causes groups to not be used, and causes problems for me. So I need to get around it anyway.
No, you can't. You can use tricks, but there is only one root, and he can not delegate that easily - except with sudo and groups. And acls. You can not define a root.for.mail admin that can do anything on all the mail directories and programs. Instead, you have to modify the permisions for groups on those directories, specify sudo commands for anything he might need, and provision for files that on creation/modification on those directories have appropriate permissions so that he has full control of them. A Windows server admin has a more complex and fine grained set of permissions, including creating partial administrators. Hey, I'm a Linux guy, but the truth is the truth... Not that it is simple in Windows, either. Far from it. Say, a backup admin. In Linux it has to be root.
On the other hand, it is quite feasible for the designer of any application to allow it to be administered by another user.
You mean with a setuid program or something of the kind?
Yes, something, if the application is designed from the start to be administered by somebody else. Databases, for instance, typically have a database admin with a different name from root, if specified. He probably can not install the database on the computer, though. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
No, you can't. You can use tricks, but there is only one root, and he can not delegate that easily - except with sudo and groups. And acls.
You can not define a root.for.mail admin that can do anything on all the mail directories and programs. Instead, you have to modify the permisions for groups on those directories, specify sudo commands for anything he might need, and provision for files that on creation/modification on those directories have appropriate permissions so that he has full control of them.
A Windows server admin has a more complex and fine grained set of permissions, including creating partial administrators. Hey, I'm a Linux guy, but the truth is the truth... Not that it is simple in Windows, either. Far from it.
Say, a backup admin. In Linux it has to be root.
It's not that you can't do it on Linux, it's simply that noone has put any (or enough) effort into developing a framework for managing and delegating permissions and such. You can actually do quite a lot with sudo, but yes, it's cumbersome. -- Per Jessen, Zürich (5.8°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2016-04-11 at 08:06 +0200, Per Jessen wrote:
Carlos E. R. wrote:
Say, a backup admin. In Linux it has to be root.
It's not that you can't do it on Linux, it's simply that noone has put any (or enough) effort into developing a framework for managing and delegating permissions and such. You can actually do quite a lot with sudo, but yes, it's cumbersome.
Well, the way I think about it, we would need privileged UIDs. Think of a backup admin: he needs execute permissions on all directories, and read access on all files, and those permissions must be assigned by default to all new files and directories. In effect, he needs read access to all files owned by UID 0. Another, related, feature, is seen by the trick some do of creating another admin user with UID 0 besides root. These are very basic access, they need, I think, a core redesign of how Linux/Unix work. Some kind of delegated/effective UID 0, without being it, not needing to alter the permissions of files. No, I do not know how to do it, or being more precise. :-( Perhaps negative numbers, to flag that they are special. Then a structure listing what each of those UIDs can do. Like a list of directories to which they have superseding permissions. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlcLefcACgkQtTMYHG2NR9VnBwCgkgG2x5aBEIITLkSKnGZWPEm2 egoAn0UBX2tyMh4q0kYAbUqGcEAmtvYV =7odT -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
On Monday, 2016-04-11 at 08:06 +0200, Per Jessen wrote:
Carlos E. R. wrote:
Say, a backup admin. In Linux it has to be root.
It's not that you can't do it on Linux, it's simply that noone has put any (or enough) effort into developing a framework for managing and delegating permissions and such. You can actually do quite a lot with sudo, but yes, it's cumbersome.
Well, the way I think about it, we would need privileged UIDs.
Think of a backup admin: he needs execute permissions on all directories, and read access on all files, and those permissions must be assigned by default to all new files and directories. In effect, he needs read access to all files owned by UID 0.
If somebody needed a backup admin, you're right. What I think somebody might need is a "storage admin" who will for instance manage when, what and how backups are made, but it would not mean he/she would have access to any of those backups. For _running_ the backups, some areas might still require root, but far from all. The backup process for a mysql database would require the user for that instance. The backup process for an apache vhost would require the user for that vhost. etc etc. There is software for that sort of thing out there, just not open source (as far as I have seen). Try googling e.g. "unix admin separation privileges". It's been practised at the enterprise level for decades, AIX, HP-UX and Solaris have probably all had this functionality for quite some time. -- Per Jessen, Zürich (13.1°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2016-04-11 at 12:57 +0200, Per Jessen wrote:
Carlos E. R. wrote:
There is software for that sort of thing out there, just not open source (as far as I have seen). Try googling e.g. "unix admin separation privileges".
It's been practised at the enterprise level for decades, AIX, HP-UX and Solaris have probably all had this functionality for quite some time.
Yes, I have used Unix machines with a layer on top of Unix that had that kind of access control. In essence, it was a complicated and very expensive application running on Unix and controlling who did what. There was a command, though, that gave access to the unix terminal, as root... - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlcLjIIACgkQtTMYHG2NR9VyoACfWD5mJhP5ANQMNawHP4HEho9y j6kAoJmAdPrU2DdPZvG8VN91af1TklKc =TRAA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/11/2016 06:57 AM, Per Jessen wrote:
It's been practised at the enterprise level for decades, AIX, HP-UX and Solaris have probably all had this functionality for quite some time.
IIR Solaris had "role based" access control a long time ago. Linux? Googling for "linux role based access control" produces some interesting reads. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen schreef op 11-04-16 12:57:
If somebody needed a backup admin, you're right. What I think somebody might need is a "storage admin" who will for instance manage when, what and how backups are made, but it would not mean he/she would have access to any of those backups. For _running_ the backups, some areas might still require root, but far from all. The backup process for a mysql database would require the user for that instance. The backup process for an apache vhost would require the user for that vhost. etc etc.
Having dedicated "admins" like that would really make the opportunity for creating security holes that gave access to full root, much harder to do. You could even imagine: this was my imagining. Okay don't laugh, or maybe do. What IF. You create a secret government :P. You immunize a certain set of essential files pertaining to security. You disallow root to change them. You create a hidden user that even root cannot see. Since no one but that user (or his cronies) can see the user, and since the files that govern this cannot be changed (except for the user) you have effectively created a super-root that no one knows about (except you). Now actually you also want to limit the rights of the super-root or nothing will have changed (you would just have a new root). But next you do is create a hidden part of the filesystem (again, only visible to the super-root) and you use this as the place where you keep your auditing logs, and perhaps your backups as well. Effectively it would be very much like having a different system that has different user accounts and where logs are sent to (and backups). It's actually not much different from that. Actually it's the exact same thing only on one system. You know, the idea of "someone compromises root on system A, but cannot clear his trails because the auditing has already been sent to system B, that he cannot access". So now you have a special backup daemon/user/process that also has access to this hidden area for storing the backups. I'm not sure how to do it, but the super-admin would by default not have all the same rights that root does have. The super-admin is the only one who can "invisiblize" parts of the system to everyone else. But he doesn't need (write) access to every other part of the system. Much like our real secret governments do. So the super-admin controls the core security files. He/she could therefore change them and open up everything else in the system as well..... hmmm.... But really do you not want this user to have the authority that root has. That's a logical impossibility if the super-admin can change the entire security system.... namely the programs and libraries that control it (and configurations). My system needs some working :p. The whole reason for this system is that if some hacker enters the machine, he might destroy the contents of the machine but never get access to the "safe" vault unless he knows how to get there. But knowing how to get there would be rather difficult because root would not be able to see it or find any traces of it, the backup user does, but root won't see any open file handles, you could even go so far as to hide statistics but then you'd at some point run into anomalies ;-). In fact the only way to get to the super-admin might be through some less-privileged user. But this thing might not be visible (and might still require a secret) while using all of the standard tools (such as su).
There is software for that sort of thing out there, just not open source (as far as I have seen). Try googling e.g. "unix admin separation privileges".
It's been practised at the enterprise level for decades, AIX, HP-UX and Solaris have probably all had this functionality for quite some time.
I think it is a real shame that Linux is so primitive, but then again, that makes it possible to design your own thing on top of it. The problem with "less-primitive" is that someone might design something you do not like, and now you are stuck with it (think systemd). The more primitive something is, the less chance someone will have taken a turtle and built a castle on top of it (just to name something silly). Primitive tools have the tendency to do only one thing and do them well. A hammer is a hammer. A motorized hammer with phase-shift ability might not do what you want ;-). Design flaws also have less impact if the system is small or still at its beginnings. The bigger the system is, the worse a design flaw will become.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. schreef op 11-04-16 12:18:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday, 2016-04-11 at 08:06 +0200, Per Jessen wrote:
Carlos E. R. wrote:
Say, a backup admin. In Linux it has to be root.
It's not that you can't do it on Linux, it's simply that noone has put any (or enough) effort into developing a framework for managing and delegating permissions and such. You can actually do quite a lot with sudo, but yes, it's cumbersome.
Well, the way I think about it, we would need privileged UIDs.
Think of a backup admin: he needs execute permissions on all directories, and read access on all files, and those permissions must be assigned by default to all new files and directories. In effect, he needs read access to all files owned by UID 0.
Nice thinking. In the Linux model you would need a root-user that has masked permissions. If the regular root has everything, you give a limited set (to everything) to the masked user. If then you needed something more fine-grained, you would create a mask that applies to the file system (hierarchy) in which case some trees might be completely inaccessible, others may have certain masked permissions, and so on. All filesystem operations would then consult this masking layer and inquire whether the current user has permission to do the certain thing that was requested.
Another, related, feature, is seen by the trick some do of creating another admin user with UID 0 besides root.
These are very basic access, they need, I think, a core redesign of how Linux/Unix work. Some kind of delegated/effective UID 0, without being it, not needing to alter the permissions of files.
Yeah a user that has masked permissions based on another user. That could even become a tree of users and then you have something that already closely resembles roles.
No, I do not know how to do it, or being more precise. :-(
Perhaps negative numbers, to flag that they are special. Then a structure listing what each of those UIDs can do. Like a list of directories to which they have superseding permissions.
Yes 1. an origin user 2. patterns to describe directory trees or locations 3. masks you can apply to those trees (or parts of them) Not unlike the way a firewall does it. For instance you could have origin user root. then you say a form of "deny all". then you select certain paths that the user must have access to. root has full access, so you create a mask of "-w" for instance if you don't want writing. the "deny all" really comes at the end (default chain). maybe a bit weird, but the masks are to take permissions away. However you could apply a full mask to any trees you do not define. I don't know. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen schreef op 11-04-16 08:06:
Carlos E. R. wrote:
No, you can't. You can use tricks, but there is only one root, and he can not delegate that easily - except with sudo and groups. And acls.
You can not define a root.for.mail admin that can do anything on all the mail directories and programs. Instead, you have to modify the permisions for groups on those directories, specify sudo commands for anything he might need, and provision for files that on creation/modification on those directories have appropriate permissions so that he has full control of them.
A Windows server admin has a more complex and fine grained set of permissions, including creating partial administrators. Hey, I'm a Linux guy, but the truth is the truth... Not that it is simple in Windows, either. Far from it.
Say, a backup admin. In Linux it has to be root.
It's not that you can't do it on Linux, it's simply that noone has put any (or enough) effort into developing a framework for managing and delegating permissions and such. You can actually do quite a lot with sudo, but yes, it's cumbersome.
Thank you for thinking on this. Personally I think you can get very far with what Carlos here describes, but it is also the only way. "Instead, you have to modify the permisions for groups on those directories, specify sudo commands for anything he might need, and provision for files that on creation/modification on those directories have appropriate permissions so that he has full control of them." Indeed, this is what the group feature provides. I don't really have a need for anything else at this point. It is just annoying to know how any specific application must be told to give g+w permissions to everything. And to discover if that will introduce any risks. I don't think there is yet a filesystem provision that you can say: this directory tree? Everything g+w, no matter what anyone says. In effect if you were in the position to code it, the most effective thing would be a daemon that just monitors a tree you have told it to monitor, and just fix any permissions as required. I wouldn't mind making something like that. (But I have no skill in C and system development yet). These 3 things: - group-based permissions for a certain tree - automatic "group" ownership for all included files (g+s) and automatic group permissions for all included files (g+w) - a daemon that monitors permissions and corrects them if wrong Is really something I would like to achieve.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Apr 11, 2016 at 3:31 PM, Xen <list@xenhideout.nl> wrote:
Per Jessen schreef op 11-04-16 08:06:
Carlos E. R. wrote:
No, you can't. You can use tricks, but there is only one root, and he can not delegate that easily - except with sudo and groups. And acls.
You can not define a root.for.mail admin that can do anything on all the mail directories and programs. Instead, you have to modify the permisions for groups on those directories, specify sudo commands for anything he might need, and provision for files that on creation/modification on those directories have appropriate permissions so that he has full control of them.
A Windows server admin has a more complex and fine grained set of permissions, including creating partial administrators. Hey, I'm a Linux guy, but the truth is the truth... Not that it is simple in Windows, either. Far from it.
Say, a backup admin. In Linux it has to be root.
It's not that you can't do it on Linux, it's simply that noone has put any (or enough) effort into developing a framework for managing and delegating permissions and such. You can actually do quite a lot with sudo, but yes, it's cumbersome.
Thank you for thinking on this.
Personally I think you can get very far with what Carlos here describes, but it is also the only way.
"Instead, you have to modify the permisions for groups on those directories, specify sudo commands for anything he might need, and provision for files that on creation/modification on those directories have appropriate permissions so that he has full control of them."
Indeed, this is what the group feature provides.
I don't really have a need for anything else at this point.
It is just annoying to know how any specific application must be told to give g+w permissions to everything.
And to discover if that will introduce any risks.
I don't think there is yet a filesystem provision that you can say: this directory tree? Everything g+w, no matter what anyone says.
In effect if you were in the position to code it, the most effective thing would be a daemon that just monitors a tree you have told it to monitor, and just fix any permissions as required.
I wouldn't mind making something like that. (But I have no skill in C and system development yet).
These 3 things:
- group-based permissions for a certain tree - automatic "group" ownership for all included files (g+s) and automatic group permissions for all included files (g+w) - a daemon that monitors permissions and corrects them if wrong
Is really something I would like to achieve.
Lots of conversation of giving people selective admin roles and no mention of ACLs? ACLs can be used to override the basic Linux permissions and maybe the above desire of Xen? So if a single user needs to have expanded permissions you can use ACLs to give them to them. Also, ACLs have default inherit features, so you can set a directory to cause new folders / files created within it to inherit the ACLs. So if you want to give a user rw permission to the /etc/postfix folder, just add an override ACL for him to the folder. I wrote an article on the old opensuse wiki (old-en.opensuse.org) on using ACLs to allow a sales team (group) and a finance team (group) to share a folder and have newly created files in the folder inherit the default ACL setup. Unfortunately, I don't know how to find that old wiki page and I don't think it was migrated to the new wiki (en.opensuse.org). I don't have that many edits on the old wiki, so if someone knows how to get a list of them, it shouldn't be hard to find that page again. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 2016-04-11 at 16:42 -0400, Greg Freemyer wrote:
Lots of conversation of giving people selective admin roles and no mention of ACLs?
ACLs can be used to override the basic Linux permissions and maybe the above desire of Xen?
So if a single user needs to have expanded permissions you can use ACLs to give them to them.
Also, ACLs have default inherit features, so you can set a directory to cause new folders / files created within it to inherit the ACLs.
So if you want to give a user rw permission to the /etc/postfix folder, just add an override ACL for him to the folder.
I wrote an article on the old opensuse wiki (old-en.opensuse.org) on using ACLs to allow a sales team (group) and a finance team (group) to share a folder and have newly created files in the folder inherit the default ACL setup.
Unfortunately, I don't know how to find that old wiki page and I don't think it was migrated to the new wiki (en.opensuse.org). I don't have that many edits on the old wiki, so if someone knows how to get a list of them, it shouldn't be hard to find that page again.
? https://old-en.opensuse.org/How_to_share_directories_between_groups_of_users... ? Cheers, Dave PS go to https://old-en.opensuse.org/Welcome_to_openSUSE.org and search for acl
Greg
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dave Howorth schreef op 11-04-16 23:06:
https://old-en.opensuse.org/How_to_share_directories_between_groups_of_users...
That is pretty awesome. Unusable without a GUI though. I didn't even know that thing existed man!! I have never seen anyone use it (online). I am a slight bit embarrassed. This actually solves my current problem completely. - I can just set "staff" group permissions on whatever tree I want - That doesn't even need to impact default permissions for the regular group - it works regardless of the sticky bit (I mean setgid bit). - it is transparent to everything else, and it allows default group permissions to be applied. That means not only does it give my owner/group permission, it also solves the issue of default permissions in the first place. If my web-application gets in trouble because it cannot change files I manually created, I can recursively give everything g+w and default g+w with just two commands. I don't really like the solution but it works like a breeze. It is like an overriding permission system. It just completely ignores existing permissions and just adds whatever I want to it. Want to give write permissions to the entire filesystem to my user? No issue. One command :p. LOL. It's that LS shows the additional permissions with a + at the end, or you could use this as a hacking tool in case you rooted something and just wanted to give your regular user a way to get back into root if you lost access :P. Like being able to edit the sudoers file or /shadow/passwd :P. AWESOME :P. "Wait, what's that + doing there? HEY!" haha. Thanks man :). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Apr 11, 2016 at 6:11 PM, Xen <list@xenhideout.nl> wrote:
Dave Howorth schreef op 11-04-16 23:06:
https://old-en.opensuse.org/How_to_share_directories_between_groups_of_users...
That is pretty awesome. Unusable without a GUI though.
I didn't even know that thing existed man!! I have never seen anyone use it (online).
I am a slight bit embarrassed.
This actually solves my current problem completely
It is a hassle to work with, but very flexible at the end of the day. That's why I was surprised the thread was pretty deep and no one had brought it up yet. fyi: Windows has ACLs for NTFS as well. I find them a nightmare to work with in Windows. I think they are much cleaner in Linux. Greg -- Greg Freemyer www.IntelligentAvatar.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer schreef op 12-04-16 00:30:
It is a hassle to work with, but very flexible at the end of the day.
The syntax is not even inconvenient. It is pretty easy to add something to a group, or even to change the default (for newly created files). It's just that without a GUI you won't have any real awareness of it and now you need to 'constantly' use that getfacl to keep an awareness of the condition of your system. In addition to the fact that it just completely overrides everything. As a test I just gave myself write permission to some file in /etc. No problem at all. Makes system maintenance a lot easier though. Any file you regularly need to change? Just add your user. The issue I have with it is that it breaks all sense of sanity around the organisation of your filesystem. Now no longer need something to be in the right place, every place is now a right place ;-). Oh my user needs to edit a tree in /etc? Sure, no problem. Oh really that tree doesn't belong in /etc? Who cares! The thing doesn't exist on my NAS, not even as a third party package. Of course the NAS uses its own system. (( Funny thing. I map root to guest in NFS. In the NAS configuration, Guest does not have write access. However Guest is a member of Users, and I have given Users write access to a certain folder. Now Guest still has write access, because the NAS config only applies to shares. Ie. stuff exported through samba etc. However I have not set up nfs mapping. The remote user (of the nfs client) is different (in UID) than the local user (on the NAS). So my remote user actually doesn't have access. But root has, because it is guest. My intent was the exact reverse :p. I don't actually want these users to be mapped onto each other. I think I will just be bad and create two "Alien" users. Alien on the NAS will have the UID of the remote user, and Alien on the client will have the UID of my NAS user :p. Then, Alien will have write access on the NAS because I will give it some important group. Also, native files on the NAS will show up as "alien" on the remote. And files written by remote will show up as "alien" on the NAS. I just don't want these names to be linked/coupled. )).
That's why I was surprised the thread was pretty deep and no one had brought it up yet.
fyi: Windows has ACLs for NTFS as well. I find them a nightmare to work with in Windows. I think they are much cleaner in Linux.
Greg -- Greg Freemyer www.IntelligentAvatar.net
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Xen <list@xenhideout.nl> writes:
It's just that without a GUI you won't have any real awareness of it and now you need to 'constantly' use that getfacl to keep an awareness of the condition of your system.
I get interested, so I did some research. There seem to be Eiciel[1], which is part of OpenSUSE Charles Footnotes: [1] http://www.linux-mag.com/id/2735/ -- "It's God. No, not Richard Stallman, or Linus Torvalds, but God." (By Matt Welsh)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2016-04-11 at 21:07 -0400, Charles Philip Chan wrote:
I get interested, so I did some research. There seem to be Eiciel[1], which is part of OpenSUSE
It comes with a plugin for nautilus. I'm going to have a look. [...] Yes, on file properties it appears a new tab named "Access Control List". It a shame, though, that "ls" is not aware of ACL. It just prints a "+" to say that they exist, but you have to use other tools to find out more. The man page for "ls" doesn't say a word. Only a mention in the info page: A file with any other combination of alternate access methods is marked with a `+' character. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlcOVAoACgkQtTMYHG2NR9Wq0gCgj7h8czaEBdbfqUh/44UCVcuH h6wAn1YELQbCekfAtdEtzGD3LoTEtx6p =353O -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer schreef op 12-04-16 00:30:
fyi: Windows has ACLs for NTFS as well. I find them a nightmare to work with in Windows. I think they are much cleaner in Linux.
Yeah, it's horrid isn't it. Windows these days locks everything down in C:\Program Files. And some other dirs are even worse. Gaining access to something might mean half an hour of messing around because you have to do everything in the right order, oh and then at the end of the day you discover that a certain kind of override doesn't work, or you cannot give permissions to the user if the group denies it, or vice versa, or ..... I may have one question though, maybe you can answer it. ** What happens if you make a tar backup of ACL-ed files? ** Easy to test. It does, if you specify --acls when both saving and extracting the files. (I think). Another flag to remember. However, whenever I am not superuser, it will not preserve any ownership (which is in a sense logical) (but at the same time it will preserve all ACL rights). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2016-04-12 at 02:27 +0200, Xen wrote:
Another flag to remember. However, whenever I am not superuser, it will not preserve any ownership (which is in a sense logical) (but at the same time it will preserve all ACL rights).
So, can we have a backup admin using ACLs? - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlcM42kACgkQtTMYHG2NR9U7mwCfYx8LR7d0p9p4vwk360T5URA3 XAwAoJKdmiPfov3JMWz99qtxsS3waEfz =sQKq -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. schreef op 12-04-16 14:00:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday, 2016-04-12 at 02:27 +0200, Xen wrote:
Another flag to remember. However, whenever I am not superuser, it will not preserve any ownership (which is in a sense logical) (but at the same time it will preserve all ACL rights).
So, can we have a backup admin using ACLs?
Yes you can have anything. There are no limits to the system. However it probably does require permissions (ACLs) to be propagated down a tree on every file creation, and this is the administrative burden. You need to ensure that these ACLs are set, and if some user takes it away, you lose permissions. I think. There is not some kind of master permission on the root of some tree, that is going to apply to all files indiscriminately, I think. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-04-12 14:45, Xen wrote:
Carlos E. R. schreef op 12-04-16 14:00:
So, can we have a backup admin using ACLs?
Yes you can have anything. There are no limits to the system.
I'll expand. Will user and group permissions be kept on the backup copy made by a plain user? Or will they be changed to be owned by the user doing the backup? I believe they are changed, so the answer to my question is "not quite". -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Tue, Apr 12, 2016 at 9:02 AM, Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2016-04-12 14:45, Xen wrote:
Carlos E. R. schreef op 12-04-16 14:00:
So, can we have a backup admin using ACLs?
Yes you can have anything. There are no limits to the system.
I'll expand. Will user and group permissions be kept on the backup copy made by a plain user? Or will they be changed to be owned by the user doing the backup?
I believe they are changed, so the answer to my question is "not quite".
Untested, but logically the backup should maintain the correct data assuming the backup tool understands ACLs. 15 years ago when I was experimenting with ACLs, "star" was a modified version of tar that groked ACLs in the backup set. The issue is the restore. I suspect only root can do a restore and get everything set correctly. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-04-12 18:58, Greg Freemyer wrote:
On Tue, Apr 12, 2016 at 9:02 AM, Carlos E. R. <> wrote:
I'll expand. Will user and group permissions be kept on the backup copy made by a plain user? Or will they be changed to be owned by the user doing the backup?
I believe they are changed, so the answer to my question is "not quite".
Untested, but logically the backup should maintain the correct data assuming the backup tool understands ACLs.
If the backup is somekind of archive, it should work. But if the backup is something like rsync, which creates identical files on the destination, I have my doubts.
15 years ago when I was experimenting with ACLs, "star" was a modified version of tar that groked ACLs in the backup set.
The issue is the restore. I suspect only root can do a restore and get everything set correctly.
Yes, I think so. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Tue, Apr 12, 2016 at 2:26 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2016-04-12 18:58, Greg Freemyer wrote:
On Tue, Apr 12, 2016 at 9:02 AM, Carlos E. R. <> wrote:
I'll expand. Will user and group permissions be kept on the backup copy made by a plain user? Or will they be changed to be owned by the user doing the backup?
I believe they are changed, so the answer to my question is "not quite".
Untested, but logically the backup should maintain the correct data assuming the backup tool understands ACLs.
If the backup is somekind of archive, it should work. But if the backup is something like rsync, which creates identical files on the destination, I have my doubts.
note rsync has a "--acls" arg which is supposed to copy the ACLs to the desitination. But I doubt it would work perfectly if not run as root.
15 years ago when I was experimenting with ACLs, "star" was a modified version of tar that groked ACLs in the backup set.
The issue is the restore. I suspect only root can do a restore and get everything set correctly.
Yes, I think so.
which is why I suspect rsync will fail. It is effectively doing a "restore" of the folder structure at the destination. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-04-12 20:33, Greg Freemyer wrote:
On Tue, Apr 12, 2016 at 2:26 PM, Carlos E. R. <> wrote:
Yes, I think so.
which is why I suspect rsync will fail. It is effectively doing a "restore" of the folder structure at the destination.
Yes, that's what I think. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Tue, 2016-04-12 at 14:33 -0400, Greg Freemyer wrote:
On Tue, Apr 12, 2016 at 2:26 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2016-04-12 18:58, Greg Freemyer wrote:
On Tue, Apr 12, 2016 at 9:02 AM, Carlos E. R. <> wrote:
I'll expand. Will user and group permissions be kept on the backup copy made by a plain user? Or will they be changed to be owned by the user doing the backup?
I believe they are changed, so the answer to my question is "not quite".
Untested, but logically the backup should maintain the correct data assuming the backup tool understands ACLs.
If the backup is somekind of archive, it should work. But if the backup is something like rsync, which creates identical files on the destination, I have my doubts.
note rsync has a "--acls" arg which is supposed to copy the ACLs to the desitination.
But I doubt it would work perfectly if not run as root.
Run rsync as a daemon "The daemon must run with root privileges if you wish to use chroot, to bind to a port numbered under 1024 (as is the default 873), or to set file ownership. Otherwise, it must just have permission to read and write the appropriate data, log, and lock files." It's pretty secure I think. But in any case, the permissions on the backup server are a separate concern to those on the source machine. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dave Howorth schreef op 12-04-16 22:27:
On Tue, 2016-04-12 at 14:33 -0400, Greg Freemyer wrote:
But I doubt it would work perfectly if not run as root.
Run rsync as a daemon
"The daemon must run with root privileges if you wish to use chroot, to bind to a port numbered under 1024 (as is the default 873), or to set file ownership. Otherwise, it must just have permission to read and write the appropriate data, log, and lock files."
It's pretty secure I think. But in any case, the permissions on the backup server are a separate concern to those on the source machine.
The issue is not really with restoring "root" it would be quite obvious you would need "root" for that. I think nobody really would want to restore a full system using some sub-role or semi-administrator. Then the issue is more specific data trees. The reason you have a "data" administrator would be that that person can be responsible for data maintenance. If this data guy is going to be the one doing backups and restores, you have a problem if this guy cannot even set ownership of trees under his control, if the files have a diversity of ownerships. There would need to be a form of way to guarantee being allowed to set ownership:group. In Linux there is no setuid for files, but I read that it exists in some BSD. Maybe the change would just require a set-ownership ACL permission. I'm not sure what the conceptual objection is to setting the ownership of files to other people. "He framed me!" Conceptually perhaps it would require that the data administrator is by definition (or by configuration) a "higher-up". That logically it would be a staff role. And this staff role then needs the privilege to set ownership. But really only for the tree under his control, which would return the issue to ACLs. Personally I am still thinking about a system-wide masking solution, but that in itself precludes "users" doing that stuff on their own. Then again, users cannot create users anyway (neat feature). Maybe you could even think of a system where members of a group, and a group can have a administrator role assigned, and this is a user flag and if this user flag is set, this user can set permissions of any files to any user (ownership I mean) to any user that is also part of his group. But that requires a group hierarchy. MAYBE just a set-permission (set ownership) ACL that you can give to any group or user. AND setting this ACL requires root. That's like delegated authority. A system of delegated authority. Root sets backup ability on a directory (tree) and gives it to a user or group. Restoration now only requires an entry point (directory) that has the required ACL for that backup admin, and restoration now causes this ACL to propagate down the tree, while restoring all other ACLs from the archive. Meh. I guess. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Apr 12, 2016 at 8:45 AM, Xen <list@xenhideout.nl> wrote:
Carlos E. R. schreef op 12-04-16 14:00:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday, 2016-04-12 at 02:27 +0200, Xen wrote:
Another flag to remember. However, whenever I am not superuser, it will not preserve any ownership (which is in a sense logical) (but at the same time it will preserve all ACL rights).
So, can we have a backup admin using ACLs?
Yes you can have anything. There are no limits to the system.
However it probably does require permissions (ACLs) to be propagated down a tree on every file creation, and this is the administrative burden.
You need to ensure that these ACLs are set, and if some user takes it away, you lose permissions. I think.
There is not some kind of master permission on the root of some tree, that is going to apply to all files indiscriminately, I think.
I'm not truly expert with ACLs, but I think you can set a default ACL in every currently existing folder to be inherited by any newly created files and folders that are direct children of the folder. So if you create a "backup" user and give it read access to every existing folder and file and also make that ACL be applied to newly created files and folders by default, all should be good. If someone wants to block access to the "backup" user, then that can be done but it takes an active step on the part of the file owner (or root). The bigger issue might be restores. It may require root access to properly restore a random file tree. This whole backup (and restore) user concept implemented via ACLs would make a good post for a blog (lizards?). fyi: With windows the Backup role can actually have more access than the Administrator role. I've tried to access the equivalent of /dev/sda on a windows box before and have it fail for the Administrator. We had to add the backup role to the Administrator account before it would work. As far as I know that level of granular access is beyond what Linux ACLs can provide. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Apr 11, 2016 at 5:06 PM, Dave Howorth <dave@howorth.org.uk> wrote:
On Mon, 2016-04-11 at 16:42 -0400, Greg Freemyer wrote:
Lots of conversation of giving people selective admin roles and no mention of ACLs?
ACLs can be used to override the basic Linux permissions and maybe the above desire of Xen?
So if a single user needs to have expanded permissions you can use ACLs to give them to them.
Also, ACLs have default inherit features, so you can set a directory to cause new folders / files created within it to inherit the ACLs.
So if you want to give a user rw permission to the /etc/postfix folder, just add an override ACL for him to the folder.
I wrote an article on the old opensuse wiki (old-en.opensuse.org) on using ACLs to allow a sales team (group) and a finance team (group) to share a folder and have newly created files in the folder inherit the default ACL setup.
Unfortunately, I don't know how to find that old wiki page and I don't think it was migrated to the new wiki (en.opensuse.org). I don't have that many edits on the old wiki, so if someone knows how to get a list of them, it shouldn't be hard to find that page again.
? https://old-en.opensuse.org/How_to_share_directories_between_groups_of_users... ?
Perfect. Thanks, I didn't realize that page is from 2007 (9 years old!). It doesn't do exactly what I recalled, but it is still a decent intro to how ACLs can be used to give the "management" team access to 2 other groups files without giving management full root access. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer schreef op 12-04-16 00:16:
Perfect. Thanks,
I didn't realize that page is from 2007 (9 years old!).
It doesn't do exactly what I recalled, but it is still a decent intro to how ACLs can be used to give the "management" team access to 2 other groups files without giving management full root access.
What more did you expect it to do / list? It cannot just give "management" access to two directories belonging to other groups, it can also give group "IAM YOUR ENEMY" access to everything else on the system you don't want it to have access to :P. And even a single user as well. Pretty awesome. Just override everything. Add a ACL and override everything. Who cares about regular permissions right. :). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Apr 11, 2016 at 6:24 PM, Xen <list@xenhideout.nl> wrote:
Greg Freemyer schreef op 12-04-16 00:16:
Perfect. Thanks,
I didn't realize that page is from 2007 (9 years old!).
It doesn't do exactly what I recalled, but it is still a decent intro to how ACLs can be used to give the "management" team access to 2 other groups files without giving management full root access.
What more did you expect it to do / list?
I just remembered the goal of the write-up to be different. I was thinking there were 2 groups (sales / finance), but there was a single folder they could drop stuff into and know both teams could read/write everything in that folder. That can be done, it just wasn't what the write-up did.
It cannot just give "management" access to two directories belonging to other groups, it can also give group "IAM YOUR ENEMY" access to everything else on the system you don't want it to have access to :P.
And even a single user as well. Pretty awesome.
Just override everything. Add a ACL and override everything.
Who cares about regular permissions right.
:).
Xen the hacker on the loose! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2016-04-08 at 17:35 +0200, Xen wrote:
I must say personally I feel "logger" is quite convenient, but you don't get to specify any alternative log file.
You can use one of the seven local or user facilities, and then configure the syslog daemon to send that to a different file. Or, use logger with a defined "--tag", and filter on it.
Personally I would prefer a more custom made or personal thing that logs only stuff that I want personally to be logged.
Yes, but syslog takes care of timestamp and caching the writes. And rotating the files is easy. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlcI3V4ACgkQtTMYHG2NR9V7pgCeJnr8b7308jWqm5wcaU/m6Zoh TsgAn3W7kWsDH0SRDbckGR5Y8/G/EZaE =TzoE -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Billy.Zheng(zw963) schreef op 08-04-16 16:51:
2. I need a common startup script for squid to start. simply enough, I add one line in my crontab '@reboot /usr/local/bin/start_squid' `start_squid' is a bash script for start squid correctly.
3. i want to record log to file, for some net analysis. I am not a linux administrator, less experience for logger, i hope spend minimum cost to achieve a sysetm logger like service. function included following: - rotately automatically. - can be output real time if need.
You do know squid outputs to its own logfile right? Normally it would output to /var/log/squid. If you have it installed under /usr/local it could for instance be /usr/local/squid/var/log/squid Or any of the kind. You get to specify those directories when you compile. I think they are ./configure options. Regards. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
You do know squid outputs to its own logfile right? Normally it would output to /var/log/squid.
Yes.
You get to specify those directories when you compile.
I think they are ./configure options.
Yes. It is a improper example here. but, some package, e.g. shadowsocks (one socks5 proxy), it just output log to stdout, when run in background, i need add log myself. -- Geek, Rubyist, Emacser 程序员中的牛逼运维， 运维中的牛逼程序员。 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Billy.Zheng(zw963) schreef op 09-04-16 08:30:
You do know squid outputs to its own logfile right? Normally it would output to /var/log/squid.
Yes.
You get to specify those directories when you compile.
I think they are ./configure options.
Yes.
It is a improper example here.
but, some package, e.g. shadowsocks (one socks5 proxy), it just output log to stdout, when run in background, i need add log myself.
I think: - edit /etc/logrotate.conf OR create custom logrotate.conf - in latter case add custom user crontab for it - add a line and file to a custom /etc/rsyslog.d/ file, in other words based on /etc/rsyslog.d/50-default.conf (on my system), add a facility.priority pair (such as user.info) This is the list of facilities: auth, authpriv, cron, daemon, kern, lpr, mail, news, syslog, user, uucp and local0 through local7 This is the list of priorities: debug, info, notice, warning, err, crit, alert, emerg - now feed the output of your program to "logger -p facility.priority". - or possibly "logger -p facility.priority -t tag" Now the regular syslog daemon (rsyslog) should output the log of that specific program to that specific file associated with that specific facility.priority pair. This what you guys mean right. Thank you Carlos? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2016-04-09 at 16:24 +0200, Xen wrote:
I think:
- edit /etc/logrotate.conf OR create custom logrotate.conf - in latter case add custom user crontab for it - add a line and file to a custom /etc/rsyslog.d/ file, in other words based on /etc/rsyslog.d/50-default.conf (on my system), add a facility.priority pair (such as user.info)
This is the list of facilities:
auth, authpriv, cron, daemon, kern, lpr, mail, news, syslog, user, uucp and local0 through local7
This is the list of priorities:
debug, info, notice, warning, err, crit, alert, emerg
- now feed the output of your program to "logger -p facility.priority".
- or possibly "logger -p facility.priority -t tag"
Now the regular syslog daemon (rsyslog) should output the log of that specific program to that specific file associated with that specific facility.priority pair.
This what you guys mean right.
Thank you Carlos?
Yes, that's a nice summary :-) - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlcJOVAACgkQtTMYHG2NR9UuXgCfX2Ypu65lxQ7tN0o8GMD+16Rc 8pQAn2cdDHWiky1acHpRpjnG7KoX/nff =R8Hv -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Xen writes:
Billy.Zheng(zw963) schreef op 09-04-16 08:30:
You do know squid outputs to its own logfile right? Normally it would output to /var/log/squid.
Yes.
You get to specify those directories when you compile.
I think they are ./configure options.
Yes.
It is a improper example here.
but, some package, e.g. shadowsocks (one socks5 proxy), it just output log to stdout, when run in background, i need add log myself.
I think:
- edit /etc/logrotate.conf OR create custom logrotate.conf - in latter case add custom user crontab for it - add a line and file to a custom /etc/rsyslog.d/ file, in other words based on /etc/rsyslog.d/50-default.conf (on my system), add a facility.priority pair (such as user.info)
This is the list of facilities:
auth, authpriv, cron, daemon, kern, lpr, mail, news, syslog, user, uucp and local0 through local7
This is the list of priorities:
debug, info, notice, warning, err, crit, alert, emerg
- now feed the output of your program to "logger -p facility.priority".
- or possibly "logger -p facility.priority -t tag"
Now the regular syslog daemon (rsyslog) should output the log of that specific program to that specific file associated with that specific facility.priority pair.
This what you guys mean right.
Thank you Carlos?
Cool. Though, complex a little for a ruby programmer => me. ;) I will try it later. Thanks. -- Geek, Rubyist, Emacser 程序员中的牛逼运维， 运维中的牛逼程序员。 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Billy.Zheng(zw963) wrote:
basically, the reason is, e.g. squid, though some like improper. because squid have own log builtin support when compile.
1. I want to use the last version squid in my VPS. so, i have to compile it myself.
2. I need a common startup script for squid to start. simply enough, I add one line in my crontab '@reboot /usr/local/bin/start_squid' `start_squid' is a bash script for start squid correctly.
3. i want to record log to file, for some net analysis. I am not a linux administrator, less experience for logger, i hope spend minimum cost to achieve a sysetm logger like service. function included following: - rotately automatically. - can be output real time if need.
Is the openSUSE supplied squid really too old for your purposes? It seems it would be a lot less work to use that.
I often read log when in programming development, so i think log is useful in this case.
The problem is:
1. What is the correct way to add my startup script log into journalctl or something else?
You create a systemd service unit, maybe "mysquid.service". See man systemd.service for details and look at some existing ones for inspiration. Or install squid from the openSUSE repo, and just update the service unit to fit your squid binary.
2. if use `ssh -vvv 2>~/ssh.log' way, should i must to add rotately function myself ? is there exist convenient way for this?
AFAIK, as long as ssh is running, ~/ssh.log will be kept open. If you rotate that file, ssh will need to be restarted.
-- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon?
As Anton hinted above, please don't top-post, it's a bad habit. -- Per Jessen, Zürich (6.6°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Is the openSUSE supplied squid really too old for your purposes? It seems it would be a lot less work to use that.
yes, my first VPS is centOS, it very old, though openSUSE is better. (current stable serious is 3.5.x, openSUSE is 3.3,13, almost one and half year ago) when I meet some problem, I sent a help email to squid mailist, they told me my squid is too old, and more self-defined configure options is added/changed. so, I write a general-use deploy script, which download and compile newest stable squid when deploy VPS.
As Anton hinted above, please don't top-post, it's a bad habit.
i just know about what is `top-post', thanks. -- Geek, Rubyist, Emacser 程序员中的牛逼运维， 运维中的牛逼程序员。 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/02/2016 10:27 PM, Billy.Zheng (zw963) wrote:
My VPS use openSUSE 42.1, I deploy some application in it, with some self-defined boot start bash scripts, I want a simple way to write all application log to same file.
start_some_application |logger
I hope it logger output to one file which I familiar and commonly. the only I know from slackware is /var/log/messages.
so, I don't know if some *service* is depend on /var/log/message.
In Date: Wed, 02 Mar 2016 02:26:52 +0800 Message-ID: <87h9gq6olv.fsf@163.com> You said
And, some service is not start correctly cause this file missing?
So long as the application/service/daemon/whatever uses the syslog protocols there should not be a problem. Why would a program want to write directly to /var/log/<anything>? After all. you make calls to the system to write rather than writing directly to the disk and trying to replicate the file system drivers inside applications. I think your problem here has to do with this: Why are you logging activity? Most desktop users have little use for the logs under normal conditions, they are there for when things go wrong or as a record of "when did I do that?". When things go wrong its different and logging is turned right up and the logs are viewed in real-time. Think, for example, of "ssh -vvvvv". The real-time viewing of that can be done with filtering ("artificial ignorance" of other items) using journalctl. Its different for a large installation,a bank, brokerage, ISP, where either activity needs to be recorded and retailed (... for six months ... for 7 years ...) or where the real time activity of illegal intrusion or ex-filtration needs to be spotted and responded to. But once again, the high level tools, possibly even ones that come from 3rd parties, are there and there is no need for low level file activity. I can imagine other types of logging. I keep a hand written book that regular readers will record me mentioning, in which I record my 'experiment's and trials' and the reasons for the decisions I made and my thoughts about the results. My recent posing about creating an encrypted LVM LV is an example of that. Why hand written and not on-line? It needs to be accessible when I'm off-line, for example when carrying out an installation. So, what is the purpose of the logging that you are wrestling with here? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Most desktop users have little use for the logs under normal conditions,
I use linux four years, I almost not write any log. in fact, in my opinion, a programmer which can read linux log is a better programmer. (not every coder have a habit to read log) in fact, my server exist some little program which only output log to STDOUT, no daemon mode built-in, I start up those service from crontab with @reboot keywoard is worked well for me, but I could not read log anymore, so i want to log with some CORRECT way. auto rotated support, convenience for view. this application is a proxy like package, I want to find out accessed ip if i need, this not a big or frequently logger, bit it useful, i just want to try standardize this process, and find out the correct way to do this. Thanks. Anton Aylward writes:
On 03/02/2016 10:27 PM, Billy.Zheng (zw963) wrote:
My VPS use openSUSE 42.1, I deploy some application in it, with some self-defined boot start bash scripts, I want a simple way to write all application log to same file.
start_some_application |logger
I hope it logger output to one file which I familiar and commonly. the only I know from slackware is /var/log/messages.
so, I don't know if some *service* is depend on /var/log/message.
In
Date: Wed, 02 Mar 2016 02:26:52 +0800 Message-ID: <87h9gq6olv.fsf@163.com>
You said
And, some service is not start correctly cause this file missing?
So long as the application/service/daemon/whatever uses the syslog protocols there should not be a problem. Why would a program want to write directly to /var/log/<anything>?
After all. you make calls to the system to write rather than writing directly to the disk and trying to replicate the file system drivers inside applications.
I think your problem here has to do with this:
Why are you logging activity?
Most desktop users have little use for the logs under normal conditions, they are there for when things go wrong or as a record of "when did I do that?". When things go wrong its different and logging is turned right up and the logs are viewed in real-time. Think, for example, of "ssh -vvvvv". The real-time viewing of that can be done with filtering ("artificial ignorance" of other items) using journalctl.
Its different for a large installation,a bank, brokerage, ISP, where either activity needs to be recorded and retailed (... for six months ... for 7 years ...) or where the real time activity of illegal intrusion or ex-filtration needs to be spotted and responded to. But once again, the high level tools, possibly even ones that come from 3rd parties, are there and there is no need for low level file activity.
I can imagine other types of logging. I keep a hand written book that regular readers will record me mentioning, in which I record my 'experiment's and trials' and the reasons for the decisions I made and my thoughts about the results. My recent posing about creating an encrypted LVM LV is an example of that. Why hand written and not on-line? It needs to be accessible when I'm off-line, for example when carrying out an installation.
So, what is the purpose of the logging that you are wrestling with here?
-- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon?
-- Geek, Rubyist, Emacser 程序员中的牛逼运维， 运维中的牛逼程序员。 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
echo 'some special log output' | xargs logger
My release is openSUSE 42.1, where is my logger to find? There is not exist a file named /var/log/messages (Like Slackware linux I used.) Per Jessen writes:
Billy.Zheng(zw963) wrote:
From logger command man:
logger - a shell command interface to the syslog(3) system log module
So, I want to use this command to write log to syslog.
following is a test:
$: echo 'some special log output' |logger
but, i could not found anything about my log in /var/log/.
From the man page:
logger [options] [message]
For your test to work:
$: echo 'some special log output' | xargs logger
-- Per Jessen, Zürich (6.0°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland.
-- Geek, Rubyist, Emacser Homepage: http://zw963.github.io -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-03-01 19:25, Billy.Zheng (zw963) wrote:
There is not exist a file named /var/log/messages (Like Slackware linux I used.)
Of course it doesn't. openSUSE uses systemd, meaning that there is no syslog by default. You have to use instead the systemd log, which you access via command "journalctl". Read its manual. Alternatively, you can install a syslog daemon. syslog-ng, rsyslog... - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF0EAREIAAYFAlbV9MwACgkQja8UbcUWM1wuLwD/dwk9rqrK+HvQiYa9uPjOYFMf HiT+DOZgTwGtMjzNEi0A+PJ1A0qqj95ZFQsJWnT7NW3hC8knn4a6QWaVhzc44mM= =QHJa -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2016-03-01 19:25, Billy.Zheng (zw963) wrote:
There is not exist a file named /var/log/messages (Like Slackware linux I used.)
Of course it doesn't. openSUSE uses systemd, meaning that there is no syslog by default.
Actually, that was by choice because someone decided there was no need for a syslog daemon. -- Per Jessen, Zürich (3.7°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2016-03-01 19:25, Billy.Zheng (zw963) wrote:
There is not exist a file named /var/log/messages (Like Slackware linux I used.) Of course it doesn't. openSUSE uses systemd, meaning that there is no syslog by default.
Actually, that was by choice because someone decided there was no need for a syslog daemon.
Wasn't that a side effect of someone deciding the default would be for SDto log as little as possible, and what it does log, it was to keep in transient storage so the log would be cleared each boot? Wait till a forensic FBI person asks SuSE for the log on a SD system, and SuSE explaining that they needed to specify the period they wanted to keep, in advance, but otherwise handing over logs would be a violation of apple's, er, suse's privacy policy...? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Linda Walsh wrote:
Per Jessen wrote:
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2016-03-01 19:25, Billy.Zheng (zw963) wrote:
There is not exist a file named /var/log/messages (Like Slackware linux I used.) Of course it doesn't. openSUSE uses systemd, meaning that there is no syslog by default.
Actually, that was by choice because someone decided there was no need for a syslog daemon.
Wasn't that a side effect of someone deciding the default would be for SDto log as little as possible, and what it does log, it was to keep in transient storage so the log would be cleared each boot?
To be honest, I'm not sure. I seem to recall something about a syslog daemon being superfluous because the journal does it all. Maybe also something about the main target user of openSUSE not needing a syslog? It matters not, just one more thing for the checklist when installing :-) -- Per Jessen, Zürich (4.6°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 02/03/2016 09:17, Per Jessen a écrit :
To be honest, I'm not sure. I seem to recall something about a syslog daemon being superfluous because the journal does it all. Maybe also something about the main target user of openSUSE not needing a syslog?
It matters not, just one more thing for the checklist when installing :-)
all the logs are here in leap, simply not accessible on the same way. dmesg works as always, journalctl works very well jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-02 09:17, Per Jessen wrote:
It matters not, just one more thing for the checklist when installing :-)
Besides that, it means more work on the cpu and disk, because it writes a log that I do not use (the journal) and syslog, than I do use. The journal can take gigabytes after two weeks with the computer running. Telcontar:~ # journalctl --disk-usage Journals take up 272.0M on disk. Telcontar:~ # Telcontar:~ # uptime 10:02am up 5 days 1:07, 40 users, load average: 0.30, 0.30, 0.27 Telcontar:~ # It is bigger than /var/log, which covers years of data: Telcontar:~ # du -hcsS /var/log 264M /var/log <=== 1.1G total Telcontar:~ # Despite having: /etc/systemd/journald.conf: SystemMaxUse=100M RuntimeMaxFileSize=200M A lot of that is mail and nntp logs. I would like to selectively purge the journal, but no idea how to, even if possible. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 03/02/2016 03:17 AM, Per Jessen wrote:
To be honest, I'm not sure. I seem to recall something about a syslog daemon being superfluous because the journal does it all. Maybe also something about the main target user of openSUSE not needing a syslog?
It matters not, just one more thing for the checklist when installing :-)
Indeed. There's also the matter of speed. In a corporate setting logging of activity is important. But writing to a file is slow. Some of the higher end activity analysers used by, for example, banks, to detect suspicious (read: 'nefarious') activity end up writing to a database. perhaps that's faster. The whole idea of the journald is that it is faster to have the events logged a binary and only translated to human readable when needed. APIs for accessing the binary for scanning are there. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
In a corporate setting logging of activity is important. But writing to a file is slow. Some of the higher end activity analysers used by, for example, banks, to detect suspicious (read: 'nefarious') activity end up writing to a database. perhaps that's faster.
Almost certainly not. It's the same data that needs to end up on disk, adding a database to the mix will slow it down, but make analysis and structured access easier.
The whole idea of the journald is that it is faster to have the events logged a binary and only translated to human readable when needed.
Anton, it's a bit early for april fools. Most stuff logged to syslog comes in text format anyway. I am not sure what the whole idea of systemd was or is or was meant to be, but it was certainly about not speed for corporate settings. -- Per Jessen, Zürich (3.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Anton Aylward wrote:
In a corporate setting logging of activity is important. But writing to a file is slow. Some of the higher end activity analysers used by, for example, banks, to detect suspicious (read: 'nefarious') activity end up writing to a database. perhaps that's faster.
Almost certainly not. It's the same data that needs to end up on disk, adding a database to the mix will slow it down, but make analysis and structured access easier.
The whole idea of the journald is that it is faster to have the events logged a binary and only translated to human readable when needed.
Anton, it's a bit early for april fools. Most stuff logged to syslog comes in text format anyway. I am not sure what the whole idea of systemd was or is or was meant to be, but it was certainly about not
s/systemd/systemd journal/ -- Per Jessen, Zürich (2.8°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-02 18:37, Per Jessen wrote:
Anton Aylward wrote:
In a corporate setting logging of activity is important. But writing to a file is slow. Some of the higher end activity analysers used by, for example, banks, to detect suspicious (read: 'nefarious') activity end up writing to a database. perhaps that's faster.
Almost certainly not. It's the same data that needs to end up on disk, adding a database to the mix will slow it down, but make analysis and structured access easier.
That's it. It is machine reading without needing to parse the results what is faster, because it is already "parsed", so to speak. In fact, reading (dumping) the systemd journal is terribly slow because (educated guess) heavy on disk fragmentation. Unless the HD is an SSD.
The whole idea of the journald is that it is faster to have the events logged a binary and only translated to human readable when needed.
Anton, it's a bit early for april fools. Most stuff logged to syslog comes in text format anyway. I am not sure what the whole idea of systemd was or is or was meant to be, but it was certainly about not speed for corporate settings.
It would be faster writing if you write in the exact same format as the log entries exist internally before being written. There is a timestamp, binary, a facility/priority field, a number, pid, a number, and the rest is text (the log entries plus names) at variable size. All that is adapted for storage in a database, and the text compressed. Can't be faster. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2016-03-02 18:37, Per Jessen wrote:
Anton Aylward wrote:
In a corporate setting logging of activity is important. But writing to a file is slow. Some of the higher end activity analysers used by, for example, banks, to detect suspicious (read: 'nefarious') activity end up writing to a database. perhaps that's faster.
Almost certainly not. It's the same data that needs to end up on disk, adding a database to the mix will slow it down, but make analysis and structured access easier.
That's it. It is machine reading without needing to parse the results what is faster, because it is already "parsed", so to speak.
In fact, reading (dumping) the systemd journal is terribly slow because (educated guess) heavy on disk fragmentation. Unless the HD is an SSD.
Yes, I remember reading something about at some point. I don't use the journal myself, I always run syslog-ng. -- Per Jessen, Zürich (1.4°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-03 08:29, Per Jessen wrote:
Carlos E. R. wrote:
In fact, reading (dumping) the systemd journal is terribly slow because (educated guess) heavy on disk fragmentation. Unless the HD is an SSD.
Yes, I remember reading something about at some point. I don't use the journal myself, I always run syslog-ng.
Me too. Well, rsyslog. But I'd prefer not to have journal running. Or at least impede some entries from going into it, like email or nntp. Telcontar:~ # time journalctl --no-pager | grep "fetchnews\|postfix\|fetchmail" | wc -l 202170 real 0m7.878s user 0m6.173s sys 0m1.351s Telcontar:~ # That in six days. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2016-03-03 08:29, Per Jessen wrote:
Carlos E. R. wrote:
In fact, reading (dumping) the systemd journal is terribly slow because (educated guess) heavy on disk fragmentation. Unless the HD is an SSD.
Yes, I remember reading something about at some point. I don't use the journal myself, I always run syslog-ng.
Me too. Well, rsyslog.
But I'd prefer not to have journal running. Or at least impede some entries from going into it, like email or nntp.
Doesn't "rm -Rf /var/log/journal" mostly take of it? -- Per Jessen, Zürich (3.5°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-03 11:14, Per Jessen wrote:
Carlos E. R. wrote:
But I'd prefer not to have journal running. Or at least impede some entries from going into it, like email or nntp.
Doesn't "rm -Rf /var/log/journal" mostly take of it?
Well, I suppose so, but it seems a crude way of doing it. It would be more reasonable to remove entries based on criteria. Even better, impede them being logged. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2016-03-03 11:14, Per Jessen wrote:
Carlos E. R. wrote:
But I'd prefer not to have journal running. Or at least impede some entries from going into it, like email or nntp.
Doesn't "rm -Rf /var/log/journal" mostly take of it?
Well, I suppose so, but it seems a crude way of doing it.
ISTR it being the recommended approach.
It would be more reasonable to remove entries based on criteria. Even better, impede them being logged.
Then look at your postfix and nntp configs, that's where the logging should really be restricted. -- Per Jessen, Zürich (3.9°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-03 11:41, Per Jessen wrote:
Carlos E. R. wrote:
Doesn't "rm -Rf /var/log/journal" mostly take of it?
Well, I suppose so, but it seems a crude way of doing it.
ISTR it being the recommended approach.
How crude...
It would be more reasonable to remove entries based on criteria. Even better, impede them being logged.
Then look at your postfix and nntp configs, that's where the logging should really be restricted.
No, no. I want the log in syslog, where I know where to filter appropriately and rotate when needed. What I do not want them is in systemd journal wasting space and resources. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2016-03-03 11:41, Per Jessen wrote:
Carlos E. R. wrote:
Doesn't "rm -Rf /var/log/journal" mostly take of it?
Well, I suppose so, but it seems a crude way of doing it.
ISTR it being the recommended approach.
How crude...
It would be more reasonable to remove entries based on criteria. Even better, impede them being logged.
Then look at your postfix and nntp configs, that's where the logging should really be restricted.
No, no. I want the log in syslog, where I know where to filter appropriately and rotate when needed. What I do not want them is in systemd journal wasting space and resources.
Ah okay - well, the systemd journal is the gateway to the syslog daemon. I think we're back to removing /var/log/journal - there may be something in /etc/systemd/journal.conf too, but I remove /var/log/journal. Just another item on the checklist. -- Per Jessen, Zürich (3.8°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-03 11:55, Per Jessen wrote:
Carlos E. R. wrote:
No, no. I want the log in syslog, where I know where to filter appropriately and rotate when needed. What I do not want them is in systemd journal wasting space and resources.
Ah okay - well, the systemd journal is the gateway to the syslog daemon. I think we're back to removing /var/log/journal - there may be something in /etc/systemd/journal.conf too, but I remove /var/log/journal. Just another item on the checklist.
Wait. I don't have "/var/log/journal/", that's the permanent journal. There is another journal for the current session only, which in theory goes to memory, but mine is big: Telcontar:~ # journalctl --disk-usage Journals take up 304.9M on disk. Telcontar:~ # uptime 12:01pm up 6 days 3:06, 42 users, load average: 0.27, 0.45, 0.38 Telcontar:~ Despite having in /etc/systemd/journald.conf: SystemMaxUse=100M RuntimeMaxFileSize=200M I'm unsure where this one is stored. On each boot, it is purged. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2016-03-03 11:55, Per Jessen wrote:
Carlos E. R. wrote:
No, no. I want the log in syslog, where I know where to filter appropriately and rotate when needed. What I do not want them is in systemd journal wasting space and resources.
Ah okay - well, the systemd journal is the gateway to the syslog daemon. I think we're back to removing /var/log/journal - there may be something in /etc/systemd/journal.conf too, but I remove /var/log/journal. Just another item on the checklist.
Wait. I don't have "/var/log/journal/", that's the permanent journal. There is another journal for the current session only, which in theory goes to memory, but mine is big:
Telcontar:~ # journalctl --disk-usage Journals take up 304.9M on disk. Telcontar:~ # uptime 12:01pm up 6 days 3:06, 42 users, load average: 0.27, 0.45, 0.38 Telcontar:~
Despite having in /etc/systemd/journald.conf:
SystemMaxUse=100M RuntimeMaxFileSize=200M
I'm unsure where this one is stored. On each boot, it is purged.
https://www.freedesktop.org/software/systemd/man/systemd-journald.service.ht... <!-- By default, the journal stores log data in /run/log/journal/. Since /run/ is volatile, log data is lost at reboot. To make the data persistent, it is sufficient to create /var/log/journal/ where systemd-journald will then store the data. --> I wonder if we do actually create /var/log/journal in the default setup. I mean, a desktop machine doesn't need a persistent log. -- Per Jessen, Zürich (3.0°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 03/03/2016 14:13, Per Jessen a écrit :
I wonder if we do actually create /var/log/journal in the default setup. I mean, a desktop machine doesn't need a persistent log.
? needed to debug boot problems jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd wrote:
Le 03/03/2016 14:13, Per Jessen a écrit :
I wonder if we do actually create /var/log/journal in the default setup. I mean, a desktop machine doesn't need a persistent log.
?
needed to debug boot problems
I was just quoting Andreas Jaeger. We stopped installing a syslog daemon because our main audience doesn't need one. -- Per Jessen, Zürich (3.4°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 03/03/2016 15:41, Per Jessen a écrit :
jdd wrote:
needed to debug boot problems
I was just quoting Andreas Jaeger. We stopped installing a syslog daemon because our main audience doesn't need one.
I read the thread, but fail to understand. journalctl still makes a better job than the previous /var/log/message IMHO journalctl -b 0 is very fast: time journalctl -b 0 > null real 0m0.097s user 0m0.072s sys 0m0.024s and as I need to read it and usually read it, some second delay do not change anything jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd wrote:
Le 03/03/2016 15:41, Per Jessen a écrit :
jdd wrote:
needed to debug boot problems
I was just quoting Andreas Jaeger. We stopped installing a syslog daemon because our main audience doesn't need one.
I read the thread, but fail to understand. journalctl still makes a better job than the previous /var/log/message IMHO
It all depends on what you do with /var/log/(messages|mail|firewall). The systemd journal certainly does not replace syslog-ng, for instance. (except maybe on a single-user desktop machine at home). Most of my logs are rotated daily, archived and analyzed (for anomalies, statistics and other feedback). I have a couple of cases where daemons are fed loglines directly from syslog-ng (see the program() option). Maybe that's all possible with journalctl, but syslog-ng does an excellent job.
journalctl -b 0
is very fast:
time journalctl -b 0 > null
real 0m0.097s user 0m0.072s sys 0m0.024s
and as I need to read it and usually read it, some second delay do not change anything
So no particular advantage over "less /var/log/messages" :-) -- Per Jessen, Zürich (3.5°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-03 16:16, Per Jessen wrote:
It all depends on what you do with /var/log/(messages|mail|firewall). The systemd journal certainly does not replace syslog-ng, for instance. (except maybe on a single-user desktop machine at home).
Most of my logs are rotated daily, archived and analyzed (for anomalies, statistics and other feedback). I have a couple of cases where daemons are fed loglines directly from syslog-ng (see the program() option). Maybe that's all possible with journalctl, but syslog-ng does an excellent job.
Indeed it does. For instance, those verbose logs that are not needed after a week I rotate and discard fast. Others I keep for years. I can play with that. On the systemd journal either I delete it all or nothing. I can not remove the nntp entries, for instance, which are huge. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 03/03/2016 10:43 AM, Carlos E. R. wrote:
On the systemd journal either I delete it all or nothing. I can not remove the nntp entries, for instance, which are huge.
Once again this is a configuration issue. I no longer run a nntp service, but when I did I had it set up under a distinct UID. Journald does have the ability to separate out logs for a specific UID. Or, as I've shown previously, for a specific COMMand. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-03 19:44, Anton Aylward wrote:
On 03/03/2016 10:43 AM, Carlos E. R. wrote:
On the systemd journal either I delete it all or nothing. I can not remove the nntp entries, for instance, which are huge.
Once again this is a configuration issue. I no longer run a nntp service, but when I did I had it set up under a distinct UID. Journald does have the ability to separate out logs for a specific UID.
Or, as I've shown previously, for a specific COMMand.
And then, delete them? What I want is delete some specific entries, by facility and level, and keep others for years and years. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Le 03/03/2016 19:58, Carlos E. R. a écrit :
What I want is delete some specific entries, by facility and level, and keep others for years and years.
or simply fork these entries to an other account and let the system roll the logs as usual the usual logrotate did not remove anything and accumulated years of tgz "what I want" is obviously wrong. It's clear from what you said that what you want is keep track of some part of the logs. The way you can do it with journalctl may not be the same than previously, that don't mean it can't be done. and if it can't, open a bug report how many time did you need to get this result from the beginning? I remember logrotate tgz filling my / partition a very long time ago, with other kind of software. not surprising there is a need to learn new things, but this is the fun :-) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd wrote:
Le 03/03/2016 19:58, Carlos E. R. a écrit :
What I want is delete some specific entries, by facility and level, and keep others for years and years.
or simply fork these entries to an other account and let the system roll the logs as usual
the usual logrotate did not remove anything and accumulated years of tgz
"what I want" is obviously wrong.
It's clear from what you said that what you want is keep track of some part of the logs. The way you can do it with journalctl may not be the same than previously, that don't mean it can't be done. and if it can't, open a bug report
s/bug report/feature request/ And then don't hold your breath. jdd, of course journald/journalctl does not do all of what syslog-ng/rsyslog does. It's backward and cumbersome to begin with, (which can be overcome with appropriate command aliasing), but it is not a syslog daemon, period. -- Per Jessen, Zürich (2.4°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-03 20:07, jdd wrote:
Le 03/03/2016 19:58, Carlos E. R. a écrit :
What I want is delete some specific entries, by facility and level, and keep others for years and years.
or simply fork these entries to an other account and let the system roll the logs as usual
the usual logrotate did not remove anything and accumulated years of tgz
No, not true. Logrotate compresses the current log, and limits the compressed logs either by date or by number of files, removing the rest.
"what I want" is obviously wrong.
It's clear from what you said that what you want is keep track of some part of the logs. The way you can do it with journalctl may not be the same than previously, that don't mean it can't be done. and if it can't, open a bug report
It simply can't be done reliably. If you need to keep an archive of logs, it has to be plain text, perhaps compressed, so that they can be kept anywhere and retrieved anywhere, without special tools. Say, keep logs in CDs, for instance. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2016-03-03 20:07, jdd wrote:
Le 03/03/2016 19:58, Carlos E. R. a écrit :
What I want is delete some specific entries, by facility and level, and keep others for years and years.
or simply fork these entries to an other account and let the system roll the logs as usual
the usual logrotate did not remove anything and accumulated years of tgz
No, not true. Logrotate compresses the current log, and limits the compressed logs either by date or by number of files, removing the rest.
Uh, for e.g. /var/log/messages, the default config in logrotate does indeed not remove very much: compress dateext maxage 365 rotate 99 missingok notifempty size +4096k Probably a fairly sound default setting. -- Per Jessen, Zürich (2.5°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-04 08:54, Per Jessen wrote:
Carlos E. R. wrote:
No, not true. Logrotate compresses the current log, and limits the compressed logs either by date or by number of files, removing the rest.
Uh, for e.g. /var/log/messages, the default config in logrotate does indeed not remove very much:
compress dateext maxage 365 rotate 99 missingok notifempty size +4096k
Probably a fairly sound default setting.
They are removed after a year, if I read it correctly. rotate 99 means a maximum of 99 rotated files. For instance, I have this: /var/log/news/news.debug { compress dateext maxage 30 rotate 10 ... which rotates quickly the news.debug file. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2016-03-04 08:54, Per Jessen wrote:
Carlos E. R. wrote:
No, not true. Logrotate compresses the current log, and limits the compressed logs either by date or by number of files, removing the rest.
Uh, for e.g. /var/log/messages, the default config in logrotate does indeed not remove very much:
compress dateext maxage 365 rotate 99 missingok notifempty size +4096k
Probably a fairly sound default setting.
They are removed after a year, if I read it correctly.
rotate 99
means a maximum of 99 rotated files.
I'm not sure, according to the man page "rotate count: Log files are rotated <count> times before being removed". I think it means nothing is deleted until you have 99 rotated files.
For instance, I have this:
/var/log/news/news.debug { compress dateext maxage 30 rotate 10 ...
which rotates quickly the news.debug file.
Well, what's the limit - size or time? (daily/weekly or size +xxx) ? -- Per Jessen, Zürich (5.1°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/03/2016 15:36, Per Jessen wrote:
Carlos E. R. wrote:
rotate 99
means a maximum of 99 rotated files.
I'm not sure, according to the man page "rotate count: Log files are rotated <count> times before being removed". I think it means nothing is deleted until you have 99 rotated files.
Well, yes, it is the same, ¿no?
For instance, I have this:
/var/log/news/news.debug { compress dateext maxage 30 rotate 10 ...
which rotates quickly the news.debug file.
Well, what's the limit - size or time? (daily/weekly or size +xxx) ?
30 days and 10 files. Size applies to the active file. -- Saludos/Cheers, Carlos E.R. (Minas-Morgul - W10) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
On 04/03/2016 15:36, Per Jessen wrote:
Carlos E. R. wrote:
rotate 99
means a maximum of 99 rotated files.
I'm not sure, according to the man page "rotate count: Log files are rotated <count> times before being removed". I think it means nothing is deleted until you have 99 rotated files.
Well, yes, it is the same, ¿no?
I dunno. If one new rotated file of 4Mb is created once a week, you only get 52 in year1. In year2 you get another 52, so 104 - I don't know if 99 are kept or only those younger than 365 days.
For instance, I have this:
/var/log/news/news.debug { compress dateext maxage 30 rotate 10 ...
which rotates quickly the news.debug file.
Well, what's the limit - size or time? (daily/weekly or size +xxx) ?
30 days and 10 files. Size applies to the active file.
Size is the criteria for rotation - unless your news.debug file satisfies your criteria, nothing is rotated. If you have "size +100G" for instance. On production machines, I always use: daily rotate 30 To me rotate and maxage do the same thing, limit the number of rotated logs, just with different criteria. I can't quite work out how they work together. How do you believe your "maxage 30 and rotate 10" is supposed to work? -- Per Jessen, Zürich (4.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-04 18:35, Per Jessen wrote:
Carlos E. R. wrote:
On 04/03/2016 15:36, Per Jessen wrote:
Carlos E. R. wrote:
rotate 99
means a maximum of 99 rotated files.
I'm not sure, according to the man page "rotate count: Log files are rotated <count> times before being removed". I think it means nothing is deleted until you have 99 rotated files.
Well, yes, it is the same, ¿no?
I dunno. If one new rotated file of 4Mb is created once a week, you only get 52 in year1. In year2 you get another 52, so 104 - I don't know if 99 are kept or only those younger than 365 days.
Ah. Only those younger than a year.
30 days and 10 files. Size applies to the active file.
Size is the criteria for rotation - unless your news.debug file satisfies your criteria, nothing is rotated. If you have "size +100G" for instance.
On production machines, I always use:
daily rotate 30
To me rotate and maxage do the same thing, limit the number of rotated logs, just with different criteria. I can't quite work out how they work together. How do you believe your "maxage 30 and rotate 10" is supposed to work?
It will keep a maximum of 10 files, and they will not cover more than 30 days - whichever condition hits first. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
It simply can't be done reliably. If you need to keep an archive of logs, it has to be plain text, perhaps compressed, so that they can be kept anywhere and retrieved anywhere, without special tools. Say, keep logs in CDs, for instance.
Le 03/03/2016 22:29, Carlos E. R. a écrit : true, but are you sure it can't be done? jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-07 19:54, jdd wrote:
Le 03/03/2016 22:29, Carlos E. R. a écrit :
It simply can't be done reliably. If you need to keep an archive of logs, it has to be plain text, perhaps compressed, so that they can be kept anywhere and retrieved anywhere, without special tools. Say, keep logs in CDs, for instance. true, but are you sure it can't be done?
Quite! You can not archive for long term a binary database on a different media. You need to also archive with it the software needed to read it. Otherwise, journalctl has to be able to read a database in another path, and the devs must promise to always generate code backwards compatible, so that next versions of journalctl can read obsolete formats of the log database. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2016-03-07 19:54, jdd wrote:
Le 03/03/2016 22:29, Carlos E. R. a écrit :
It simply can't be done reliably. If you need to keep an archive of logs, it has to be plain text, perhaps compressed, so that they can be kept anywhere and retrieved anywhere, without special tools. Say, keep logs in CDs, for instance. true, but are you sure it can't be done?
Quite!
You can not archive for long term a binary database on a different media. You need to also archive with it the software needed to read it.
Tape is your answer. The only media guaranteed and tested for 20-30 years storage. -- Per Jessen, Zürich (1.3°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-08 10:04, Per Jessen wrote:
Carlos E. R. wrote:
You can not archive for long term a binary database on a different media. You need to also archive with it the software needed to read it.
Tape is your answer. The only media guaranteed and tested for 20-30 years storage.
Paper is for millennia :-p Realistically though, shuffling to another hard disk is enough for me. I think I read about a memory crystal somewhere. Perhaps an article in the OT list. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2016-03-08 10:04, Per Jessen wrote:
Carlos E. R. wrote:
You can not archive for long term a binary database on a different media. You need to also archive with it the software needed to read it.
Tape is your answer. The only media guaranteed and tested for 20-30 years storage.
Paper is for millennia :-p
Heh, check your grandfathers old papers - brown, bleached, ink disappeared or soaked into the next page. Maybe laser-printed will last for long enough, dunno.
Realistically though, shuffling to another hard disk is enough for me.
I think I read about a memory crystal somewhere. Perhaps an article in the OT list.
Yes, there is stuff like that coming out, there is also "long-life" CDs and DVDs, although the latter have not been sufficiently tested either. -- Per Jessen, Zürich (1.3°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-08 10:25, Per Jessen wrote:
Carlos E. R. wrote:
Paper is for millennia :-p
Heh, check your grandfathers old papers - brown, bleached, ink disappeared or soaked into the next page. Maybe laser-printed will last for long enough, dunno.
Well, I have books printed around 1850 in very good state. Hand written papers is different: those I have were written in some ink that with age turns light brown, and so does the paper. Poor contrast, and difficult hand written er... shapes? letter calligraphy?
Realistically though, shuffling to another hard disk is enough for me.
I think I read about a memory crystal somewhere. Perhaps an article in the OT list.
Yes, there is stuff like that coming out, there is also "long-life" CDs and DVDs, although the latter have not been sufficiently tested either.
Will be good news, be able to preserve digital content for more than a few years. Write and forget. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Le 08/03/2016 10:04, Per Jessen a écrit :
Tape is your answer. The only media guaranteed and tested for 20-30 years storage. I you can keep the hardware. my HP tape recorder eated my tapes :-(
jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd wrote:
Le 08/03/2016 10:04, Per Jessen a écrit :
Tape is your answer. The only media guaranteed and tested for 20-30 years storage.
If you can keep the hardware. my HP tape recorder eated my tapes :-(
For archiving, it's wise to keep at least two copies in geographically separate locations. Apart from that, HP LTO drives have never caused me any problems. -- Per Jessen, Zürich (0.1°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 2016-03-08 at 19:40 +0100, jdd wrote:
Le 08/03/2016 10:04, Per Jessen a écrit :
Tape is your answer. The only media guaranteed and tested for 20-30 years storage. I you can keep the hardware. my HP tape recorder eated my tapes :-(
Media might be guaranteed for 20-30 years. But not the content. If anything goes wrong, you get your money back for the tapes. But not your data. Have quite a reasonable amount of DDS2-tapes, and some time ago decided to use those again (some were used, other brand new) Writing to them isn't such a problem, only thing you need is patience. Ofcource, I wrote them back to an empty dir, and checked the hashes: all fine. Alas, one year later most of them could not be read back anymore. Not even on the tape-unit I used for writing.. Ergo, never put your trust on a single instance. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 09/03/2016 22:58, Hans Witvliet a écrit :
Ergo, never put your trust on a single instance.
sure. nearly every 5 years, the storage get a leap. Then you have to upgrade your storage. As it involve better medium, it's often friendly. I very recently buy 5Gb usb hard drives for my 4Gb archives, spread on 5 to 6 lesser capacity drives. I now have three usb boxes, on various physical places, and I update them on round robin way. I still have the old disks, I only use then when necessary, never delete the content. Sometime I have to go to an old dvd (sometime faster to remember where it is than to scan a 5Gb data collection :-) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/03/2016 08:41 AM, jdd wrote:
Le 03/03/2016 14:13, Per Jessen a écrit :
I wonder if we do actually create /var/log/journal in the default setup. I mean, a desktop machine doesn't need a persistent log.
?
needed to debug boot problems
Indeed. And once things are running stably ... ? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 03/03/2016 16:34, Anton Aylward a écrit :
On 03/03/2016 08:41 AM, jdd wrote:
Le 03/03/2016 14:13, Per Jessen a écrit :
I wonder if we do actually create /var/log/journal in the default setup. I mean, a desktop machine doesn't need a persistent log.
?
needed to debug boot problems
Indeed. And once things are running stably ... ?
there is always something running wrong and you lose the keyboard... Of course, My work may not be the one of everybody, spending much time trying to test new things (new for me), but one never know when something will go wrong. the best use of journalctl I have (comparing to the old) is the ability to separate last boots. but this is for me... I manage a handful of servers and nearly never have use of logs, but once in a while I'm very glad to have them. I think the problem is elsewhere. Linux/unix is a very ancient system, now, and old systems are very stable and everybody knows how to use them. Building houses with logs (wood ones :-), is the same, but what for skyscrapers? on modern computers, million times more complex and powerful than what we had, it's normal to have new tools. I'm not expert enough to understand the background of things like system logs, so I trust experts. Of course one needs to use own knowledge, so not change too fast, but at sme moment it's time to learn new things at a reasonable pace jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd wrote:
I manage a handful of servers and nearly never have use of logs, but once in a while I'm very glad to have them.
Which is exactly why we have them - for that once in a while. There are other uses and purposes, but that is no doubt the main one for most people. Diskspace has been increasingly plentyful since the mid-90s, so keeping 30days worth of logfiles is not a luxury.
I think the problem is elsewhere. Linux/unix is a very ancient system, now, and old systems are very stable and everybody knows how to use them. Building houses with logs (wood ones :-), is the same, but what for skyscrapers?
on modern computers, million times more complex and powerful than what we had, it's normal to have new tools.
The best tools usually survive the rest - no one has yet discovered a better bicycle or screwdriver or pair of scissors or pliers, spoon, fork, knife, needle, zipper, rope, knot, man pages, vi, syslog - etc etc. Actually, somebody did create a "better" man page, but man pages seem to as popular as ever. -- Per Jessen, Zürich (3.4°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday 03 March 2016, Per Jessen wrote:
I wonder if we do actually create /var/log/journal in the default setup. I mean, a desktop machine doesn't need a persistent log.
Hehe, first they replaced syslog (which was always running since 20 years without bothering anybody) by journald. That's why nowadays even people, who never heard about logging and never watched it, painfully learned to know how bad logging could be. :) Thus we simply disable logging per default now? No, we should remove/shrink journald as good as possible and run syslog per default again! cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Ruediger Meier wrote:
On Thursday 03 March 2016, Per Jessen wrote:
I wonder if we do actually create /var/log/journal in the default setup. I mean, a desktop machine doesn't need a persistent log.
Hehe, first they replaced syslog (which was always running since 20 years without bothering anybody) by journald. That's why nowadays even people, who never heard about logging and never watched it, painfully learned to know how bad logging could be. :)
Thus we simply disable logging per default now? No, we should remove/shrink journald as good as possible and run syslog per default again!
Exactly! -- Per Jessen, Zürich (3.6°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/03/2016 08:13 AM, Per Jessen wrote:
Carlos E. R. wrote:
On 2016-03-03 11:55, Per Jessen wrote:
Carlos E. R. wrote:
No, no. I want the log in syslog, where I know where to filter appropriately and rotate when needed. What I do not want them is in systemd journal wasting space and resources.
Ah okay - well, the systemd journal is the gateway to the syslog daemon. I think we're back to removing /var/log/journal - there may be something in /etc/systemd/journal.conf too, but I remove /var/log/journal. Just another item on the checklist.
Wait. I don't have "/var/log/journal/", that's the permanent journal. There is another journal for the current session only, which in theory goes to memory, but mine is big:
Telcontar:~ # journalctl --disk-usage Journals take up 304.9M on disk. Telcontar:~ # uptime 12:01pm up 6 days 3:06, 42 users, load average: 0.27, 0.45, 0.38 Telcontar:~
Despite having in /etc/systemd/journald.conf:
SystemMaxUse=100M RuntimeMaxFileSize=200M
I'm unsure where this one is stored. On each boot, it is purged.
https://www.freedesktop.org/software/systemd/man/systemd-journald.service.ht...
<!-- By default, the journal stores log data in /run/log/journal/. Since /run/ is volatile, log data is lost at reboot. To make the data persistent, it is sufficient to create /var/log/journal/ where systemd-journald will then store the data. -->
I wonder if we do actually create /var/log/journal in the default setup.
If you want persistent storage, yes, and configure journald.conf appropriately.
I mean, a desktop machine doesn't need a persistent log.
Well, there is that. Recall I kept asking Billy Zheng why he needed those logs. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
I'm unsure where this one is stored. On each boot, it is purged.
https://www.freedesktop.org/software/systemd/man/systemd-journald.service.ht...
<!-- By default, the journal stores log data in /run/log/journal/. Since /run/ is volatile, log data is lost at reboot. To make the data persistent, it is sufficient to create /var/log/journal/ where systemd-journald will then store the data. -->
I wonder if we do actually create /var/log/journal in the default setup.
If you want persistent storage, yes, and configure journald.conf appropriately.
I meant "we" == "us, the openSUSE project". -- Per Jessen, Zürich (3.4°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-03 14:13, Per Jessen wrote:
Carlos E. R. wrote:
I'm unsure where this one is stored. On each boot, it is purged.
https://www.freedesktop.org/software/systemd/man/systemd-journald.service.ht...
Yes, I found the location a post later.
I wonder if we do actually create /var/log/journal in the default setup. I mean, a desktop machine doesn't need a persistent log.
Dunno, I have forgotten. But actually, I think that a desktop does need a persistent log, not verbose, if not for use by the user, for the person that does the maintenance. Or for when the user asks for help here, that we can ask for logs, find out what happened, and help him. Hey, Windows does have a log system. Very difficult to use and find things, with only a GUI. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 03/03/2016 10:40 AM, Carlos E. R. wrote:
But actually, I think that a desktop does need a persistent log, not verbose, if not for use by the user, for the person that does the maintenance. Or for when the user asks for help here, that we can ask for logs, find out what happened, and help him.
I rather suspect that we can justify two - or more? - classes -- ?types/ -- of logs based on that. I also note that its possible to configure journald to log based on individual users as well as the system. While that is of limited use in a single user desktop, I can see it being very useful in a true multi-user/server context. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-03 19:07, Anton Aylward wrote:
I also note that its possible to configure journald to log based on individual users as well as the system. While that is of limited use in a single user desktop, I can see it being very useful in a true multi-user/server context.
Is anything using that method yet? -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. writes:
On 2016-03-03 11:55, Per Jessen wrote:
Carlos E. R. wrote:
No, no. I want the log in syslog, where I know where to filter appropriately and rotate when needed. What I do not want them is in systemd journal wasting space and resources.
Ah okay - well, the systemd journal is the gateway to the syslog daemon. I think we're back to removing /var/log/journal - there may be something in /etc/systemd/journal.conf too, but I remove /var/log/journal. Just another item on the checklist.
Wait. I don't have "/var/log/journal/", that's the permanent journal. There is another journal for the current session only, which in theory goes to memory, but mine is big:
Telcontar:~ # journalctl --disk-usage Journals take up 304.9M on disk. Telcontar:~ # uptime 12:01pm up 6 days 3:06, 42 users, load average: 0.27, 0.45, 0.38 Telcontar:~
my usage: ╰─ $ time journalctl --no-pager | grep "fetchnews\|postfix\|fetchmail" | wc -l 89862 real 1m18.993s user 0m42.040s sys 0m39.092s ╰─ $ journalctl --disk-usage Journals take up 1016.0M on disk. ╰─ $ uptime 14:36pm up 1 day 13:08, 13 users, load average: 1.10, 1.19, 1.14 -- Geek, Rubyist, Emacser 程序员中的牛逼运维， 运维中的牛逼程序员。 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-04-09 08:45, Billy.Zheng (zw963) wrote:
my usage:
╰─ $ time journalctl --no-pager | grep "fetchnews\|postfix\|fetchmail" | wc -l 89862
real 1m18.993s user 0m42.040s sys 0m39.092s
╰─ $ journalctl --disk-usage Journals take up 1016.0M on disk.
╰─ $ uptime 14:36pm up 1 day 13:08, 13 users, load average: 1.10, 1.19, 1.14
One gigabyte log, one day usage. That's a lot. Please verify the size of "/var/log/journal/" and "/run/log/journal/". The first one is hard disk, the second one is a virtual disk in RAM: if that's the one that has 1GB, you have a problem. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Billy.Zheng(zw963) schreef op 09-04-16 08:45:
my usage:
╰─ $ time journalctl --no-pager | grep "fetchnews\|postfix\|fetchmail" | wc -l 89862
real 1m18.993s user 0m42.040s sys 0m39.092s
╰─ $ journalctl --disk-usage Journals take up 1016.0M on disk.
Taking a minute or longer to grep your file is not really workable is it. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2016-04-09 at 16:26 +0200, Xen wrote:
my usage:
╰─ $ time journalctl --no-pager | grep "fetchnews\|postfix\|fetchmail" | wc -l 89862
real 1m18.993s user 0m42.040s sys 0m39.092s
╰─ $ journalctl --disk-usage Journals take up 1016.0M on disk.
Taking a minute or longer to grep your file is not really workable is it.
Well, that's a characteristic of systemd journal :-p - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlcJOgIACgkQtTMYHG2NR9WMmACffbVTBYRmwyK0AFWmICf0U9wL 2tkAoJN7FyuKSThfHhtWB4EP5DScDxfn =hLI6 -----END PGP SIGNATURE-----
On Thursday 03 March 2016, Per Jessen wrote:
Carlos E. R. wrote:
On 2016-03-03 11:41, Per Jessen wrote:
Carlos E. R. wrote:
Doesn't "rm -Rf /var/log/journal" mostly take of it?
Well, I suppose so, but it seems a crude way of doing it.
ISTR it being the recommended approach.
How crude...
It would be more reasonable to remove entries based on criteria. Even better, impede them being logged.
Then look at your postfix and nntp configs, that's where the logging should really be restricted.
No, no. I want the log in syslog, where I know where to filter appropriately and rotate when needed. What I do not want them is in systemd journal wasting space and resources.
Ah okay - well, the systemd journal is the gateway to the syslog daemon. I think we're back to removing /var/log/journal - there may be something in /etc/systemd/journal.conf too, but I remove /var/log/journal. Just another item on the checklist.
Maybe it's possible to setup or re-compile postfix and friends without systemd support and log directly to a real syslogd. See also logger's options: --socket, --server, --udp I'm sure that using one of them would bypass stupid journald. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Ruediger Meier wrote:
On Thursday 03 March 2016, Per Jessen wrote:
Carlos E. R. wrote:
On 2016-03-03 11:41, Per Jessen wrote:
Carlos E. R. wrote:
Doesn't "rm -Rf /var/log/journal" mostly take of it?
Well, I suppose so, but it seems a crude way of doing it.
ISTR it being the recommended approach.
How crude...
It would be more reasonable to remove entries based on criteria. Even better, impede them being logged.
Then look at your postfix and nntp configs, that's where the logging should really be restricted.
No, no. I want the log in syslog, where I know where to filter appropriately and rotate when needed. What I do not want them is in systemd journal wasting space and resources.
Ah okay - well, the systemd journal is the gateway to the syslog daemon. I think we're back to removing /var/log/journal - there may be something in /etc/systemd/journal.conf too, but I remove /var/log/journal. Just another item on the checklist.
Maybe it's possible to setup or re-compile postfix and friends without systemd support and log directly to a real syslogd.
Perhaps, but hardly worth it - and I think it's better to keep the syslog() interface. -- Per Jessen, Zürich (3.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/03/2016 06:23 AM, Ruediger Meier wrote:
Maybe it's possible to setup or re-compile postfix and friends without systemd support and log directly to a real syslogd.
As far as I can tell postfix, dovecot, fetchmail and the like know nothing about systemd, they just use the syslog protocols or their own files. You can verify this for yourself looking at what ports they have open and what libraries they use. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I had to resend without systemd in the subject line, it is not allowed on the mail list :-/ On 2016-03-03 11:55, Per Jessen wrote:
Carlos E. R. wrote:
No, no. I want the log in syslog, where I know where to filter appropriately and rotate when needed. What I do not want them is in systemd journal wasting space and resources.
Ah okay - well, the systemd journal is the gateway to the syslog daemon. I think we're back to removing /var/log/journal - there may be something in /etc/systemd/journal.conf too, but I remove /var/log/journal. Just another item on the checklist.
Wait. I don't have "/var/log/journal/", that's the permanent journal. There is another journal for the current session only, which in theory goes to memory, but mine is big: Telcontar:~ # journalctl --disk-usage Journals take up 304.9M on disk. Telcontar:~ # uptime 12:01pm up 6 days 3:06, 42 users, load average: 0.27, 0.45, 0.38 Telcontar:~ Despite having in /etc/systemd/journald.conf: SystemMaxUse=100M RuntimeMaxFileSize=200M I'm unsure where this one is stored. On each boot, it is purged. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 03/03/2016 05:55 AM, Per Jessen wrote:
Ah okay - well, the systemd journal is the gateway to the syslog daemon. I think we're back to removing /var/log/journal - there may be something in /etc/systemd/journal.conf too, but I remove /var/log/journal. Just another item on the checklist
Alternatively remove /var/log/message and rsyslog (or syslog-ng). Once again, let me refer to http://0pointer.de/blog/projects/journalctl.html on how to configure and use journald/journalctl properly. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
On 03/03/2016 05:55 AM, Per Jessen wrote:
Ah okay - well, the systemd journal is the gateway to the syslog daemon. I think we're back to removing /var/log/journal - there may be something in /etc/systemd/journal.conf too, but I remove /var/log/journal. Just another item on the checklist
Alternatively remove /var/log/message and rsyslog (or syslog-ng).
Once again, let me refer to
http://0pointer.de/blog/projects/journalctl.html
on how to configure and use journald/journalctl properly.
Anton, it's bit of a pointless discussion (as syslog-ng does an excellent job). Removing /var/log/messages and syslog-ng is not a solution to anything. As for "how to configure and use journald/journalctl properly", I have better things to do. I have a working setup with a syslog daemon, trying to bend it to work with journald/journalctl would only be a waste of time. Also, using syslog-ng means I can have the same setup across machines of different generations (pre and post systemd). -- Per Jessen, Zürich (3.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-03 16:30, Anton Aylward wrote:
Once again, let me refer to
http://0pointer.de/blog/projects/journalctl.html
on how to configure and use journald/journalctl properly.
The configuration is ignored here. I had to restart the daemon several times till the log was finally cycled and deleted. I can't limit its size. Probably I'll have to do a cronjob to remove the files in /run/log/journal -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 03/03/2016 05:50 AM, Carlos E. R. wrote:
No, no. I want the log in syslog, where I know where to filter appropriately and rotate when needed. What I do not want them is in systemd journal wasting space and resources.
Another POV is that the text files are wasting space compared to the compression mode of journald. So far, all you've said is that you are familiar with the old, tradition *NIX tools for searching and filtering text files and are comfortable using them on /var/log/messages as a text file, but don't know, haven't experimented with the capabilities of joournald/journalctl and the ways it can be configured and used. I can't fault your knowledge of the old tools, and won't since they form my knowledge base as well, but I enjoy learning new stuff, despite my age, and have learnt a little more today to be able to show you a faster use of journalctl than filtering with grep. I hope to learn a little more about something tomorrow and the day after, and on until I die, probably from my head exploding. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-03 16:26, Anton Aylward wrote:
On 03/03/2016 05:50 AM, Carlos E. R. wrote:
No, no. I want the log in syslog, where I know where to filter appropriately and rotate when needed. What I do not want them is in systemd journal wasting space and resources.
Another POV is that the text files are wasting space compared to the compression mode of journald.
Actually, it is the other way round. The journal of six days takes 300MB, more than the same size as syslog for years, which is also compressed. Telcontar:~ # du -hcsS /var/log 274M /var/log 1.2G total Telcontar:~ # There are two big directories, holding bugzilla files and old logs, that fill up the rest of that 1.2G. The current logs are 274M only. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Thursday 03 March 2016, Anton Aylward wrote:
On 03/03/2016 05:50 AM, Carlos E. R. wrote:
No, no. I want the log in syslog, where I know where to filter appropriately and rotate when needed. What I do not want them is in systemd journal wasting space and resources.
Another POV is that the text files are wasting space compared to the compression mode of journald.
LOL the text is factor 10 smaller. Compressed text (as in /var/log/messages) is factor 160 smaller: $ du -sh /var/run/log/journal 80M /var/run/log/journal $ journalctl | xz -c > /tmp/log $ du -sh /tmp/log 9M $ xz /tmp/log $ du -sh /tmp/log.xz 460K /tmp/log.xz BTW I see journald's compression mode is the default. I guess would be even more fun to measure an uncompressed journal.
So far, all you've said is that you are familiar with the old, tradition *NIX tools for searching and filtering text files and are comfortable using them on /var/log/messages as a text file, but don't know, haven't experimented with the capabilities of joournald/journalctl and the ways it can be configured and used.
I can't fault your knowledge of the old tools, and won't since they form my knowledge base as well, but I enjoy learning new stuff, despite my age, and have learnt a little more today to be able to show you a faster use of journalctl than filtering with grep.
I hope to learn a little more about something tomorrow and the day after, and on until I die, probably from my head exploding.
The probability to die while waiting for journalctl to show some logs is more than 10 times higher than waiting for syslog/grep. Instead of just to accept everything and to learn what is written somewhere you could also compare old and new things by yourself. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/03/2016 05:41 AM, Per Jessen wrote:
Carlos E. R. wrote:
On 2016-03-03 11:14, Per Jessen wrote:
Carlos E. R. wrote:
But I'd prefer not to have journal running. Or at least impede some entries from going into it, like email or nntp.
Doesn't "rm -Rf /var/log/journal" mostly take of it?
Well, I suppose so, but it seems a crude way of doing it.
ISTR it being the recommended approach.
It would be more reasonable to remove entries based on criteria. Even better, impede them being logged.
Then look at your postfix and nntp configs, that's where the logging should really be restricted.
Or RTFM JOURNALD.CONF(5) Using "SplitMode" will enable logging of users' activity as distinct from system services run by root. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday 03 March 2016, Carlos E. R. wrote:
On 2016-03-03 11:14, Per Jessen wrote:
Carlos E. R. wrote:
But I'd prefer not to have journal running. Or at least impede some entries from going into it, like email or nntp.
Doesn't "rm -Rf /var/log/journal" mostly take of it?
You have still /run/log/journal in RAM. It's slow enough after some uptime... Here my timings on a system without /var/log/journal on disk: $ uptime 11:38am up 21 days 0:47, 1 user, load average: 4.15, 4.18, 4.15 See how much memory (RAM) it wastes per default: $ du -sh /var/run/log/journal 456M /var/run/log/journal ... for no reason because it's unusable; $ time journalctl | wc -l 496444 real 0m14.403s user 0m12.916s sys 0m1.316s ## funny --boot is even slower although it's the same in this case $ time journalctl --boot | wc -l 496448 real 0m18.263s user 0m16.736s sys 0m1.476s Compare with syslog log from one full year, not only 21 days! $ time xzcat /var/log/messages-*.xz | wc -l 5071664 real 0m6.002s user 0m5.600s sys 0m0.420s BTW I had benchmarked this system one month ago when I've had 150 days uptime. It took about 1-2 minutes to wait for the logs. If you have an emergency case you can't use it. Moreover the high CPU load while watching logs might make things even worse.
Well, I suppose so, but it seems a crude way of doing it.
It would be more reasonable to remove entries based on criteria. Even better, impede them being logged.
IMO it makes no sense to hope that journald will be usable one day. For me removing /var/log/journal is a must. Still on my TODO: Try out whether it works to set RuntimeMaxUse=0 to get rid of it completely, see man journald.conf. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-03 12:05, Ruediger Meier wrote:
On Thursday 03 March 2016, Carlos E. R. wrote:
On 2016-03-03 11:14, Per Jessen wrote:
Carlos E. R. wrote:
But I'd prefer not to have journal running. Or at least impede some entries from going into it, like email or nntp.
Doesn't "rm -Rf /var/log/journal" mostly take of it?
You have still /run/log/journal in RAM. It's slow enough after some uptime...
Exactly. Mine is big: Telcontar:~ # du -hsc /run/log/journal 306M /run/log/journal 306M total Telcontar:~ # Telcontar:~ # journalctl --disk-usage Journals take up 305.0M on disk. Telcontar:~ # Telcontar:~ # uptime 12:15pm up 6 days 3:21, 42 users, load average: 0.16, 0.28, 0.34 top: KiB Mem: 8193516 total, 4675860 used, 3517656 free, 234420 buffers KiB Swap: 34305004 total, 1892008 used, 32412996 free, 1319844 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1 root 20 0 50056 4800 1800 S 0.000 0.059 0:11.35 systemd 313 root 20 0 2827420 44636 44304 S 0.000 0.545 2:11.36 systemd-journal 1177 root 20 0 399496 11092 880 S 0.000 0.135 0:32.75 rsyslogd
It would be more reasonable to remove entries based on criteria. Even better, impede them being logged.
IMO it makes no sense to hope that journald will be usable one day. For me removing /var/log/journal is a must.
Yes.
Still on my TODO: Try out whether it works to set RuntimeMaxUse=0 to get rid of it completely, see man journald.conf.
I have: SystemMaxUse=100M RuntimeMaxFileSize=200M Does not work. Maybe "Storage=none". I'm trying now: Storage=none SystemMaxUse=100M RuntimeMaxFileSize=200M RuntimeMaxUse=100M MaxLevelStore=warning Telcontar:~ # systemctl restart systemd-journald.service Telcontar:~ # journalctl --disk-usage Journals take up 305.5M on disk. Telcontar:~ # Still same size... :-? Telcontar:~ # systemctl status systemd-journald.service systemd-journald.service - Journal Service Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static) Active: active (running) since Thu 2016-03-03 12:25:33 CET; 2s ago Docs: man:systemd-journald.service(8) man:journald.conf(5) Main PID: 26422 (systemd-journal) Status: "Processing requests..." CGroup: /system.slice/systemd-journald.service └─26422 /usr/lib/systemd/systemd-journald Mar 03 12:25:33 Telcontar systemd-journal[26422]: Runtime journal is using 305.5M (max 400.0M, leaving 600.1M of free 3.6G, current limit 400.0M). Mar 03 12:25:33 Telcontar systemd-journal[26422]: Runtime journal is using 305.5M (max 400.0M, leaving 600.1M of free 3.6G, current limit 400.0M). Mar 03 12:25:33 Telcontar systemd-journal[26422]: Journal started Mar 03 12:25:33 Telcontar systemd-journal[26422]: Runtime journal is using 305.5M (max 400.0M, leaving 600.1M of free 3.6G, current limit 400.0M). Telcontar:~ # Where is it taking that max size of 400? It is ignoring the config, using the default of 10% free ram instead. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
I had to resend without systemd in the subject line, it is not allowed on the mail list :-/ On 2016-03-03 12:05, Ruediger Meier wrote:
On Thursday 03 March 2016, Carlos E. R. wrote:
On 2016-03-03 11:14, Per Jessen wrote:
Carlos E. R. wrote:
But I'd prefer not to have journal running. Or at least impede some entries from going into it, like email or nntp.
Doesn't "rm -Rf /var/log/journal" mostly take of it?
You have still /run/log/journal in RAM. It's slow enough after some uptime...
Exactly. Mine is big: Telcontar:~ # du -hsc /run/log/journal 306M /run/log/journal 306M total Telcontar:~ # Telcontar:~ # journalctl --disk-usage Journals take up 305.0M on disk. Telcontar:~ # Telcontar:~ # uptime 12:15pm up 6 days 3:21, 42 users, load average: 0.16, 0.28, 0.34 top: KiB Mem: 8193516 total, 4675860 used, 3517656 free, 234420 buffers KiB Swap: 34305004 total, 1892008 used, 32412996 free, 1319844 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1 root 20 0 50056 4800 1800 S 0.000 0.059 0:11.35 systemd 313 root 20 0 2827420 44636 44304 S 0.000 0.545 2:11.36 systemd-journal 1177 root 20 0 399496 11092 880 S 0.000 0.135 0:32.75 rsyslogd
It would be more reasonable to remove entries based on criteria. Even better, impede them being logged.
IMO it makes no sense to hope that journald will be usable one day. For me removing /var/log/journal is a must.
Yes.
Still on my TODO: Try out whether it works to set RuntimeMaxUse=0 to get rid of it completely, see man journald.conf.
I have: SystemMaxUse=100M RuntimeMaxFileSize=200M Does not work. Maybe "Storage=none". I'm trying now: Storage=none SystemMaxUse=100M RuntimeMaxFileSize=200M RuntimeMaxUse=100M MaxLevelStore=warning Telcontar:~ # systemctl restart systemd-journald.service Telcontar:~ # journalctl --disk-usage Journals take up 305.5M on disk. Telcontar:~ # Still same size... :-? Telcontar:~ # systemctl status systemd-journald.service systemd-journald.service - Journal Service Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static) Active: active (running) since Thu 2016-03-03 12:25:33 CET; 2s ago Docs: man:systemd-journald.service(8) man:journald.conf(5) Main PID: 26422 (systemd-journal) Status: "Processing requests..." CGroup: /system.slice/systemd-journald.service └─26422 /usr/lib/systemd/systemd-journald Mar 03 12:25:33 Telcontar systemd-journal[26422]: Runtime journal is using 305.5M (max 400.0M, leaving 600.1M of free 3.6G, current limit 400.0M). Mar 03 12:25:33 Telcontar systemd-journal[26422]: Runtime journal is using 305.5M (max 400.0M, leaving 600.1M of free 3.6G, current limit 400.0M). Mar 03 12:25:33 Telcontar systemd-journal[26422]: Journal started Mar 03 12:25:33 Telcontar systemd-journal[26422]: Runtime journal is using 305.5M (max 400.0M, leaving 600.1M of free 3.6G, current limit 400.0M). Telcontar:~ # Where is it taking that max size of 400M? It is ignoring the config, using the default of 10% free ram instead. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Thursday 03 March 2016, Carlos E. R. wrote:
Telcontar:~ # systemctl status systemd-journald.service systemd-journald.service - Journal Service Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static) Active: active (running) since Thu 2016-03-03 12:25:33 CET; 2s ago Docs: man:systemd-journald.service(8) man:journald.conf(5) Main PID: 26422 (systemd-journal) Status: "Processing requests..." CGroup: /system.slice/systemd-journald.service └─26422 /usr/lib/systemd/systemd-journald
Mar 03 12:25:33 Telcontar systemd-journal[26422]: Runtime journal is using 305.5M (max 400.0M, leaving 600.1M of free 3.6G, current limit 400.0M). Mar 03 12:25:33 Telcontar systemd-journal[26422]: Runtime journal is using 305.5M (max 400.0M, leaving 600.1M of free 3.6G, current limit 400.0M). Mar 03 12:25:33 Telcontar systemd-journal[26422]: Journal started Mar 03 12:25:33 Telcontar systemd-journal[26422]: Runtime journal is using 305.5M (max 400.0M, leaving 600.1M of free 3.6G, current limit 400.0M). Telcontar:~ #
Where is it taking that max size of 400M?
10% or 15% of free memory or the size of /run?
It is ignoring the config, using the default of 10% free ram instead.
man journald.conf: "If the file system is nearly full and either SystemKeepFree= or RuntimeKeepFree= is violated when systemd-journald is started, the value will be raised to percentage that is actually free." Maybe it needs journalctl --vacuum-time=2d or journalctl --vacuum-size=500M cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-03 12:50, Ruediger Meier wrote:
On Thursday 03 March 2016, Carlos E. R. wrote:
Where is it taking that max size of 400M?
10% or 15% of free memory or the size of /run?
Oh, right, the size of /run. Telcontar:~ # df -h Filesystem Size Used Avail Use% Mounted on ... tmpfs 4.0G 309M 3.7G 8% /run
It is ignoring the config, using the default of 10% free ram instead.
man journald.conf:
"If the file system is nearly full and either SystemKeepFree= or RuntimeKeepFree= is violated when systemd-journald is started, the value will be raised to percentage that is actually free."
I don't understand that :-? Anyway, the filesystem is not close to full. 58% ussage of "/".
Maybe it needs journalctl --vacuum-time=2d or journalctl --vacuum-size=500M
Telcontar:~ # journalctl --vacuum-time=2d journalctl: unrecognized option '--vacuum-time=2d' Telcontar:~ # journalctl --vacuum-size=500M journalctl: unrecognized option '--vacuum-size=500M' Telcontar:~ # -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Thursday 03 March 2016, Carlos E. R. wrote:
On 2016-03-03 12:50, Ruediger Meier wrote:
On Thursday 03 March 2016, Carlos E. R. wrote:
Where is it taking that max size of 400M?
10% or 15% of free memory or the size of /run?
Oh, right, the size of /run.
Telcontar:~ # df -h Filesystem Size Used Avail Use% Mounted on ... tmpfs 4.0G 309M 3.7G 8% /run
It is ignoring the config, using the default of 10% free ram instead.
man journald.conf:
"If the file system is nearly full and either SystemKeepFree= or RuntimeKeepFree= is violated when systemd-journald is started, the value will be raised to percentage that is actually free."
I don't understand that :-?
Anyway, the filesystem is not close to full. 58% ussage of "/".
Maybe it needs journalctl --vacuum-time=2d or journalctl --vacuum-size=500M
Telcontar:~ # journalctl --vacuum-time=2d journalctl: unrecognized option '--vacuum-time=2d' Telcontar:~ # journalctl --vacuum-size=500M journalctl: unrecognized option '--vacuum-size=500M' Telcontar:~ #
Ah it's a very new option. But this worked on my 13.1 (systemd 210); edit /etc/journald.conf [Journal] SystemMaxUse=100M RuntimeMaxUse=50M # nothing else ... $ journalctl --disk-usage Journals take up 160.0M on disk. $ systemctl restart systemd-journald $ journalctl --disk-usage Journals take up 64.0M on disk. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-03 13:05, Ruediger Meier wrote:
On Thursday 03 March 2016, Carlos E. R. wrote:
Telcontar:~ # journalctl --vacuum-time=2d journalctl: unrecognized option '--vacuum-time=2d' Telcontar:~ # journalctl --vacuum-size=500M journalctl: unrecognized option '--vacuum-size=500M' Telcontar:~ #
Ah it's a very new option.
But this worked on my 13.1 (systemd 210);
edit /etc/journald.conf [Journal] SystemMaxUse=100M RuntimeMaxUse=50M # nothing else ...
$ journalctl --disk-usage Journals take up 160.0M on disk. $ systemctl restart systemd-journald $ journalctl --disk-usage Journals take up 64.0M on disk.
But not here, I don't know why. # # See journald.conf(5) for details [Journal] #CER #Storage=none SystemMaxUse=100M RuntimeMaxUse=50M RuntimeMaxUse=100M MaxLevelStore=warning #Storage=auto #Compress=yes #Seal=yes Telcontar:~ # systemctl restart systemd-journald.service Telcontar:~ # journalctl --disk-usage Journals take up 368.0K on disk. Telcontar:~ # Ah, wait it, now it worked. 368.0 KB, not MB. Or maybe the restart the service forced the log to be purged. I have tried to restart it about five times! Telcontar:~ # journalctl -- Logs begin at Thu 2016-03-03 13:56:17 CET, end at Thu 2016-03-03 13:56:17 CET. -- Mar 03 13:56:17 Telcontar systemd-journal[30085]: Runtime journal is using 137.3M (max 100.0M, leaving 600.1M of free 3.7G, current limit 100.0M). Telcontar:~ # I have done a cosmetic change: I moved the changes to the top of the config file instead of the bottom. This is 13.1, but without the last systemd update because it causes problems with services starting, it is broken. Telcontar:~ # rpm -q systemd systemd-208-35.1.x86_64 -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 03/03/2016 06:33 AM, Carlos E. R. wrote:
Exactly. Mine is big:
And how does that compare to a text based repository containing the same information? Recall, /var/log/mesages is already filtered since it ONLY logs syslog protocol messages. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-03 17:04, Anton Aylward wrote:
On 03/03/2016 06:33 AM, Carlos E. R. wrote:
Exactly. Mine is big:
And how does that compare to a text based repository containing the same information? Recall, /var/log/mesages is already filtered since it ONLY logs syslog protocol messages.
No, I'm considering all logged entries, not only syslog protocol messages. Actually, replicated: Telcontar:~ # ls -lh /var/log/allmessages* -rw-r----- 1 root root 7.1M Mar 3 17:06 /var/log/allmessages -rw-r----- 1 root root 1.1M Feb 14 22:15 /var/log/allmessages-20160214.xz -rw-r----- 1 root root 787K Feb 16 22:15 /var/log/allmessages-20160216.xz -rw-r----- 1 root root 2.8M Feb 26 09:15 /var/log/allmessages-20160226.xz -rw-r----- 1 root root 1.1M Feb 28 13:00 /var/log/allmessages-20160228.xz -rw-r----- 1 root root 1.1M Mar 1 22:15 /var/log/allmessages-20160301.xz -rw-r----- 1 root root 9.0M Dec 12 2014 /var/log/allmessages~ Telcontar:~ # Those are the entire logs of all things for about two weeks. The journal for 6 days takes 300 MB. My case rests, your honour ;-) :-p -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 03/03/2016 03:55 AM, Carlos E. R. wrote:
Telcontar:~ # time journalctl --no-pager | grep "fetchnews\|postfix\|fetchmail" | wc -l 202170
real 0m7.878s user 0m6.173s sys 0m1.351s Telcontar:~ #
That in six days.
No fair! try this time journalctl --no-pager _COMM=fetchnews \ _COMM=postfix \ _COMM=fetchmail | wc -l -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-03 16:01, Anton Aylward wrote:
On 03/03/2016 03:55 AM, Carlos E. R. wrote:
Telcontar:~ # time journalctl --no-pager | grep "fetchnews\|postfix\|fetchmail" | wc -l 202170
real 0m7.878s user 0m6.173s sys 0m1.351s Telcontar:~ #
That in six days.
No fair!
try this
time journalctl --no-pager _COMM=fetchnews \ _COMM=postfix \ _COMM=fetchmail | wc -l
It is very fair. Two weeks, including mail and news and everything: Telcontar:~ # ls -lh /var/log/allmessages* -rw-r----- 1 root root 7.1M Mar 3 17:06 /var/log/allmessages -rw-r----- 1 root root 1.1M Feb 14 22:15 /var/log/allmessages-20160214.xz -rw-r----- 1 root root 787K Feb 16 22:15 /var/log/allmessages-20160216.xz -rw-r----- 1 root root 2.8M Feb 26 09:15 /var/log/allmessages-20160226.xz -rw-r----- 1 root root 1.1M Feb 28 13:00 /var/log/allmessages-20160228.xz -rw-r----- 1 root root 1.1M Mar 1 22:15 /var/log/allmessages-20160301.xz -rw-r----- 1 root root 9.0M Dec 12 2014 /var/log/allmessages~ Telcontar:~ # -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 03/03/2016 11:12 AM, Carlos E. R. wrote:
It is very fair. Two weeks, including mail and news and everything:
The point I was trying to make wasn't about the time span but about the method. Having journalctl output *everything* then greping is the wrong way to do it. Journalctl is managing what amounts to a database, make the database mechanism, the 'indexing', do the work. In effect you wrote select * from all tables | grep .... where I was writing select 'postfix' or 'fetchmail' or 'fetchnews' from commands ... That you choose, in your specific config, to have different time spans for journald and /var/log/messages is just being antagonistic and missing the point. You used journalctl in your grep example, and that CAN be compared with the use of journalctl without grep in my example on your machine. Whether your journalctl covers the same timespan as your syslog is not relevant here, only the performance of a journalctl based pipeline with two different ways of filering are being compared. The different timespans are a red herring. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-03 17:59, Anton Aylward wrote:
On 03/03/2016 11:12 AM, Carlos E. R. wrote:
It is very fair. Two weeks, including mail and news and everything:
The point I was trying to make wasn't about the time span but about the method. Having journalctl output *everything* then greping is the wrong way to do it. Journalctl is managing what amounts to a database, make the database mechanism, the 'indexing', do the work.
In effect you wrote
select * from all tables | grep ....
where I was writing
select 'postfix' or 'fetchmail' or 'fetchnews' from commands ...
That you choose, in your specific config, to have different time spans for journald and /var/log/messages is just being antagonistic and missing the point.
Wait. My point was about the size of the logs, not about how to select entries. I'm familiar with using databases for log systems: in fact, that was one of my jobs. I worked at a control centre for a telephone network watching reports for issues, which were automatically collected from text logs from several "machines" all over the country and placed into a specific database for analysis and real time alarms (Lucent Network Fault Management (NFM)). No, my issue with the journal is that the log for 6 days uses 300 MB, while the syslog for more than double that same period uses less than 30MB. I previously used grep on the log to show that the majority of entries came from mail and news system. And I used grep because I have not found the way to tell journalctl to print simply the entries for one of the "facilities", in this case, "mail". cer@Telcontar:~> man journalctl | grep facility cer@Telcontar:~> -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
I previously used grep on the log to show that the majority of entries came from mail and news system. And I used grep because I have not found the way to tell journalctl to print simply the entries for one of the "facilities", in this case, "mail".
cer@Telcontar:~> man journalctl | grep facility
On that page look for MATCHES, then look up: man systemd.journal-fields Try this: journalctl -b 0 SYSLOG_FACILITY=mail I still prefer "less /var/log/mail". Takes less time to type and less man page lookups :-) -- Per Jessen, Zürich (3.4°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Per Jessen <per@computer.org> [03-03-16 12:40]:
Carlos E. R. wrote:
I previously used grep on the log to show that the majority of entries came from mail and news system. And I used grep because I have not found the way to tell journalctl to print simply the entries for one of the "facilities", in this case, "mail".
cer@Telcontar:~> man journalctl | grep facility
On that page look for MATCHES, then look up:
man systemd.journal-fields
Try this:
journalctl -b 0 SYSLOG_FACILITY=mail
I still prefer "less /var/log/mail". Takes less time to type and less man page lookups :-)
It does and that is the *painful* part of change, but after becoming familiar with repeditive searches, the change becomes second nature toooo. systemctl isolate graphical.target is ridiculous compared to runlevel 5 and then we have aliases :) and forget the *normal* method. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Patrick Shanahan wrote:
* Per Jessen <per@computer.org> [03-03-16 12:40]:
Carlos E. R. wrote:
I previously used grep on the log to show that the majority of entries came from mail and news system. And I used grep because I have not found the way to tell journalctl to print simply the entries for one of the "facilities", in this case, "mail".
cer@Telcontar:~> man journalctl | grep facility
On that page look for MATCHES, then look up:
man systemd.journal-fields
Try this:
journalctl -b 0 SYSLOG_FACILITY=mail
I still prefer "less /var/log/mail". Takes less time to type and less man page lookups :-)
It does and that is the *painful* part of change, but after becoming familiar with repeditive searches, the change becomes second nature toooo.
Agree completely, hence the smiley. The topic is really still the old one from 2012 - why did we (= the openSUSE project) get rid of having a syslog daemon as a default when it does in fact serve purposes that journalctl does not. It's not one I can be bothered to discuss - been there, done that, waste of time in the end. As one of my good friends like to say - in our anarc ... uh, do-ocracy, why don't I just go change that default back? -- Per Jessen, Zürich (3.2°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd wrote:
Le 03/03/2016 18:51, Per Jessen a écrit :
why don't I just go change that default back?
as long as you can change it very easily, why?
Because I want to contribute. Because I believe that we have the wrong default. Because my list of "things to change" when I install openSUSE is growing longer and longer due to other people making wild changes without really considering the target audience. Also, as my friend pointed out, I should simply go and do it to see how well the do-ocracy works. -- Per Jessen, Zürich (2.3°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 03/03/2016 20:05, Per Jessen a écrit :
jdd wrote:
as long as you can change it very easily, why?
Because I want to contribute. Because I believe that we have the wrong default. Because my list of "things to change" when I install openSUSE is growing longer and longer due to other people making wild changes without really considering the target audience.
target audience is what? the defaults fits perfectly my needs, as did the other system, by the way, but I don't expect things to last forever. I think it's easier to learn things as they come, because at a moment or an other I will have to and then may not have the will, time or ability to do. I began computer with scientific calculators and use PC nearly since the beginning (in fact Personal Computers before the IBM PC), so I learned to use 8" floppies, 5" floppies, 3" floppies, zyps, cd's... up to spinning Hard drives, usb sticks and ssd. people using a recent PC with multimedia capabilities have a enormous quantity of things to learn (and often fails to). simply setting Facebook is more hard than compiling a linux kernel in year 2000 :-)) it's life jdd NB: I still have working HP-41C :-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/03/2016 02:14 PM, jdd wrote:
people using a recent PC with multimedia capabilities have a enormous quantity of things to learn (and often fails to).
Indeed. Peoeple like Thee and Mee have learnt from simple(r) systems to the more complex gradually. Kids today are being thrown in the deep end of complexity right away. No doubt that accounts for the nature of sme of the questions asked here. But to deal with the new one has to be willing to surrender many things associated with the old. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd wrote:
Le 03/03/2016 20:05, Per Jessen a écrit :
jdd wrote:
as long as you can change it very easily, why?
Because I want to contribute. Because I believe that we have the wrong default. Because my list of "things to change" when I install openSUSE is growing longer and longer due to other people making wild changes without really considering the target audience.
target audience is what?
A very good question, the answer depends on who you ask.
the defaults fits perfectly my needs, as did the other system, by the way, but I don't expect things to last forever.
Since around 12.x, my list of things to customize has been growing longer and longer, for desktop and server installs both. The default used to be a sound compromise, but I think we've lost track of our target audience.
I began computer with scientific calculators and use PC nearly since the beginning (in fact Personal Computers before the IBM PC), so I learned to use 8" floppies, 5" floppies, 3" floppies, zyps, cd's... up to spinning Hard drives, usb sticks and ssd.
Yes, been there, done that. First programmable calculator HP25C, followed by writing COMAL on an RC7000 with 32k core memory, paper-punch and teletype: (aka Data General Nova 1200): http://datamuseum.dk/wiki/RC/RC7000. The toggle-switches on the front were for boot-strapping it. That was in the late 70s. Thanks for the trip down memory lane :-)
it's life jdd NB: I still have working HP-41C :-)
The HP25C is long gone, I switched to HP15C - still use one every day. -- Per Jessen, Zürich (2.6°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-04 09:14, Per Jessen wrote:
the beginning (in fact Personal Computers before the IBM PC), so I learned to use 8" floppies, 5" floppies, 3" floppies, zyps, cd's... up to spinning Hard drives, usb sticks and ssd. Yes, been there, done that. First programmable calculator HP25C, followed by writing COMAL on an RC7000 with 32k core memory,
I began computer with scientific calculators and use PC nearly since paper-punch and teletype: (aka Data General Nova 1200): http://datamuseum.dk/wiki/RC/RC7000. The toggle-switches on the front were for boot-strapping it. That was in the late 70s. Thanks for the trip down memory lane :-)
I started with the Texas Instrument TI-57, in high school, I think. 50 programmable steps. I managed to do a small lunar landing simulation on it. https://en.wikipedia.org/wiki/TI-57 The LED version, I never saw the LCD one. Later I got a TI-58 hand me down from my cousin. The battery charge in this thing lasted about 2 hours, dangerous for exams. And the keyboard in the two TI I had developed a repeat feature on keypresses, causing math errors that I blame for some failed exams. I finally got a Casio FX-850P which I still use. This one has Basic. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Le 04/03/2016 12:28, Carlos E. R. a écrit :
I started with the Texas Instrument TI-57, in high school, I think. 50 programmable steps. I managed to do a small lunar landing simulation on it.
I drived a computer club on it in my high school (as a teacher)
https://en.wikipedia.org/wiki/TI-57
The LED version, I never saw the LCD one.
was unusable, the 50 steps where for program *and* memory jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-04 12:47, jdd wrote:
https://en.wikipedia.org/wiki/TI-57
The LED version, I never saw the LCD one.
was unusable, the 50 steps where for program *and* memory
Not this one. 50 steps plus 10 memories, perhaps 9, not sure. The wikipedia is wrong in this respect. It was the TI58/59 in which the RAM could be partitioned to select a variable amount for program or memory (data). I see the wikipedia mentions a hack for the battery: use a real 9V battery instead. I would have liked to know about it at the time. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Le 04/03/2016 12:55, Carlos E. R. a écrit :
On 2016-03-04 12:47, jdd wrote:
https://en.wikipedia.org/wiki/TI-57
The LED version, I never saw the LCD one.
was unusable, the 50 steps where for program *and* memory
Not this one. 50 steps plus 10 memories, perhaps 9, not sure.
the led one, not the lcd one, in fact very different (as said in wikipedia) the led one was very smart jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/04/2016 03:14 AM, Per Jessen wrote:
The HP25C is long gone, I switched to HP15C - still use one every day.
Indeed. I, too, have an android smartphone https://play.google.com/store/apps/details?id=com.hp.hp15c15&hl=en Mind you, if I want to do RPN on my phone I'll use gFORTH. But that get back to text mode vs gui, doesn't it? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 04/03/2016 15:09, Anton Aylward a écrit :
On 03/04/2016 03:14 AM, Per Jessen wrote:
The HP25C is long gone, I switched to HP15C - still use one every day.
Indeed. I, too, have an android smartphone https://play.google.com/store/apps/details?id=com.hp.hp15c15&hl=en
Mind you, if I want to do RPN on my phone I'll use gFORTH. But that get back to text mode vs gui, doesn't it?
me use "realcalc", rpm emulator jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/04/2016 09:17 AM, jdd wrote:
Le 04/03/2016 15:09, Anton Aylward a écrit :
On 03/04/2016 03:14 AM, Per Jessen wrote:
The HP25C is long gone, I switched to HP15C - still use one every day.
Indeed. I, too, have an android smartphone https://play.google.com/store/apps/details?id=com.hp.hp15c15&hl=en
Mind you, if I want to do RPN on my phone I'll use gFORTH. But that get back to text mode vs gui, doesn't it?
me use "realcalc", rpm emulator
I think you typo'd 'rpn'. The only real RPN calculator is LiSP. If God does not write LiSP, God writes some code so similar to LiSP as to make no difference. Forth: Lisp without being Lost In the Sea of (Lots of ((Irritating, Spurious) (Parentheses))) Irritating Single Parentheses -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 04/03/2016 15:28, Anton Aylward a écrit :
On 03/04/2016 09:17 AM, jdd wrote:
me use "realcalc", rpm emulator
I think you typo'd 'rpn'.
yes, of course :-)
The only real RPN calculator is LiSP.
If God does not write LiSP, God writes some code so similar to LiSP as to make no difference.
Forth: Lisp without being Lost In the Sea of (Lots of ((Irritating, Spurious) (Parentheses))) Irritating Single Parentheses
:-), but integer only :-) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/04/2016 09:31 AM, jdd wrote:
Le 04/03/2016 15:28, Anton Aylward a écrit :
On 03/04/2016 09:17 AM, jdd wrote:
me use "realcalc", rpm emulator
I think you typo'd 'rpn'.
yes, of course :-)
The only real RPN calculator is LiSP.
If God does not write LiSP, God writes some code so similar to LiSP as to make no difference.
Forth: Lisp without being Lost In the Sea of (Lots of ((Irritating, Spurious) (Parentheses))) Irritating Single Parentheses
:-), but integer only :-)
Actually LiSp has "machine based" floating point, and the degree of precision to which God's machine, the universe' can calculate, for example, Pi, is better than we have with any "indefinite precision" package. And don't forget, the universe is also a massively parallel, multiple instruction, multiple data steam emulator. See also https://en.wikipedia.org/wiki/Church%E2%80%93Turing%E2%80%93Deutsch_principl... -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 04/03/2016 15:48, Anton Aylward a écrit :
On 03/04/2016 09:31 AM, jdd wrote:
Forth: Lisp without being Lost In the Sea of (Lots of ((Irritating, Spurious) (Parentheses))) Irritating Single Parentheses
:-), but integer only :-)
Actually LiSp has "machine based" floating point, and the degree of
Forth is integer only, enough for most usual caculation. I used a dos lotus clone called vpplanner https://en.wikipedia.org/wiki/Paperback_Software_International coded in forth it didn't need the math coprocessor that other software needed and could run on 386 (the real one) without the copro jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/04/2016 11:14 AM, jdd wrote:
Forth is integer only
Yes it used to be but we changed all that. American National Standards Institute FORTH can do floating point calculations, just like modern LisP can. It was decided to implement this using a separate stack from the native mode fixed arithmetic. http://www.triangledigital.com/man2020f/ch3ansfp.htm Why? https://groups.google.com/forum/#!topic/comp.lang.forth/QmqcJJE2bQk See also http://www.forth200x.org/documents/html/diff.html an d http://www.forth.org/fd/FD-V08N5.pdf I've implemented FORTH directly (i.e. not in C, C++ or java) on a variety of machines, PDP-11, Z-8000 (wonderful for keeping the top few elements of stack in the register bank, wonderful for using other registers as pointers to the various stacks), M68000, and also an 8-bit 8051 for an embedded application. I've tried gFORTH but get to wonder why one has to implement what amounts to sophisticated machine code in a HLL interpreter. gFORTH also has floating point https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Floating-Point-Tuto... Yes, its there; yes its part of the current standard. No, I've never implemented it. I've never needed it. But then the applications I've written in FORTH have never needed it. To be honest, I've never even needed 16 bits of arithmetic. I can see that Leo's original application involving astronomy and telescopes would need floating point but apparently he did what many programmers did and used fixed point precision with long integers. BTDT. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 04/03/2016 21:07, Anton Aylward a écrit :
On 03/04/2016 11:14 AM, jdd wrote:
Forth is integer only
Yes it used to be but we changed all that.
of course, math libraries exists for very long, but
Yes, its there; yes its part of the current standard. No, I've never implemented it. I've never needed it. But then the applications I've written in FORTH have never needed it. To be honest, I've never even needed 16 bits of arithmetic.
exactly it have much less drawbacks nowadays, math copro being always included, but I still guess Forth can be incredibly fast and compact. I always was a hacker, not a real programmer, but 20 years ago I played making code that could program itself, writing to it's own code segment, played with text buffer and it was fun. I also remember a text processor (sprint from Borland) that used similar pointer joke, being able to jump from start to end of a bible long book in a snap. I often feel like we do the same than 20 years ago with 1000x more powerful computers and very little enhancement :-) fairy tales of old timers :-)) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/04/2016 03:07 PM, Anton Aylward wrote:
Forth is integer only Yes it used to be but we changed all that.
American National Standards Institute FORTH can do floating point calculations, just like modern LisP can.
Go FORTH and multiply! ;-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
On 03/04/2016 03:14 AM, Per Jessen wrote:
The HP25C is long gone, I switched to HP15C - still use one every day.
Indeed. I, too, have an android smartphone https://play.google.com/store/apps/details?id=com.hp.hp15c15&hl=en
Wow, didn't know one existed. I'm actually still using my original HP15C from 82-83. I also have a Limited Edition somewhere, still in its box. -- Per Jessen, Zürich (5.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/04/2016 09:31 AM, Per Jessen wrote:
Anton Aylward wrote:
On 03/04/2016 03:14 AM, Per Jessen wrote:
The HP25C is long gone, I switched to HP15C - still use one every day.
Indeed. I, too, have an android smartphone https://play.google.com/store/apps/details?id=com.hp.hp15c15&hl=en
Wow, didn't know one existed. I'm actually still using my original HP15C from 82-83. I also have a Limited Edition somewhere, still in its box.
WOW! Not quite as fungible as gold krugerrands, but so long as eBay is out there you have a emergency fund with that. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/04/2016 09:09 AM, Anton Aylward wrote:
On 03/04/2016 03:14 AM, Per Jessen wrote:
The HP25C is long gone, I switched to HP15C - still use one every day. Indeed. I, too, have an android smartphone https://play.google.com/store/apps/details?id=com.hp.hp15c15&hl=en
Mind you, if I want to do RPN on my phone I'll use gFORTH. But that get back to text mode vs gui, doesn't it?
My first calculator was a "four banger", basic arithmetic, no memory, fixed point. It cost $150, back in 1975. I then got a Novus Mathematician, which used RPN. I then had a couple of Sharp scientific calculators, which were pretty good and now use a calculator app called "RealCalc" on my Android phone. However, I still have a slide rule in my desk drawer, just in case... ;-) BTW, I bought that slide rule for $2, when I started high school in 1967. It's a Pickett Microline 120. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-03-04 23:51, James Knott wrote:
My first calculator was a "four banger", basic arithmetic, no memory, fixed point. It cost $150, back in 1975.
I don't remember how much ours was, same type. A Sharp, green fluorescent numbers. My father bought it during a trip to the UK, cheaper than here.
and now use a calculator app called "RealCalc" on my Android phone.
I just downloaded it. Too complex. The one on my Motorola is way to simple (no memory), but realcalc is exceedingly complex.
However, I still have a slide rule in my desk drawer, just in case... ;-)
I have two big, one small, from my father and his uncle, I think. I just know how to do multiplications and divisions on it. I didn't use it in school just for a few years, calculators were starting to be accessible. The military trainees still had to use slide rules in case batteries failed in battle or some thing, for some years more. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlbamDUACgkQja8UbcUWM1wobwD+JEjEdkJ7KJbenMKeYZhugoHG bl76XGytGbMNotBQJLwA/itWazSXrh9HKGo6EU825C18mcYV2oWNP3viPvQQvwfP =rIPY -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/05/2016 12:26 AM, Carlos E. R. wrote:
I just downloaded it. Too complex. The one on my Motorola is way to simple (no memory),
I was bitching when I got my last new Android about how basic and useless the calculator was. How could they be so dumb as to put that miserable thing in an expensive phone. Then I turned the phone to Landscape. Boom! Memory is via normal copy/paste. -- After all is said and done, more is said than done.
On 2016-03-05 19:10, John Andersen wrote:
On 03/05/2016 12:26 AM, Carlos E. R. wrote:
I just downloaded it. Too complex. The one on my Motorola is way to simple (no memory),
I was bitching when I got my last new Android about how basic and useless the calculator was. How could they be so dumb as to put that miserable thing in an expensive phone.
Then I turned the phone to Landscape. Boom! Memory is via normal copy/paste.
Yes, it gets more functionalities, like sin(), which I do not need in a phone. What I need is M+, M-, Mrc, not copy paste. And parenthesis. Ah, no, those it has. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 03/05/2016 10:54 AM, Carlos E. R. wrote:
What I need is M+, M-, Mrc, not copy paste
Well you can get that by copy and paste preceeded by +/- but yes it is obtuse as hell. Maybe try CALCU in the app store. It has the memory functions (turn on on in settings) as well as pull down history, which you can tap any prior result to use it again. Free or $1.99 to remove ads -- After all is said and done, more is said than done.
Le 03/03/2016 18:45, Patrick Shanahan a écrit :
systemctl isolate graphical.target is ridiculous compared to runlevel 5
and then we have aliases :) and forget the *normal* method.
openSUSE way, but do you remember /etc/init.d/whatever jdd :-) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* jdd <jdd@dodin.org> [03-03-16 12:53]:
Le 03/03/2016 18:45, Patrick Shanahan a écrit :
systemctl isolate graphical.target is ridiculous compared to runlevel 5
and then we have aliases :) and forget the *normal* method.
openSUSE way, but do you remember /etc/init.d/whatever
init 5 was certainly simpler yet :) -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 03/03/2016 18:40, Per Jessen a écrit :
I still prefer "less /var/log/mail". Takes less time to type and less man page lookups :-)
but with parallel login on boot messages are very difficult to follow jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-03 18:40, Per Jessen wrote:
Carlos E. R. wrote:
I previously used grep on the log to show that the majority of entries came from mail and news system. And I used grep because I have not found the way to tell journalctl to print simply the entries for one of the "facilities", in this case, "mail".
cer@Telcontar:~> man journalctl | grep facility
On that page look for MATCHES, then look up:
man systemd.journal-fields
I did a moment ago. But it looked like it wanted the numeric value.
Try this:
journalctl -b 0 SYSLOG_FACILITY=mail
At this point, it produces nothing. I restarted the service some hours ago, and this entry in the config seems to have effect: MaxLevelStore=warning The log now contains just 10 lines, thus I managed to about impeding the journal from growing too much. Also, it is saying now: Mar 03 18:51:50 Telcontar systemd-journal[9751]: Runtime journal is using 380.0K (max 50.0M, leaving 600.1M of free 3.9G, current limit 50.0M). So the size limit finally now applies.
I still prefer "less /var/log/mail". Takes less time to type and less man page lookups :-)
Yep :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2016-03-03 18:40, Per Jessen wrote:
Carlos E. R. wrote:
I previously used grep on the log to show that the majority of entries came from mail and news system. And I used grep because I have not found the way to tell journalctl to print simply the entries for one of the "facilities", in this case, "mail".
cer@Telcontar:~> man journalctl | grep facility
On that page look for MATCHES, then look up:
man systemd.journal-fields
I did a moment ago. But it looked like it wanted the numeric value.
Try this:
journalctl -b 0 SYSLOG_FACILITY=mail
At this point, it produces nothing.
Well spotted, Carlos. I took my own medicine and choked - it looks like you have to use: journalctl -b 0 SYSLOG_FACILITY=2 -o short-iso to get /var/log/mail from today. Having to specify 2 instead of mail is a gigantic usability issue. One can only surmise that this isn't being used much. -- Per Jessen, Zürich (3.3°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-03 20:00, Per Jessen wrote:
Carlos E. R. wrote:
At this point, it produces nothing.
Well spotted, Carlos. I took my own medicine and choked - it looks like you have to use:
journalctl -b 0 SYSLOG_FACILITY=2 -o short-iso
to get /var/log/mail from today.
Oh! :-( Yes, that does produce about a hundred lines of output. I haven't processed email today.
Having to specify 2 instead of mail is a gigantic usability issue. One can only surmise that this isn't being used much.
Indeed. I happen to know the number, because my logs are written in this format (which I'm going to change one day, again): <2.6> 2016-03-03 20:03:28 Telcontar postfix 12625 - - disconnect from localhost[127.0.0.1] The two numbers at the start are facility.priority. Which took some hours of reading, because the default rsyslog format printed a combined number. But to find out the numeric value for a certain facility from scratch is not that simple. Once you know where to look, yes. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
But to find out the numeric value for a certain facility from scratch is not that simple. Once you know where to look, yes.
/usr/include/sys/syslog.h (I found mail=2 by trial and error). -- Per Jessen, Zürich (2.6°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/03/2016 12:17 PM, Carlos E. R. wrote:
Wait. My point was about the size of the logs,
No your point was about the time it took to run that command. Yes, you've discussed size, repeatedly, but this thread isn't sufficiently differentiated. I was referring specifically to Message-ID: <56D7FBEB.5000001@telefonica.net> Date: Thu, 3 Mar 2016 09:55:07 +0100 where you said:
But I'd prefer not to have journal running. Or at least impede some entries from going into it, like email or nntp.
Telcontar:~ # time journalctl --no-pager | grep "fetchnews\|postfix\|fetchmail" | wc -l 202170
real 0m7.878s user 0m6.173s sys 0m1.351s
I said that instead of the "grep" in that pipeline you should use the proper journalctl filters. Yes, those times are outrageous, I agree, but its because you are getting journalctl to format and output *ALL* of its entries. There is no need for that. That you could, by proper configuration, have separate logs for those process, is quite another matter; I've touched on that. As for size, each journalctl record is much more comprehensive than a syslog record. The format you've requested output is just the syslog compatible form, which is much less than journald actually has. In addition, the ability to filter without 'grepping' means that the database also contains hash-chains for indexing. If you were to add a parallel index to your /var/log/messages (etc..etc) to allow equally comprehensive searches and filtering then the size would go up too. My whole point here is that the indexes *DO* exist and you can specify directly to journalctl to make use of them instead of outputting the whole and grepping. An analogy would be to have a database ... select all field from table | sort vs select all field from table using index order-by ... -- Let us never forget that government is ourselves and not an alien power over us. The ultimate rulers of our democracy are not a President and senators and congressmen and government officials, but the voters of this country.” -- Franklin D. Roosevelt -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-03 19:42, Anton Aylward wrote:
On 03/03/2016 12:17 PM, Carlos E. R. wrote:
Wait. My point was about the size of the logs,
...
where you said:
But I'd prefer not to have journal running. Or at least impede some entries from going into it, like email or nntp.
Telcontar:~ # time journalctl --no-pager | grep "fetchnews\|postfix\|fetchmail" | wc -l 202170
real 0m7.878s user 0m6.173s sys 0m1.351s
The important data on that command output is the number of lines, not the time it took to run. You are picking on the time, but that one is not important there.
I said that instead of the "grep" in that pipeline you should use the proper journalctl filters.
Yes, those times are outrageous, I agree, but its because you are getting journalctl to format and output *ALL* of its entries. There is no need for that.
Again, no, I'm not worried about time in that command. It took just 8 seconds, it is stored in RAM.
An analogy would be to have a database ...
Again, I know very well the advantages of having a log in a database. It was my job. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 03/03/2016 02:03 PM, Carlos E. R. wrote:
The important data on that command output is the number of lines, not the time it took to run. You are picking on the time, but that one is not important there.
Same answer. Don't use grep. Use the filtering power of journalctl. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
On 03/03/2016 02:03 PM, Carlos E. R. wrote:
The important data on that command output is the number of lines, not the time it took to run. You are picking on the time, but that one is not important there.
Same answer. Don't use grep. Use the filtering power of journalctl.
Anton, sounds to me as if you're saying is "abandon what you have used for decades, there's a new syslog in town". You wanna search any other file, and e/grep is the answer - but if it's the journal, ah no. It really is not overly intuitive. Especially when the "filtering power of journalctl" is handicapped, backward and probably not used much. -- Per Jessen, Zürich (2.4°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/03/2016 02:24 PM, Per Jessen wrote:
Anton Aylward wrote:
On 03/03/2016 02:03 PM, Carlos E. R. wrote:
The important data on that command output is the number of lines, not the time it took to run. You are picking on the time, but that one is not important there.
Same answer. Don't use grep. Use the filtering power of journalctl.
Anton, sounds to me as if you're saying is "abandon what you have used for decades, there's a new syslog in town". You wanna search any other file, and e/grep is the answer - but if it's the journal, ah no. It really is not overly intuitive. Especially when the "filtering power of journalctl" is handicapped, backward and probably not used much.
You're playing yes-but games. Yes bit it isn't about time, its about number of entries Yes but it isn't about number of entries its about having to learn something new Yes but ... Where will this stop? Its not about 'grep', really. If I demonstrated that using 'awk' meant that you didn't have to run 'wc' you'd come up with some other "yes, but". I'm not arguing here about the power of grep or awk or piplelines, but about using journbalctl in an inapproriate manner. Journalsctl is not syslog. I've never tried sayin ghat it is, but only that it can do some of the job. You can't compare a indexed/has-chain record keeping system that sores a lot more information with a plain text file without any indexing in the way you've been trying. To have a level playing field you are going to have to create a full text index of everything in /var/log, or at the very elats a QUICK index, and then use the index system to find the rcords or step though the record chain, rather than acess the plain text file directly. Alternatively you could have systemd dump all its records, possibly in JSON form to show how more comprehensive they are than syslog entries, and use awk or egrep to scan that static text file. Yes you could use journalctl with the parameters I suggest and then run it though grep, but that's redundant. But stop playing yes-but. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-03 20:05, Anton Aylward wrote:
On 03/03/2016 02:03 PM, Carlos E. R. wrote:
The important data on that command output is the number of lines, not the time it took to run. You are picking on the time, but that one is not important there.
Same answer. Don't use grep. Use the filtering power of journalctl.
Again, no. I don't care about grep or filtering power, I care about the huge size of the log. I was using grep as a tool to show the huge size of the mail and news log. 300MB of it, in RAM. Please don't fixate on the tool I used, and tell me how to purge mail and news out of the log, reducing the size of the log dramatically. That's what I care about, the huge resource hog it is. Or don't waste your time, because I know it is impossible. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Thursday 03 March 2016, Anton Aylward wrote:
On 03/03/2016 03:55 AM, Carlos E. R. wrote:
Telcontar:~ # time journalctl --no-pager | grep "fetchnews\|postfix\|fetchmail" | wc -l 202170
real 0m7.878s user 0m6.173s sys 0m1.351s Telcontar:~ #
That in six days.
No fair!
try this
time journalctl --no-pager _COMM=fetchnews \ _COMM=postfix \ _COMM=fetchmail | wc -l
Hehe this comparision is even better. :) $ time grep "sshd" /var/log/messages | wc -l 34755 real 0m0.066s user 0m0.052s sys 0m0.016s $ time journalctl --no-pager _COMM=sshd | wc -l 34945 real 0m2.097s user 0m1.916s sys 0m0.168s Note that this journal is stored in RAM. What is RAM speed today? 10-20GB/s? Journald is able to show 7MB/s. Congratulations. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/03/2016 03:13 PM, Ruediger Meier wrote:
On Thursday 03 March 2016, Anton Aylward wrote:
On 03/03/2016 03:55 AM, Carlos E. R. wrote:
Telcontar:~ # time journalctl --no-pager | grep "fetchnews\|postfix\|fetchmail" | wc -l 202170
real 0m7.878s user 0m6.173s sys 0m1.351s Telcontar:~ #
That in six days.
No fair!
try this
time journalctl --no-pager _COMM=fetchnews \ _COMM=postfix \ _COMM=fetchmail | wc -l
Hehe this comparision is even better. :)
$ time grep "sshd" /var/log/messages | wc -l 34755
real 0m0.066s user 0m0.052s sys 0m0.016s
$ time journalctl --no-pager _COMM=sshd | wc -l 34945
real 0m2.097s user 0m1.916s sys 0m0.168s
Note that this journal is stored in RAM. What is RAM speed today? 10-20GB/s? Journald is able to show 7MB/s. Congratulations.
And how many total records in /var/log/messages and how many total records in journald? And how does that compare with journalctl _SYSTEMD_UNIT=sshd.service -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday 03 March 2016, Anton Aylward wrote:
On 03/03/2016 03:13 PM, Ruediger Meier wrote:
Hehe this comparision is even better. :)
$ time grep "sshd" /var/log/messages | wc -l 34755
real 0m0.066s user 0m0.052s sys 0m0.016s
$ time journalctl --no-pager _COMM=sshd | wc -l 34945
real 0m2.097s user 0m1.916s sys 0m0.168s
Note that this journal is stored in RAM. What is RAM speed today? 10-20GB/s? Journald is able to show 7MB/s. Congratulations.
And how many total records in /var/log/messages and how many total records in journald?
And how does that compare with
journalctl _SYSTEMD_UNIT=sshd.service
This is a feature I don't need and it's also terrible slow: $ time journalctl _SYSTEMD_UNIT=sshd.service > /dev/null real 0m1.835s user 0m1.788s sys 0m0.036s Note, after shrinking the journal today it contains logs only from last 5 days! Last month I've had more than 100 days uptime and all these journalctl operations took 1-2 _minutes_! cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/03/2016 03:42 PM, Ruediger Meier wrote:
Hehe this comparision is even better. :)
$ time grep "sshd" /var/log/messages | wc -l 34755
real 0m0.066s user 0m0.052s sys 0m0.016s
$ time journalctl --no-pager _COMM=sshd | wc -l 34945
real 0m2.097s user 0m1.916s sys 0m0.168s
Note that this journal is stored in RAM. What is RAM speed today? 10-20GB/s? Journald is able to show 7MB/s. Congratulations.
Actually, thinking about it, that doesn't surprise me at all. Firstly, grep is really about regular expressions. you've given it a single fixed string, not a regular expression. Asking it to look for "s\{2\}[Hh]\{1\}[^A-Za-ce-z]" is also valid but is going to be a more demanding and hence slower evaluation (I how I've got the RE right) Secondly, anyone who has had to deal with relational databases, that is ones where the query is based on arbitrary fields, know that the setup time is what dominates. The setup time for a single value of a field and for a number of different values of the same field is going to be about the same. And of course there's then formatting for IO. The original question had a RE for grep, not a single value, and a multiple OR for the same field for journalctl. That's quite a different balance between setup and evaluation from your example above. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
03.03.2016 11:55, Carlos E. R. пишет:
On 2016-03-03 08:29, Per Jessen wrote:
Carlos E. R. wrote:
In fact, reading (dumping) the systemd journal is terribly slow because (educated guess) heavy on disk fragmentation. Unless the HD is an SSD.
Yes, I remember reading something about at some point. I don't use the journal myself, I always run syslog-ng.
Me too. Well, rsyslog.
But I'd prefer not to have journal running.
You can't. All logging in systemd assumes journald is present. It is multiplexor that receives everything and can forward it to other receivers (gateways to remote logging are available as well).
Or at least impede some entries from going into it, like email or nntp.
No. Journald explicitly does not do filtering. What you can do is disable storage and use it only for multiplexing: Storage=none "none" turns off all storage, all log data received will be dropped. Forwarding to other targets, such as the console, the kernel log buffer, or a syslog socket will still work however. Defaults to "auto".
On 03/03/2016 12:46 PM, Andrei Borzenkov wrote:
Or at least impede some entries from going into it, like email or nntp.
No. Journald explicitly does not do filtering.
It depends what you mean by ... JournalCTL does filtering, yes. Many people do not use /var/log/mail* and other separated out logs, they put everything into /var/log/messages. In effect, that is what journald does in its default configuration. But it doesn't have to be like that. You can have journald separate out by UID, for example. I can see that applying, mostly, for users in a multi-user context, servers and ISPs with shared use of the machine, the traditional old way UNIX worked before we had powerful workstations. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-03 21:31, Anton Aylward wrote:
On 03/03/2016 12:46 PM, Andrei Borzenkov wrote:
Or at least impede some entries from going into it, like email or nntp.
No. Journald explicitly does not do filtering.
It depends what you mean by ...
JournalCTL does filtering, yes.
No, it doesn't. We are not talking about reading entries that match a certain filter, but about not having events that match a certain filter written to the log, not stored. Or stored for a different amount of time or up to a different disk size. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 03/03/2016 04:38 PM, Carlos E. R. wrote:
On 2016-03-03 21:31, Anton Aylward wrote:
On 03/03/2016 12:46 PM, Andrei Borzenkov wrote:
Or at least impede some entries from going into it, like email or nntp.
No. Journald explicitly does not do filtering.
It depends what you mean by ...
JournalCTL does filtering, yes.
No, it doesn't. We are not talking about reading entries that match a certain filter, but about not having events that match a certain filter written to the log, not stored. Or stored for a different amount of time or up to a different disk size.
I was trying to make that distinction to start with. Please don't assume that I'm some kind of systemd/journald expert. I'm perhaps one chapter ahead of you in the 'idiots guide', experimented a bit. I'm taking time out from doing my taxes, and discussing this with you is less frustrating that trying to figure those out! -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-03 18:46, Andrei Borzenkov wrote:
No. Journald explicitly does not do filtering.
Does it allow purging entries from the database? Like doing a "logrotate".
What you can do is disable storage and use it only for multiplexing:
Storage=none
"none" turns off all storage, all log data received will be dropped. Forwarding to other targets, such as the console, the kernel log buffer, or a syslog socket will still work however. Defaults to "auto".
Yes, I found that one, but seemed not to work. Now I'm using: [Journal] #CER #Storage=none SystemMaxUse=100M RuntimeMaxUse=50M MaxLevelStore=notice which drastically reduced the content in the journal. Previously the size limit was not honoured, it started working half an hour ago. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
* Carlos E. R. <robin.listas@telefonica.net> [03-03-16 16:49]:
On 2016-03-03 18:46, Andrei Borzenkov wrote:
No. Journald explicitly does not do filtering.
Does it allow purging entries from the database? Like doing a "logrotate".
What you can do is disable storage and use it only for multiplexing:
Storage=none
"none" turns off all storage, all log data received will be dropped. Forwarding to other targets, such as the console, the kernel log buffer, or a syslog socket will still work however. Defaults to "auto".
Yes, I found that one, but seemed not to work. Now I'm using:
[Journal] #CER #Storage=none SystemMaxUse=100M RuntimeMaxUse=50M MaxLevelStore=notice
which drastically reduced the content in the journal. Previously the size limit was not honoured, it started working half an hour ago.
Might work if you remove the first column hash mark: Storage=none ?? -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-03 23:32, Patrick Shanahan wrote:
* Carlos E. R. <> [03-03-16 16:49]:
...
which drastically reduced the content in the journal. Previously the size limit was not honoured, it started working half an hour ago.
Might work if you remove the first column hash mark: Storage=none
??
I suppose so, but it is sufficient reducing most messages. At least for now. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
04.03.2016 00:47, Carlos E. R. пишет:
On 2016-03-03 18:46, Andrei Borzenkov wrote:
No. Journald explicitly does not do filtering.
Does it allow purging entries from the database? Like doing a "logrotate".
There is MaxRetentionSec which is roughly analogous to logrotate time-based retention and *MaxUse and *MaxFiles that are roughly analogous to logrotate size-based retention.
What you can do is disable storage and use it only for multiplexing:
Storage=none
"none" turns off all storage, all log data received will be dropped. Forwarding to other targets, such as the console, the kernel log buffer, or a syslog socket will still work however. Defaults to "auto".
Yes, I found that one, but seemed not to work.
That would be a bug.
Now I'm using:
[Journal] #CER #Storage=none SystemMaxUse=100M RuntimeMaxUse=50M MaxLevelStore=notice
which drastically reduced the content in the journal. Previously the size limit was not honoured, it started working half an hour ago.
All limits apply to archived journal files. It means if you have large files that being actively used they can well go over limit. I won't claim to understand in details how journald manages its storage.
On 2016-03-04 04:59, Andrei Borzenkov wrote:
04.03.2016 00:47, Carlos E. R. пишет:
On 2016-03-03 18:46, Andrei Borzenkov wrote:
No. Journald explicitly does not do filtering.
Does it allow purging entries from the database? Like doing a "logrotate".
There is MaxRetentionSec which is roughly analogous to logrotate time-based retention and *MaxUse and *MaxFiles that are roughly analogous to logrotate size-based retention.
Yes... right. But it is applied to all entries, not selectable by some filtering. For instance, remove early debug entries, leave critical messages for much longer. Likewise, depending on the facility.
Yes, I found that one, but seemed not to work.
That would be a bug.
Maybe... but I'm at 13.1.
Now I'm using:
[Journal] #CER #Storage=none SystemMaxUse=100M RuntimeMaxUse=50M MaxLevelStore=notice
which drastically reduced the content in the journal. Previously the size limit was not honoured, it started working half an hour ago.
All limits apply to archived journal files. It means if you have large files that being actively used they can well go over limit. I won't claim to understand in details how journald manages its storage.
Well, I don't have /var/log/journal. My current problem is, or was, with /run/log/journal, which grew to 300 MB in a week. Now, it is at 10MB/day. Notice that it is a problem because it is RAM. I will add a MaxRetentionSec clause now. Setting to "1w" Huh, now "systemctl status systemd-journald.service" hangs. systemctl restart systemd-journald.service also hangs. Finished. Took a minute. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
04.03.2016 21:05, Carlos E. R. пишет:
Yes, I found that one, but seemed not to work.
That would be a bug.
Maybe... but I'm at 13.1.
"none" was present in Storage option from the very beginning and appeared in systemd v186. Which version in in 13.1? Does it recognize Storage=none but it does not work, or does it not understand Storage option at all?
Now I'm using:
[Journal] #CER #Storage=none SystemMaxUse=100M RuntimeMaxUse=50M MaxLevelStore=notice
...
Huh, now "systemctl status systemd-journald.service" hangs. systemctl restart systemd-journald.service also hangs. Finished. Took a minute.
Yes, on rotating disk journal query is indeed quite slow.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-03-05 08:19, Andrei Borzenkov wrote:
04.03.2016 21:05, Carlos E. R. пишет:
Yes, I found that one, but seemed not to work.
That would be a bug.
Maybe... but I'm at 13.1.
"none" was present in Storage option from the very beginning and appeared in systemd v186. Which version in in 13.1? Does it recognize Storage=none but it does not work, or does it not understand Storage option at all?
Version 208. I'm unsure at this moment what failed, but I had to try several options and restart the journal service several times till it obeyed and purged the log. It was deleted entirely, not trimmed to the 50 MB I requested.
...
Huh, now "systemctl status systemd-journald.service" hangs. systemctl restart systemd-journald.service also hangs. Finished. Took a minute.
Yes, on rotating disk journal query is indeed quite slow.
But it was not rotated, I still had the same size afterwards. The "disk" is tmpfs. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlbamSUACgkQja8UbcUWM1yNpQEAlUiZw2wZaj0gzt/VEQRjgdb4 8uxpvXQJrohlzzgpLrIA/3CjhA1dM5SVWNgcRGBocmux0I0DnVnTWrQHS2CaZR/k =R3tZ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-03-05 09:30, Carlos E. R. wrote:
On 2016-03-05 08:19, Andrei Borzenkov wrote:
04.03.2016 21:05, Carlos E. R. пишет:
Yes, I found that one, but seemed not to work.
That would be a bug.
Maybe... but I'm at 13.1.
"none" was present in Storage option from the very beginning and appeared in systemd v186. Which version in in 13.1? Does it recognize Storage=none but it does not work, or does it not understand Storage option at all?
Version 208. I'm unsure at this moment what failed, but I had to try several options and restart the journal service several times till it obeyed and purged the log. It was deleted entirely, not trimmed to the 50 MB I requested.
I have activated Storage=none in this laptop and restarted journal service. I see in journalctl output: Mar 05 09:49:53 minas-tirith.valinor systemd[1]: Stopping Journal Service... Mar 05 09:49:53 minas-tirith.valinor systemd-journal[254]: Journal stopped But: minas-tirith:~ # journalctl --disk-usage Journals take up 6.4M on disk. minas-tirith:~ # So it is probably working here, but not completely as I expected. It is possible that when I wrote that it did not work I was referring to the options I used limiting size: I specified 100 or 50 MB, yet the log had 300MB, in tmpfs, thus RAM. At the end it worked, though. The files were not purged to specified size, but deleted completely and log restarted. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlbanvQACgkQja8UbcUWM1weLQD8DaDOFYR7GdS/2u+cVVB+nRjl IboLAanjNkXpPWduln0A/01GfCXOA4CNdYZukdIRyKw/xrT3yprr8OVwxb4uivil =JJ/U -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
05.03.2016 11:55, Carlos E. R. пишет:
On 2016-03-05 09:30, Carlos E. R. wrote:
On 2016-03-05 08:19, Andrei Borzenkov wrote:
04.03.2016 21:05, Carlos E. R. пишет:
Yes, I found that one, but seemed not to work.
That would be a bug.
Maybe... but I'm at 13.1.
"none" was present in Storage option from the very beginning and appeared in systemd v186. Which version in in 13.1? Does it recognize Storage=none but it does not work, or does it not understand Storage option at all?
Version 208. I'm unsure at this moment what failed, but I had to try several options and restart the journal service several times till it obeyed and purged the log. It was deleted entirely, not trimmed to the 50 MB I requested.
I have activated Storage=none in this laptop and restarted journal service. I see in journalctl output:
Mar 05 09:49:53 minas-tirith.valinor systemd[1]: Stopping Journal Service... Mar 05 09:49:53 minas-tirith.valinor systemd-journal[254]: Journal stopped
But:
minas-tirith:~ # journalctl --disk-usage Journals take up 6.4M on disk. minas-tirith:~ #
So it is probably working here, but not completely as I expected.
I do not follow here - journald is stopped by works? :) Anyway - I would expect that with Storage=none journald does not care about any existing data at all. So whatever you have there will remain (forever) unless you delete data yourself.
It is possible that when I wrote that it did not work I was referring to the options I used limiting size: I specified 100 or 50 MB, yet the log had 300MB, in tmpfs, thus RAM. At the end it worked, though. The files were not purged to specified size, but deleted completely and log restarted.
On 2016-03-05 10:01, Andrei Borzenkov wrote:
05.03.2016 11:55, Carlos E. R. пишет:
I have activated Storage=none in this laptop and restarted journal service. I see in journalctl output:
Mar 05 09:49:53 minas-tirith.valinor systemd[1]: Stopping Journal Service... Mar 05 09:49:53 minas-tirith.valinor systemd-journal[254]: Journal stopped
But:
minas-tirith:~ # journalctl --disk-usage Journals take up 6.4M on disk. minas-tirith:~ #
So it is probably working here, but not completely as I expected.
I do not follow here - journald is stopped by works? :)
Yes, it apparently keeps the entries entered previous to stopping. Maybe after a reboot it disappears completely.
Anyway - I would expect that with Storage=none journald does not care about any existing data at all. So whatever you have there will remain (forever) unless you delete data yourself.
Yes, just my thought. You see, the main problem for me was that the non-persistent logs are written to disk in tmpfs (/run), up to 400MB (filled 300MB in six days), and for me having the logs in RAM is a waste of RAM that I can put to much better uses. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
You see, the main problem for me was that the non-persistent logs are written to disk in tmpfs (/run), up to 400MB (filled 300MB in six days), and for me having the logs in RAM is a waste of RAM that I can put to much better uses.
When it's not being used, i.e. most of the time, it's probably swapped out. -- Per Jessen, Zürich (2.6°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-05 12:03, Per Jessen wrote:
Carlos E. R. wrote:
You see, the main problem for me was that the non-persistent logs are written to disk in tmpfs (/run), up to 400MB (filled 300MB in six days), and for me having the logs in RAM is a waste of RAM that I can put to much better uses.
When it's not being used, i.e. most of the time, it's probably swapped out.
Maybe, maybe not. I have only 8 GiB of RAM, and it is using SWAP. Rigth now, almost 3 GiB. I prefer to avoid that extra load. (I'm trying to convert a video with openshot, and I saw a tumblerd process using 12 GiB of memory, had to kill it). -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Linda Walsh wrote:
Per Jessen wrote:
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2016-03-01 19:25, Billy.Zheng (zw963) wrote:
There is not exist a file named /var/log/messages (Like Slackware linux I used.) Of course it doesn't. openSUSE uses systemd, meaning that there is no syslog by default.
Actually, that was by choice because someone decided there was no need for a syslog daemon.
Wasn't that a side effect of someone deciding the default would be for SDto log as little as possible, and what it does log, it was to keep in transient storage so the log would be cleared each boot?
It was discussed quite a bit back in 2012. https://lists.opensuse.org/opensuse-factory/2012-09/msg00982.html It goes on well into October. In October 2012, Andreas Jaeger declared "And the stand-alone desktop is the primary target of openSUSE." https://lists.opensuse.org/opensuse-factory/2012-09/msg00986.html Of course, Andreas has moved on to pastures new and in our current do-ocracy, maybe I should just go and re-add syslog-ng to the default patterns. -- Per Jessen, Zürich (4.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am Sun, 28 Feb 2016 23:31:28 +0800 schrieb "Billy.Zheng(zw963)" <zw963@163.com>:
From logger command man:
logger - a shell command interface to the syslog(3) system log module
So, I want to use this command to write log to syslog.
following is a test:
$: echo 'some special log output' |logger
but, i could not found anything about my log in /var/log/.
thanks.
Enter in first user terminal: peter@raven:~> sudo journald -f to follow last log entries, then enter in second user terminal peter@raven:~> logger -i This is my message \(from user peter\) you have to escape bash characters with special meaning (here the brackets) and you will got in the journal this entry Feb 28 17:35:16 raven peter[21210]: This is my message (from user peter) -- Mit freundlichen Grüßen Kind Regards Peter Ragosch -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
This is not worked in openSUSE 42.1. there is not exist a `journald' command. This is not the answer i expected. thanks. Peter Ragosch writes:
Am Sun, 28 Feb 2016 23:31:28 +0800 schrieb "Billy.Zheng(zw963)" <zw963@163.com>:
From logger command man:
logger - a shell command interface to the syslog(3) system log module
So, I want to use this command to write log to syslog.
following is a test:
$: echo 'some special log output' |logger
but, i could not found anything about my log in /var/log/.
thanks.
Enter in first user terminal:
peter@raven:~> sudo journald -f
to follow last log entries, then enter in second user terminal
peter@raven:~> logger -i This is my message \(from user peter\)
you have to escape bash characters with special meaning (here the brackets)
and you will got in the journal this entry
Feb 28 17:35:16 raven peter[21210]: This is my message (from user peter)
-- Mit freundlichen Grüßen Kind Regards
Peter Ragosch
-- Geek, Rubyist, Emacser Homepage: http://zw963.github.io -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/01/2016 01:22 PM, Billy.Zheng (zw963) wrote:
This is not worked in openSUSE 42.1. there is not exist a `journald' command.
This is not the answer i expected.
Well you could google, but this is the answer I prefer: $ apropos journal journalctl (1) - Query the systemd journal journald.conf (5) - Journal service configuration file ljlatest (6x) - prints the most recent public posts on livejournal.com. named-journalprint (8) - print zone journal in human-readable form systemd-cat (1) - Connect a pipeline or program's output with the journal systemd-coredumpctl (1) - Retrieve coredumps from the journal systemd-journalctl (1) - Query the systemd journal systemd-journald (8) - Journal service systemd-journald.service (8) - Journal service systemd-journald.socket (8) - Journal service systemd.journal-fields (7) - Special journal fields -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hi, I have tried `journalctl -f' on SUSE 42.1, it seem like not work correctly for me, it seem like journalctl only display logger from terinal only if provide enough bytes content to logger command enough, Otherwise, journalctl display nothings. Is this expected behavior for journalctl ? Thanks. Peter Ragosch writes:
Am Sun, 28 Feb 2016 23:31:28 +0800 schrieb "Billy.Zheng(zw963)" <zw963@163.com>:
From logger command man:
logger - a shell command interface to the syslog(3) system log module
So, I want to use this command to write log to syslog.
following is a test:
$: echo 'some special log output' |logger
but, i could not found anything about my log in /var/log/.
thanks.
Enter in first user terminal:
peter@raven:~> sudo journald -f
to follow last log entries, then enter in second user terminal
peter@raven:~> logger -i This is my message \(from user peter\)
you have to escape bash characters with special meaning (here the brackets)
and you will got in the journal this entry
Feb 28 17:35:16 raven peter[21210]: This is my message (from user peter)
-- Mit freundlichen Grüßen Kind Regards
Peter Ragosch
-- Geek, Rubyist, Emacser Homepage: http://zw963.github.io -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/01/2016 01:49 PM, Billy.Zheng (zw963) wrote:
Hi, I have tried `journalctl -f' on SUSE 42.1, it seem like not work correctly for me, it seem like journalctl only display logger from terinal only if provide enough bytes content to logger command enough, Otherwise, journalctl display nothings.
Is this expected behavior for journalctl ?
The behaviour of the journalling mechanism depends on the configuration, which is very flexible. See the man page for journald.conf -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (20)
-
Andrei Borzenkov -
Anton Aylward -
Billy.Zheng -
Billy.Zheng(zw963)
-
Carlos E. R. -
Charles Philip Chan -
Dave Howorth -
Greg Freemyer -
Hans Witvliet -
James Knott -
jdd -
John Andersen -
Lew Wolfgang -
Linda Walsh -
Luuk -
Patrick Shanahan -
Per Jessen -
Peter Ragosch -
Ruediger Meier -
Xen