fanout
fanout copied to clipboard
travisghansen
Systemd unit file
Hi,
I am package fanout as rpm for CentOS 7. so far I have just used the init script. But I guess it is time to use systemd unit files.
Did you create one already I can use?
Are you interested in a pull request for the rpm spec-file?
Sure if you could provide some rpm based packaging that would be great!
I will try to provide the systemd unit file and a rpm spec file.
How do you prefer the additional files? Shall I create a pull-request with those?
That would be great yeah. Out of curiosity can you share what you're using the server for? Its original use case was pretty small so I'm interested in knowing how it's getting used today..
I use it at the moment mainly with SparkleShare (https://www.sparkleshare.org/).
I was planning to use it to communicate fail2ban events to cluster nodes, but without any authentication or basic encryption, I am not sure if it is the best solution.
All in all, I like the simplicity of it. No fancy bells and whistles. :-)
Yeah ok I was originally working with the sparkleshare team so that makes sense.
Yeah I was working with hbons on irc back in the day...coded a few things in the client as well..
Wow, interesting.
Progress ... I have a first build with systemd unit file as el7 rpm and init script as el6 rpm.
I will try to add it in a "rpm" directory and create a pull request. Next would be SELinux police for it.
I had some fun with ulimits and systemd.
Can you shortly explain how the logic behind the --client-limit parameter works? It seems as under some conditions, fanout tries to manipulate the ulimit on its own.
It's a bit tricky to squeeze that into a unit file when systemd is handling the user under which the daemon is running.
It's been a looooong time :)
It looks like the extent of the integration is here: https://github.com/travisghansen/fanout/blob/master/fanout.c#L461
Looks like the extent appears to be 1 function call:
setrlimit (RLIMIT_NOFILE,&i_rlimit)
Hmmm. So you calculate the required file descriptors and compare it to the currently set limit. And in case the Current Limit is not big enough, you just set it. Right?
That would definitely explain what I observed. :-)
Sent with GitHawk
Yeah, if you set --client-limit it adds a few extra file descriptors to the limit and ensures the limit is high enough to handle the desired number of clients.
For example, if you only want to allow 5000 clients it will set the limit to 5000 + <a few extras> I don't recall exactly how the extras are added up based on features etc.
Thanks for the info. I found the section in the source and it seems that you calculate a few extra file descriptors and additional ones depending on the activated feature. :) Sounds really good.
I desided to set the limit for nofile in systemd unit file to "unlimit" as it seems a bit complicated to make it configureable. Additionally I set the defaults value --client-limit to 1024 for fanout.
I did that because I create a user fanout so the fanout daemon is not permitted to set the ulimit values. That would have caused the daemon to fail. If you know of an easy way to set the LIMIT_NOFILE in a configureable way, ... please let me know.
Currently testing the rpm package and the daemon start and stop behaviour. I hope to be able to provide the rpm specific files soon as pull-request.
Yeah this one is tricky I'd guess.
Are you using LimitNOFILE= in the unit file? If so the value should be infinity no?
I'm not sure if you can set that value to a variable via an environment file. Then let fanout sysconfig file manage both via the same variable..
I tried to set an environment variable via the enviriment file (/etc/default/fanout) and use it with LimitNOFILE but it doesn't use the variable.