How to stop syslog-ng at boot

[dpsguard]

Hello all,

In order to trying to reduce the cpu random peaks, I have done few things. Last thing I want to do is to stop syslog service from starting up at boot time. I have tried various things including adding in the conf file

/etc/rc.conf

syslog_ng_enable="NO"


and

sysrc syslog_ng_enable=”NO”

but on reboot, the service still runs.

I don't need logs to be sent to a syslog for my simple Guest Wi-fi setup, so will like to stop it for good.

There seems to be some other conf file that overrides this.

Can someone please help me in getting rid of this? I can try to even remove the syslog-ng package, but it might have some side effects on GUI and may get reinstalled on next update.

Thanks

[franco]

At the moment it's neither recommended nor possible to disable the system logging daemon.

That being said you can try it by editing the following file

/usr/local/opnsense/service/templates/OPNsense/Syslog/rc.conf.d

change

syslog_ng_enable="YES"

to

syslog_ng_enable="NO"

and reboot.

This modification will NOT survive an update.

Alternatively, go to System: Settings: Logging and check "Disable writing log files to the local disk" to see if that helps with your CPU peaks. It would be a more viable solution (at the cost of not having any logging still).


Cheers,
Franco

[dpsguard]

Thank you so much @franco. I will test this later in the evening and report back.

Appreciate great work you and team are doing.

[dpsguard]

Hi @franco,

Thank you so much for giving me a working solution.

Although few other measures that I had implemented earlier, significantly reduced the fatal impact of sharp and frequent CPU surges (I only have few posts, so all that is documented in those), this last one was still troubling me.

I was getting on an average of 1 surge of about 25% (with normal consumption of close to 0% CPU), on average of one per 2 minutes, with light load.

I then stopped syslog-ng (and your method worked to stop the running of the syslog-ng service at boot) and I then got the frequency of these peaks to lower to one-third. Though amplitude remained same at about 25% average. The reason I wanted to remove or reduce the amplitude and frequency of these peaks was that these had an impact on real-time traffic wherein picture / videos will get pixelated or pause or stutter , and any voice call will lose some word or so when the peak will strike. Looks like with reduction in frequency of peaks, situation is very acceptable.

I then followed your second advice (while still kept syslog-ng shut), and this did not improve anything further as for as CPU surges go, but I could sure see almost no IOPS now, so that is good as well. I am thus going to keep both in place.

I am happy and I am going to donate another $100 this Friday, when I will have some cash available.  And I will donate another $100 in two weeks for sure.

Franco, would you recommend lowering the tcp session timeouts for the hung up sessions to be cleared soon or is there already a script that runs to achieve that?

Thanks again and keep doing good work.

[franco]

Very kind, thank you! <3

> Franco, would you recommend lowering the tcp session timeouts for the hung up sessions to be cleared soon or is there already a script that runs to achieve that?

I'd try tweaking Firewall: Settings: Advanced: Firewall Optimization... "aggressive" seems to be what you want.


Cheers,
Franco

[dpsguard]

Hi @franco.

I already have aggressive settings for optimization. I was looking under firewall / diagnostics / sessions / states tables and it had long hanging sessions and I thought maybe tcp close / wait etc could be tweaked downward in a configuration file. I assume then I can ignore the table and aggressive script takes care of killing the hung sessions periodically.

Thanks. And money will be in bank tomorrow evening my time and I will do my part.

[dpsguard]

Another thing just noticed is that before changing the logging away from disk, it must then be logging to RAM. And before I had 4% RAM used, now it is stuck at 18% with  1.2GB used by ARC. I dont much understand ARC or ZFS, but not sure if this cached memory is an issue or will become an issue. If RAM is still idle, then no issues, but I will like to know if there is a way to periodically delete this cache.

[franco]

Hi,

There is no discernible "script" here but the effect is the same. I know there are some more numbers you could set with "set timeout" directive in pf.conf(4) but they have never been added to the GUI because in reality they are not needed and/or nobody has the time to sit down and tweak these values (too many different types of connections exist in every network anyway).

It's still logging, but it shouldn't require GB's worth of memory. It's only there to accept messages and then discard them. Check the sylog-ng process memory use in particular.

With ZFS RAM usage is always higher or fluctuating BTW.


Cheers,
Franco

[dpsguard]

Thanks again @franco. Just did my part by donating my $105 and some change via PayPal transaction ID 4W1450995K203081D

I agree to not complicate and let aggressive option do its work.

As to ZFS and RAM usage, with ZFS enabled, but logs written to disk, I have almost fixed 135MB of RAM used for ARC. When I disable logs writing to disk (so it starts writing to memory), then I see close to 1.2GB of RAM used as ARC cache. I was not sure if this 1.2GB  (with little traffic) will remain about the same or it will grow too large over time. As long as ARC is not a consumed memory, and is available for other things when needed, I will be okay.

Thanks again and keep doing great work. I will donate another about $100 in two weeks.