the biggest problem is if one of these operations ever takes over 24h you'll end up with multiple scans overlapping and sharing CPU/IO load, slowing them down, spiralling into resource exhaustion.
these can be turned off system-wide by setting the security_status_chksetuid_enable and security_status_neggrpperm_enable rc.conf vars to NO in the Tunables tab, or you can manually add those overrides to /etc/periodic.conf on a per-jail basis if you just want to turn this off for specific jails.
Comments
Displaying 0 of 3 comments
Graham Sutherland / Polynomial
In response to this postthe middlewared issue I mentioned earlier in the thread is just a symptom of these scans eating up resources. when the scans aren't running the middlewared process uses a lot less CPU time, so I can only guess that there's some spinlock contention or something causing problems (which would make sense because the python stuff is using multiprocessing)
Likes: 0
Replies: 0
Boosts: 0
fraggLe!
In response to this post@gsuberland Hmm, would that actually happen if the system has a reasonable amount of RAM? It should be dirt cheap to keep the dents in ARC (neither of those scripts look at file contents do they?) and an ARC hit should be pretty much free.
I suppose it would matter how much disk activity the system and/or ARC is seeing in that 24h period? 🤔
@fwaggle I've got 96GB in this machine, plus NVMe L2ARC, and it still slams CPU/IO.
by Graham Sutherland / Polynomial ;
Mentions: @gsuberland@chaos.social
Likes: 0
Replies: 1
Boosts: 0
Joel Michael
In response to this post@gsuberland lol, “once per day” scripts that take more than one day to run but don’t gate themselves from multiple copies of itself running
@jpm I wish systems like cron had built in features to trigger alerts when a prior task has not finished by the time it runs again, instead of relying on individual reimplementations.
by Graham Sutherland / Polynomial ;
Mentions: @gsuberland@chaos.social
Likes: 0
Replies: 1
Boosts: 0