Add syslog APIs

[lambda-fairy]

The syslog interfaces are useful for writing daemons and such. It would be nice to have bindings to them.

[lambda-fairy]

I've published a preliminary set of bindings on my fork. There are a few issues with it so far:

• According to the Linux documentation, the ident argument to openlog() should have a static lifetime. I have modeled this using &'static CStr, which is correct but kind of fiddly.
• The interface of syslog() itself almost matches that of printf, except the former supports an extra code %m. I have no idea how to expose this safely. EDIT: printf supports this code as well.

Given these issues, I think we'd be better off just using a pure-Rust implementation instead.

[fiveop]

I have modeled this using &'static CStr, which is correct but kind of fiddly.

I think is the correct way to expose it safely.

The interface of syslog() itself almost matches that of printf, except the former supports an extra code %m. I have no idea how to expose this safely.

I have not encountered a good way of dealing with foreign functions with a variable number of arguments. When strings are involved, it only gets messier.

[lambda-fairy]

I have not encountered a good way of dealing with foreign functions with a variable number of arguments. When strings are involved, it only gets messier.

A syntax extension would work, but I think that would be overkill for this crate.

[tisonkun]

I think we'd be better off just using a pure-Rust implementation instead.

A binding is still helpful.

Today, I tried to write syslogs to macos, and encounter this issue python/cpython#91070, while directly call syslog(3) can work.

[tisonkun]

Or from the other perspective, how to implement syslog lib as in rust?

I made https://github.com/fast/fasyslog/ as a syslog client library. It works well for remote server and if the syslog daemon listens to a UNIX domain socket. But macos no longer works in either way so it's hard to make it work on macos.

[SteveLauC]

A binding is still helpful.

while directly call syslog(3) can work.

Considering that macOS bug, I agree it would be still helpful to bind them, if we can safely do so.

[tisonkun]

Ref -

• https://github.com/python/cpython/blob/v3.13.0/Modules/clinic/syslogmodule.c.h#L112
• https://github.com/python/cpython/blob/v3.13.0/Modules/syslogmodule.c
• https://docs.python.org/3/library/syslog.html

[tisonkun]

The interface of syslog() itself almost matches that of printf, except the former supports an extra code %m. I have no idea how to expose this safely. EDIT: printf supports this code as well.

I don't think we need to support the C formatter. Rust has its own format functions and we can also pass the formatted string without any other format signs.

[AlexTMjugador]

Given these issues, I think we'd be better off just using a pure-Rust implementation instead.

I figured I'd give my two cents about this idea, because how syslog works in detail seems to be an overall pretty obscure topic on the Internet and I did not see this point being stressed (enough? This is probably the only good summary I found about it): almost every Unix flavor under the sun I've looked into has a different implementation of the syslog functions.

Linux ones communicate with a Unix datagram socket at /dev/log, FreeBSD with a Unix datagram socket at /var/run/log, Solaris attempts several Unix stream sockets beginning with /var/log/syslog, newer MacOS versions don't even log to a socket anymore and instead forward logs to os_log (but only if you call the right versioned symbol)... The POSIX standard is as vague as it gets about actual implementation details.

So, if we are to rewrite it in Rust, we should be aware that are years of different conventions and use cases formed around practical implementations of this function we should care about, and getting it to work portably just right is thus more involved than the simplicity of the interface may suggest at a first glance.