Forums

Resolved
0 votes
clearsyncd seems to be a bit of a resource hog - have caught it running 3 out of 4 CPUs close to 100% each at times...

Now on one of the systems here clearsyncd appears to have gone into some sort of a loop running one CPU at nearly 100% continuously... Disabled it using systemctl - but "systemctl stop clearsync.service" just hung and was unable to stop the service. Resorted to finding its pid and using "kill -9 nnnn".

As is too often the case for ClearOS programs - no "man" pages or useful documentation to be found on this site. Ran it in a terminal using the debug option (-d) and seemed to repeat a set sequence of stuff over and over again. Most noticeable were constant errors regarding missing .conf files for optional clearos apps which are not installed - dumb... Nothing else stood out to me...

At the moment have left it disabled - what are the longer term consequences of this action?
Wednesday, October 03 2018, 03:54 AM
Share this post:
Responses (6)
  • Accepted Answer

    Wednesday, October 03 2018, 07:23 AM - #Permalink
    Resolved
    0 votes
    Clearsyncd seems to watch for all sorts of changes and then kicks of related processes. I think if any of the networking ifcfg files a network restart is kicked off. The same sort of think happens with samba. Have a look in /etc/clearsync.d to find the monitors and which follow-on events are kicked off. If it is running at a high CPU load then something has gone wrong. If you kill it without disabling the systemctl autostart, you'll find servicewatch kicks off the process again.

    [edit]
    Disabling it may mess up some app updates as the follow-on events are suppressed.
    [/edit]
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, October 03 2018, 08:45 AM - #Permalink
    Resolved
    0 votes
    Thanks Nick - that is the sort of conclusion I had come to - but was looking for some in-depth documentation to make debugging easier. Had seen the /etc/clearsync.d files and had already formulated one debugging plan that I didn't want to action :( The /var/log/clearsync.log and /var/log/clearsyncd.log contained nothing but the usual messages and were of no help with my issue.

    So there was nothing for it but to enact my plan to find if one of these files in /etc/clearsync.d was responsible for kicking off the loop. Mr Murphy was in attendance and found it was the second last file of my testing that was the culprit... i.e. /etc/clearsync.d/csplugin-events.conf.

    Looking at the file it seems to be responsible for creating the entries in the Webconfig "Events and Notifications" page. That's something never used here - so will not miss it at all... Checked the size of every single log in /var/log and sub-directories and there is nothing that is not the usual size so am at a loss why it is a problem. That file compares OK using "cmp" with the same file on another system... Not willing to waste any more time. Annoys me that virtually all the problems on my systems are in stuff developed by Clear - especially openldap - and these have by far the poorest documentation or none at all. The vanilla parts derived from CentOS are rock solid...
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, October 03 2018, 09:24 AM - #Permalink
    Resolved
    1 votes
    Interesting find and you've triggered a memory. A long while back I had issues with slow logging into the webconfig. Ben did a little diagnostics and diagnosed a corrupt /var/lib/csplugin-events/events.db. He suggested the following:
    systemctl stop clearsync.service
    rm -f /var/lib/csplugin-events/events.db
    systemctl start clearsync.service
    This sorted out the slow logins and because it has no obvious side-effects, I've stuck it in a cron.monthly job.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, October 03 2018, 10:27 AM - #Permalink
    Resolved
    0 votes
    Thanks - Well, that turned out to be my problem as well. Annoying this is a known problem that hasn't been fixed. My solution will be a little different, a weekly cron job - on all systems...
    # rm -f /etc/clearsync.d/csplugin-events.conf

    Still maintain clearsyncd is a resource hog. On all systems can see it occasionally spiking to near 100%. So took the time and wrote a little script to check memory and CPU usage on another system (not the one that had the problem)... Not impressed at all... this is for clearsyncd when CPU usage > 0. All this for the occasional time a config file is changed, event to be logged etc? Suppose could extend the time the script runs to capture the near 100% usage - but it is already showing its true colours without doing that... seems to run approxiamately every 5 seconds...

    Wed 03 Oct 2018 08:10:21 PM AEST 20:10:21 Memory 0.3 % - CPU 4.3 %
    Wed 03 Oct 2018 08:10:24 PM AEST 20:10:24 Memory 0.3 % - CPU 15.8 %
    Wed 03 Oct 2018 08:10:29 PM AEST 20:10:29 Memory 0.3 % - CPU 15.8 %
    Wed 03 Oct 2018 08:10:34 PM AEST 20:10:34 Memory 0.3 % - CPU 15.8 %
    Wed 03 Oct 2018 08:10:39 PM AEST 20:10:39 Memory 0.3 % - CPU 21.1 %
    Wed 03 Oct 2018 08:10:45 PM AEST 20:10:45 Memory 0.3 % - CPU 5.3 %
    Wed 03 Oct 2018 08:10:49 PM AEST 20:10:49 Memory 0.3 % - CPU 15.8 %
    Wed 03 Oct 2018 08:10:57 PM AEST 20:10:57 Memory 0.3 % - CPU 10.5 %
    Wed 03 Oct 2018 08:10:59 PM AEST 20:10:59 Memory 0.3 % - CPU 5.9 %
    Wed 03 Oct 2018 08:11:04 PM AEST 20:11:04 Memory 0.3 % - CPU 10.5 %
    Wed 03 Oct 2018 08:11:05 PM AEST 20:11:05 Memory 0.3 % - CPU 5.3 %
    Wed 03 Oct 2018 08:11:11 PM AEST 20:11:11 Memory 0.3 % - CPU 5.3 %
    Wed 03 Oct 2018 08:11:14 PM AEST 20:11:14 Memory 0.3 % - CPU 10.5 %
    Wed 03 Oct 2018 08:11:19 PM AEST 20:11:19 Memory 0.3 % - CPU 15.8 %
    The reply is currently minimized Show
  • Accepted Answer

    Monday, May 13 2019, 02:26 PM - #Permalink
    Resolved
    0 votes
    A bit of a bump, but I've been looking into clearsync for another reason.

    One thing it does, which is very useful, is a load of file watches and then fires of actions in the case of a file addition, deletion or change. All the things it watches are in /etc/clearsync.d/. As an example, /etc/clearsync.d/filewatch-firewall.conf watches for changes in ifcfg files and various firewall files and a few other bits then fires off a firewall restart. This is how changes to the firewall through the webconfig are actually implemented. The webconfig writes the relevant file then the clearsync restarts the firewall with then wipes all the old rules and inserts the new ones.

    Apart from doing direct commands, it can also fire off commands with /usr/sbin/syncaction and /usr/sbin/trigger which work in different ways. You'd need to follow the logic through.

    It seems to me that clearsync is necessary for quite a lot of the underlying ClearOS lue to work. It does not just look after the events database.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 14 2019, 12:00 AM - #Permalink
    Resolved
    0 votes
    Clearsync annoys me as well from time to time. There are better ways of doing some of the things that clearsync covers and those will be implemented in some of changes that will be going into effect later this year. For example, systemctl is capable of managing some event-related items that need to be better leveraged.
    The reply is currently minimized Show
Your Reply