Systemd unit file about fanout HOT 17 OPEN

Yeah ok I was originally working with the sparkleshare team so that makes sense.

from fanout.

Sure if you could provide some rpm based packaging that would be great!

from fanout.

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?

from fanout.

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..

from fanout.

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. :-)

from fanout.

I am currently hosting the fanout Server for them.

from fanout.

Yeah I was working with hbons on irc back in the day...coded a few things in the client as well..

from fanout.

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.

from fanout.

Very good!

from fanout.

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.

from fanout.

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)

from fanout.

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}

from fanout.

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.

from fanout.

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.

from fanout.

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..

from fanout.

Yes LimitNOFILE, and sorry, yes I meant infinity.

_{Sent with GitHawk}

from fanout.

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.

from fanout.