On 07/03/2015 05:19 PM, Richard Weinberger wrote:
Am 03.07.2015 um 17:09 schrieb Marcin Niesluchowski:
Why can't you just make sure that your target has a working
syslogd/rsyslogd/journald/whatever?
All can be done perfectly fine in userspace.
* Message credibility: Lets imagine simple service which collects logs via unix sockets. There is no reliable way of identifying logging process. getsockopt() with SO_PEERCRED
option would give pid form cred structure, but according to manual it may not be of actual logging process:
"The returned credentials are those that were in effect at the time of the call to connect(2) or socketpair(2)."
- select(7)
This interface can be improved. Should be easy.
What kind of improvement do you have in mind?
* Early userspace tool: Helpful especially for embeded systems.
This is what we do already. In early user space spawn your logger as early as possible.
"embedded Linux is special" is not an excuse btw. ;)
I would say "embedded Linux is real use case"instead of "special". What
I meant that it does only require one ioctl and no additional resources
are needed.
* Reliability: Userspace service may be killed due to out of memory (OOM). This is kernel cyclic buffer, which size can be specified differently according to situation.
This is what we have /proc/<pid>/oom_adj and /proc/<pid>/oom_score_adj for.
You are right, but additional resources and complexity is required.
* Possibility of using it with pstore: This code could be extended to log additional buffers to persistent storage same way main (kmsg) log buffer is.
pstorefs and friends?
pstore filesystem is used to access already stored kernel data (e.g.
kmsg buffer). But does not provide mechanism of storing userspace memory.
* Use case of attaching file descriptor to stdout/stderr: Especially in early userspace.
You can redirect these also in userspace.
True for that, but as I said in my first argument there is no
possibility of logging process identification in case of sockets.
* Performance: Those services mentioned by You are weeker solutions in that case. Especially systemd-journald is much too heavy soulution.
Do you have numbers? I agree systemd-journald is heavy wight. But it is by far not the only logging daemon we have...
I compared write operations on kmsg buffervia write/read operations on
socketon SOCK_STREAM socket and sendmsg/recv on SOCK_DGRAM socket.
Compared toSOCK_STREAM socket it was about 39% slowerbut compared
toSOCK_DGRAM socket it was about 326% faster.syslogfor example uses
SOCK_DGRAM sockets.In all cases there were 2^20 (1048576) write/sendmsg
operations of 2^8 (256) bytes.
Best Regards,
Marcin Niesluchowski
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
