Arch Linux User Repository

I am unaware of any log levels, but the thing is that logging to a file is the same as logging to the journal when it comes to disk usage. Either way, the partition with the log is going to fill up. The difference is that one method consolidates the logs in an easy-to-filter central location that conforms to the standard expected on systemd-based systems and the other one doesn't. In either case, unless you're running a service with the equivalent of a verbose or debug flag, a large number of log messages usually means that the sysadmin should be fixing a problem, not that the service is being overly verbose. So don't worry about big logs being a mere possibility; worry about your local configuration when they actually present themselves.

I did not find any way how to configure log level for btsync. If you know how to do this - please share your knowledge. Otherwise I think the approach with logging to file is more correct and safe, at least heavy btsync users can use it without cleaning up the journal time-to-time.

I deleted my comment earlier re: the --log option because I realized that it wasn't the right way to do it. An inherent part of systemd is the journal, so even though it may be to @dam5h's chagrin, the log really should end up accessible via journalctl, making it consistent with all other systemd services. I personally would like to see a reversion to the previous unit file and would instead point @dam5h to btsync's support options (or just Google it; possible issues include firewalls with DDoS protection and corrupt databases).

Ok, I just uploaded new version with logging problem solved. So, basically now systemd starts btsync in daemon mode with type forking. In this case not logs are going to journal, all is logged to sync.log. Please test and report your feedback.

Actually, --log <file> option for --nodaemon mode is not working for some reason, can anybody confirm this?

OK, I found an easy way to completely disable output from btsync to journal. To achieve this, just put StandardOutput=null line in [Service] section of the systemd unit you are using and restart the service. After this output will be redirected to /dev/null. Better approach will be to copy systemd unit to the /etc/systemd/{system or user depending of unit you are using} and make change there. Now I am looking for the option to redirect it to the file...

No, I can't see any reason why using the user service instead would fix your problem. What I meant was that you can override /usr/lib service files with ones in /etc or (if it's a user service) ~/.config . Then you can experiment with it and see if you manage to solve it.

Yes, that's how I start it. So I should use the user based approach via systemctl? It's odd to me that would fix the logging level issue but I'll try it.

@dam5h You mean the one running as user btsync (# systemctl start btsync)? Then override with a service file at /etc/systemd/system/btsync.service instead. :)