<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-05-04 3:16 GMT+02:00 Lennart Poettering <span dir="ltr"><<a href="mailto:lennart@poettering.net" target="_blank">lennart@poettering.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, 02.05.15 15:12, Ludovic Gasc (<a href="mailto:gmludo@gmail.com">gmludo@gmail.com</a>) wrote:<br>
<br>
>    2. We use heavily AsyncIO module to have async pattern in Python,<br>
<span class="">>    especially for I/O: <a href="https://docs.python.org/3/library/asyncio.html" target="_blank">https://docs.python.org/3/library/asyncio.html</a><br>
>    In the source code of python-systemd, I've seen that you use a C glue to<br>
>    interact with journald, but I don't understand what's the communication<br>
>    between my Python daemon process and journald: unix sockets ? Other<br>
>    mechanism ? Depends on the mechanism, it should be have an impact for us.<br>
<br>
</span>The communication is via an AF_UNIX/SOCK_DGRAM socket in the file<br>
system.<br>
<br>
I am very sure that logging should not be asynchronous non-blocking<br>
IO. It's about reliably getting out log messages at the right times,<br>
and that's a property you lose if you enqueue logs non-blocking.<br>
<br>
I don't think that's a good idea in any programming language to log<br>
asynchronously. I mean, there's a reason why libc syslog() is<br>
blocking too.<br></blockquote><div><br></div><div>Yes, you're right.</div><div>The only way I see to send asynchronously messages and keep the order is to add a precise timestamp in the message.</div><div>But the "time" you need to access to the clock and push that on the wire, I'm not sure you'll be more efficient, without to count the cost of the effort to implement that in journald.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If you are afraid of blocking logging, then make sure to use large<br>
socket buffers. the journal client library and journald will try to<br>
use very large buffers, but this doesn't always work if the client is<br>
unprivileged. Also you might have to increase the number of datagrams<br>
that may be queued with /proc/sys/net/unix/max_dgram_qlen<br></blockquote><div><br></div><div>Thanks for the tip, I didn't know that.</div><div>Ok, it seems to be a more pragmatic and efficient way, I'll do that and validate with a benchmark to be sure.</div><div><br></div><div>BTW, FYI, I don't find a solution to install python-systemd in a pyvenv.</div><div>Finally, I've "reverse-engineered" journald "protocol" with socat.</div><div>The protocol is so simple that I've written a tiny library written in pure Python to be easy to install.</div><div><br></div><div>I'll opensource that soon.</div><div><br></div><div>Thanks for your help.</div><div><br></div><div>Regards.</div></div></div></div>