Crystal: No syslog in stdlib

[stronny]

Please consider wrapping syslog.h which shouldn't be too hard.

[asterite]

It can also be provided as a shard. I see no need for it to be in the standard library, specially because it's tied to Linux.

[stronny]

It's not though, this is a POSIX call. Ruby has it for one. My belief is that this is a baseline functionality that should not need an external dependency.

[asterite]

The standard library should provide things that work in all OSes. This is clearly not mulyiplatform.

[stronny]

I think this is a wrong way to look at stdlib. Should we drop UNIXSocket then?

Only available on UNIX and UNIX-like operating systems.

[asterite]

I'm not sure anymore. I though Go's standard library was like that, but they do have Unix sockets and even a syslog package. So maybe it's fine if it is included in the standard library.

[Sija]

Yep, Ruby does too, and Python...

[jhass]

I think syslog is dying. Most supervisors or container solutions prefer you to just log to stdout, so they or the sysadmin can control where the log ends up via simple redirection on a per service basis. As such a syslog wrapper is fine as a shard if you want to fight the trend, but I wouldn't include it in stdlib as I wouldn't include a journald API or the like either.

[straight-shoota]

UNIX sockets are a part of the sockets API. They are platform specific, yes. But having a few platform specific implementations in a few places is fine. Extracting that into a shard would be to complicated and leave an incomplete API.

Now, syslog is a completely different feature. It could be in the stdlib but I don't see a reason for that. IMHO it is not a baseline library that needs to be supported by the stdlib. The long term goal is even to make the stdlib smaller and extract some parts to their own shards (see #5215).

Currently we're also still missing a sophisticated logging API that could make proper use of a syslog library (see #5874).

I don't see a point to continuously ask for syslog being added to the stdlib. Implementing it as a shard firat is probably even better because it can have shorter release cycles. Once it is mature enough there is still a possibility to discuss including it in stdlib.

[stronny]

I didn't find an issue talking about syslog. Although I did find a logging meta-discussion, I think it has little to do with this issue, as syslog itself has an extremely stable API already which can be provided as is.

Now let me address your points in detail.

I think syslog is dying.

This is clearly not the case. It's true that systemd wraps STDOUT and STDERR, however you can't inform it about the log levels this way. Sometimes it's acceptable, other times it's not, not even mentioning that systemd is not a universal constant.

as I wouldn't include a journald API or the like either

This is a false equvalence. I wouldn't propose a journald API in stdlib either.

The long term goal is even to make the stdlib smaller

I can see the value in this goal for the developers, however a rich standard library is never a bad thing for the user. Please take a look at C++ and nodejs as two examples of how not to organize an stdlib.

Implementing it as a shard firat is probably even better because it can have shorter release cycles.

What cycles? It will never change.

Finally, let me offer you a different perspective. I am not a programmer, I am a sysadmin with almost 20 years of experience. When I do write the code, I usually avoid external dependencies (shards in this case) if at all possible, mainly for the issues of trust and stability. Please also take into account that any program needs syscalls, and not providing a useful subset of the userland-kernel interaction, delegating it to your users is easy, but unhelpful. Right now there are no such shards in the index, and there is one that I can find that uses /dev/log, which is not what I want. Suppose there are several -- which one should I use?

Of course the decision to include something into stdlib or not has to be made each time with a bunch of conflicting criteria, however _standard_, _stable_ and _simple_ things should probably be included, in my opinion. FFS, you have an OAuth there and you are telling me syslog should be a shard?

[j8r]

@stronny For now the work about syslog remains to be done. When done, then, eventually, we will be able to talk about its integration in the stdlib, which also depends of the implementation.

[stronny]

I am not asking to do it immediately of course. This issue means that I personally think that crystal project could be improved some time in the future.

[asterite]

When I do write the code, I usually avoid external dependencies (shards in this case) if at all possible, mainly for the issues of trust and stability.

This is a good reason. However, if you can't find someone how truly understands syslog and knows how to build a good wrapper in Crystal for it, I doubt you'll get trust and stability.

For example, I added the initial bindings to readline just because Ruby provides them. I never really used readline, I just tried things out as I used them. It turns out the bindings are lacking in many ways and I don't have the knowledge or time to fix them. In the end, it would have been better if someone wrote a shard for that, someone that truly understands the library and has time and knowledge to develop it.

If you are an expert in syslog, I recommend you start that shard :-)

[straight-shoota]

It will never change.

I doubt you (or anyone else, even someone very experienced with both Crystal and syslog) could spit out an outstanding Crystal wrapper - without any pieces the would need some kind of improvement - right from the start. There will inevitably be changes. If this completely new feature is developed in a shard (which is IMHO the right place for it), you can still suggest to add it to stdlib once it is mature.

Having additional dependencies is a thing I always try to avoid, as well. But you can't have all libraries in stdlib. That would make just make it a never-evolving monolith.

Obviously there are issues with an open eco system that shards might be abandoned etc. But honestly, if nobody bothers maintaining a shard, would it be a good thing to drag such library with us in stdlib? I don't think so.

[ysbaddaden]

I'd like someone to implement this as a Shard first —preferably in pure Crystal, not wrapping an external library— then maybe move it to stdlib. It would be fantastic as an alternative backend to Logger.

Now a problem is which syslog? There are different versions, yet only the oldest BSD seems ubiquitous.

[stronny]

Guys, have you seen the man page at all? man 3 syslog -- there is nothing there besides 3 voids and a bunch of #defined enums. What expertise are you talking about?

The only problem I see is platform-specificity, so it may be the case that different compile targets may require different values in those enums and I don't know the solution to that besides some external tool that converts headers to .cr files at build time.

How do other languages do that anyway?

preferably in pure Crystal

the whole point is to call the underlying libc fuction, how do you do that in pure crystal?

[chris-huxtable]

OpenBSD pretty much exclusively uses syslog (easier/safer in chroot and priv-sep). They even change the defaults in ports to prefer it.

I have a poor quality shard in use currently. When I eventually get around to cleaning it up I will ISC it. I don't think it can be 'pure' crystal. Mine currently uses the c calls but I hope to change it to the reentrant versions eventually.

[ysbaddaden]

@stronny please keep your temper. If it's so damn easy, please create your own shard, thanks.

BTW: other languages merely implement a syslog backend for their standard logger, which is basically "send a standardized text message to an UDP socket". See RFC 3164 I really don't see the need for calling syslog_r.

Closing for now. Please create a shard.

[ysbaddaden]

Here is a gist I wrote some weeks ago. It took me around 30 minutes, with half of them wondering why RFC 5424 didn't work and reverting to RFC 3164 that did work (linux ubuntu trusty).

https://gist.github.com/ysbaddaden/c5ec563de87c517c9326e83587c25959

[stronny]

please create your own shard, thanks

You won't go far with this attitude guys. Just saying.

[asterite]

@stronny the tone was a bit high, it's true.

However, it seems no one here is willing to write a syslog implementation for Crystal. I mean, now that I saw that Ruby, Python and Go all have this functionality, I think it might be good to include such thing in the standard library. How to do it is not trivial: all interfaces to the library are very different in Ruby, Python and Go, so it's not just wrapping a bunch of functions, there's a design process in between, and a discussion must follow.

Then, this is an open source project where time and effort is limited. It seems no one here has the time or will to tackle this particular thing, and that's why we all suggest you or someone else create a shard for it. It's development will go much faster than here.

[stronny]

Right. Please accept my apologes if the comment came out as shouting, that was not my intention.

I have no objections to an intermediate shard, in fact I probably agree with your reasoning. This issue however was not about the process, rather the result.

After a bit of investigation I came to realize that handling /dev/log directly may be okay, however there are two issues with this approach:

1. syslog(3) has more functionality than just sending a datagram: the additional functions are in the options (LOG_PID et al.) Replicating this may be work spent unwisely.
2. the path of the socket is platform-dependent.

[RX14]

I see absolutely no issue in using the syslog syscalls. Re-implementing something in libc is unnecessary. Binding the libc call is fine, and doesn't add any extra dependency at all.

[chris-huxtable]

Here is the shard I mentioned earlier:

• syslog.cr

Comments/Issues/PR's welcome.
*Currently only tested on macOS