My system seems to have updated this morning from 02:10 - Yum Log
Since than i am getting a HIGH volume of log files - messages - Started Session c4476 of user root - about 36 entries every second??
Apr 6 17:09:48 ZodiacTech systemd: Started Session c789 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c790 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c791 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c792 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c793 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c794 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c795 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c796 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c797 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c798 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c799 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c800 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c801 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c802 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c803 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c804 of user root
Did a "HARD" reset so that i can get in and copy from /var/log/messages
It seems that my system is getting overwhelmed, so bad that i can't login even via ssh anymore.
What i did see before i could not get in anymore was a higher memory usage by clamd
Any idea where i can look to find out what is causing this?
Since than i am getting a HIGH volume of log files - messages - Started Session c4476 of user root - about 36 entries every second??
Apr 6 17:09:48 ZodiacTech systemd: Started Session c789 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c790 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c791 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c792 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c793 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c794 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c795 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c796 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c797 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c798 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c799 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c800 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c801 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c802 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c803 of user root.
Apr 6 17:09:48 ZodiacTech systemd: Started Session c804 of user root
Did a "HARD" reset so that i can get in and copy from /var/log/messages
It seems that my system is getting overwhelmed, so bad that i can't login even via ssh anymore.
What i did see before i could not get in anymore was a higher memory usage by clamd
Any idea where i can look to find out what is causing this?
In Water Cooler
Share this post:
Responses (72)
-
Accepted Answer
-
Accepted Answer
Ah ha - I think the problem is how I am looking at the logs. The "sudo" messages are indeed not going into /var/log/messages. However they do show up in "journalctl -xe", and "journalctl -f" which what I use to keep an eye on logs. I used to use "tail -f /var/log/messages" though I think that got deprecated in favour of journalctl, which is indeed more flexible in most cases. I'll have a dig as there is probably a way to apply the same kind of filter there.
Apologies for my lack of understanding of how logging and viewing of logs works. -
Accepted Answer
I don't understand, then, what is going wrong. If you restart rsyslog are there any error messages (Don't worry about ~ being deprecated, but you can change each instance to "stop" without the quotes if you want).
The rsyslog filter will not stop the messages from showing in "journalctl -xe" but should stop anything from appearing in the logs.
There is one more thing you could try. In /etc/pam.d/system-auth-ac change:
tosession [success=1 default=ignore] pam_succeed_if.so service in sudo quiet uid = 0 ruser = webconfig
I am not sure what else this affects.session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session [success=1 default=ignore] pam_succeed_if.so service in sudo quiet uid = 0 ruser = webconfig
This is not a file maintained by ClearOS so could get stomped on with an updated. I't prefer to track down why the rsyslog filter is not working. -
Accepted Answer
Hi Nick,
I have the correct version of the system-base package and the /etc/rsyslog.d/system-base.conf file exists - datestamp Apr-12-2019 15:26, bytecount 290, and content appears to do exactly what is required. I have rebooted several times in last few days (though had not rebooted prior to that for about 4 months) and also restarted rsyslog service just now. Still makes no difference so not clear what is going wrong...
Thanks,
Andrew -
Accepted Answer
Those should be filtered out by an rsyslog filter, /etc/rsyslog.d/system-base.conf which is provided by system-base-7.6.5-1.v7, which you have. Can you check you have the file? If you do and have not rebooted recently, please reboot to get the latest kernel into operation (the kernel has nothing to do with the issue but it is a security release). Obviously this will also restart the rsyslog daemon. -
Accepted Answer
This is the sort of log entry I get in /var/log/messages (from journalctl -f):
Not identical to all the other log entries that have been reported, but definitely generated by any kind of root access, especially via the webconsole.Jul 27 21:41:02 gateway.wasielewski sudo[3535]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jul 27 21:41:02 gateway.wasielewski sudo[3535]: pam_unix(sudo:session): session closed for user root
Jul 27 21:41:02 gateway.wasielewski sudo[3538]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jul 27 21:41:02 gateway.wasielewski sudo[3538]: pam_unix(sudo:session): session closed for user root
Jul 27 21:41:02 gateway.wasielewski sudo[3541]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jul 27 21:41:02 gateway.wasielewski sudo[3541]: pam_unix(sudo:session): session closed for user root
-
Accepted Answer
-
Accepted Answer
Hi Nick,
The IP Settings screen certainly does generate a lot of events... There are no .rpmnew files, and none of the three config files have been edited. I was under the impression from the message trail that the underlying cause had been addressed by package updates 2-3 months back and the only issue was whether these had been applied successfully or not. My system is updated automatically and all packages are currently up to date.
Let me know if there is anything else in config I can check or any other testign I can do.
Andrew -
Accepted Answer
@ Andrew,
While this is going on, please do not sit in the Webconfig IP Settings screen as it will massively ramp up the number of events and could bring your system to its knees.
Please can you check if you have a /etc/clearos/events.d/20-user-auth.conf.rpmnew? If so, you've probably made an edit to the /etc/clearos/events.d/20-user-auth.conf and you now need to rationalise the two files (easiest is to move the /etc/clearos/events.d/20-user-auth.conf out of the way and rename the rpmnew file), then, in slow time, work out any edits you made to the original file and decide if you want them in the new file. Then reset the events with:systemctl stop clearsync.service
rm -f /var/lib/csplugin-events/events.db
systemctl start clearsync.service
-
Accepted Answer
Andrew Wasielewski wrote:
I'm still getting the same issue - syslog is swamped by large numbers of "sudo" events, mostly coming from webconfig so the rate of entries depends on what is happening there. Not enough to affect system performance but makes it very hard to spot "real" events. Seems to have been going on for some time though is causing annoyance now as it is making syslog difficult to use for other purposes.
System is fully updated as far as I am aware and no custom edits made to any of the config files mentioned above. Specifically, the three main packages involved are at or above the level required:
[code type="markup"]Installed Packages
app-base.noarch 1:2.7.4-1.v7
csplugin-events.x86_64 1.2-3.v7
system-base.x86_64 7.6.5-1.v7
- File /etc/systemd/system.conf has "LogLevel=info" but that line (like all in section [Manager]) is commented out.
- File /etc/systemd/system.conf.d/clearos-base.conf contains a single entry "LogLevel=notice"
- File /etc/clearos/events.d/20-user-auth.conf hasn't been edited in any way, and is dated 09-Apr-2019.
I tried the command systemd-analyze set-log-level notice in the current session but that makes no difference.
Have I missed out on something here?
Thanks,
Andrew - File /etc/systemd/system.conf has "LogLevel=info" but that line (like all in section [Manager]) is commented out.
-
Accepted Answer
I'm still getting the same issue - syslog is swamped by large numbers of "sudo" events, mostly coming from webconfig so the rate of entries depends on what is happening there. Not enough to affect system performance but makes it very hard to spot "real" events. Seems to have been going on for some time though is causing annoyance now as it is making syslog difficult to use for other purposes.
System is fully updated as far as I am aware and no custom edits made to any of the config files mentioned above. Specifically, the three main packages involved are at or above the level required:
Installed Packages
app-base.noarch 1:2.7.4-1.v7
csplugin-events.x86_64 1.2-3.v7
system-base.x86_64 7.6.5-1.v7- File /etc/systemd/system.conf has "LogLevel=info" but that line (like all in section [Manager]) is commented out.
- File /etc/systemd/system.conf.d/clearos-base.conf contains a single entry "LogLevel=notice"
- File /etc/clearos/events.d/20-user-auth.conf hasn't been edited in any way, and is dated 09-Apr-2019.
I tried the command
in the current session but that makes no difference.systemd-analyze set-log-level notice
Have I missed out on something here?
Thanks,
Andrew
PS: I inadvertently replied to this post when I was trying to edit it - can someone please delete my reply below? - File /etc/systemd/system.conf has "LogLevel=info" but that line (like all in section [Manager]) is commented out.
-
Accepted Answer
I have investigated Jeff's system and the root cause could be faced by a few people.
Csplugin-events updated during the big 7.6 update. The only thing it did was to replace /etc/clearos/events.d/20-user-auth.conf which added a filter for the two events you were seeing. In Jeff's case he had edited the file in early 2017. Unfortunately, in the rpm system this file is flagged as a config file, so if yum notices the conf file has been edited, it does not replace it, but creates the new one with an rpmnew extension when it updates.
In this sort of case the user should really regularly go through all rpmnew files ("locate rpmnew") and make a judgement call about them in case they need to make adjustments to their edited file. In this case I moved the original file to /root and renamed the rpmnew file to /etc/clearos/events.d/20-user-auth.conf and restarted clearsync. For the sake of cleanliness I also removed the old events database.
What should now be done is to compare the old /root/20-user-auth.conf to the new /etc/clearos/events.d/20-user-auth.conf and see if there are any changes in the old file which you want to bring into the new file.
In terms of Clearcenter, we could consider making the changes differently and adding an upgrade script to add the new lines to the old file to cover the case that it has been edited. This is possible and will be discussed in a technical meeting, but the file structure is no so neat for inserting lines programatically. -
Accepted Answer
@Brendon and Jeff,
Please can you raise a General Enquiry ticket at https://secure.clearcenter.com/portal/ticket_manage.jsp and submit remote log in credentials to https://secure.clearcenter.com/portal/system_password.jsp and I'll see if someone can have a look tomorrow. This will be done free of charge. -
Accepted Answer
Jeff Rynders wrote:
Looks like I'm having the same issues as Brendon (User root logged in and out via sudo continuously)
Results of what you asked above:
app-base-2.6.9-2.v7.noarch
csplugin-events-1.2-3.v7.x86_64
system-base-7.6.5-1.v7.x86_64
Hi Jeff, I have not found a solution thus far, it is still logging sudo events like crazy. It is not as bad if you don't have webconfig open in a browser but it does not stop it. I'm wondering how concerned I should be with it thrashing logs on an SSD drive, but luckily it is running in a VM that is backed up frequently. -
Accepted Answer
-
Accepted Answer
-
Accepted Answer
-
Accepted Answer
Nick Howitt wrote:
I don't understand this. Those events are info events so should not be being pushed into the events now. What is the contents of /etc/systemd/system.conf.d/clearos-base.conf and what is the result of:
Can you also try the manual command which only works until the next reboot:grep LogLevel /etc/systemd/system.conf
This should have been fixed by system-base.systemd-analyze set-log-level notice
In your secure log are you seeing horrible logging or not? This should have been fixed by app-base, but we will be moving the fix to system-base. Your packages are out of sync here.
Please be careful as you've been updating packages out of clearos-updates-testing. You've pulled the latest app-base from there, so the filtering of secure messages has been dropped and it is now in system-base which you have not pulled. Please do a:
This should quieten down the secure log but does not affect the events.yum update system-base --enablerepo=clearos-updates testing
# grep LogLevel /etc/systemd/system.conf
#LogLevel=info
I am getting a ton of these sudo info logging in my secure log
Apr 16 11:45:02 GW sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Apr 16 11:45:02 GW sudo: pam_unix(sudo:session): session closed for user root
Apr 16 11:45:03 GW sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Apr 16 11:45:03 GW sudo: pam_unix(sudo:session): session closed for user root
I will try updating the system base from testing and see if that helps, thanks! -
Accepted Answer
I don't understand this. Those events are info events so should not be being pushed into the events now. What is the contents of /etc/systemd/system.conf.d/clearos-base.conf and what is the result of:
Can you also try the manual command which only works until the next reboot:grep LogLevel /etc/systemd/system.conf
This should have been fixed by system-base.systemd-analyze set-log-level notice
In your secure log are you seeing horrible logging or not? This should have been fixed by app-base, but we will be moving the fix to system-base. Your packages are out of sync here.
Please be careful as you've been updating packages out of clearos-updates-testing. You've pulled the latest app-base from there, so the filtering of secure messages has been dropped and it is now in system-base which you have not pulled. Please do a:
This should quieten down the secure log but does not affect the events.yum update system-base --enablerepo=clearos-updates testing -
Accepted Answer
-
Accepted Answer
@Brendon,
What is the output from:rpm -q app-base csplugin-events system-base
The problem largely goes away of you close down your webconfig screen, and some pages are less susceptible than others (IP Settings is terrible). So, to get your system responsive again, come out of the webconfig and wait a while. You may hear your disk activity quieten down.
You can remove all the messages in bulk with:systemctl stop clearsync.service
rm -f /var/lib/csplugin-events/events.db
systemctl start clearsync.service -
Accepted Answer
I have followed this thread and made sure the updates were installed and am still having this problem, thousands instances per hour of
User root logged in via sudo 2019-04-15 18:16:19
User root logged out via sudo 2019-04-15 18:16:19
User root logged in via sudo 2019-04-15 18:16:19
User root logged out via sudo 2019-04-15 18:16:19
User root logged in via sudo 2019-04-15 18:16:19
User root logged out via sudo 2019-04-15 18:16:19
User root logged in via sudo 2019-04-15 18:16:17
User root logged out via sudo 2019-04-15 18:16:17
User root logged in via sudo 2019-04-15 18:16:17
User root logged out via sudo 2019-04-15 18:16:17
It started about 10 days ago when my system updated to 7.6, it gets to the point that it causes the dashboard to give a http 500 error. This morning I had 1.5 million notices before clearing them when I couldn't access the dashboard. -
Accepted Answer
Nick Howitt wrote:
@Siv,
Did your "smbd_audit" messages also disappear? If so, I am not sure that it is anything we fixed and may have been a separate issue. I've not been able to replicate it.
Nick,
No, since the updates the machine has quietened down and I am not getting the same events logged.
Whatever you did fixed that issue as well.
Siv -
Accepted Answer
-
Accepted Answer
There are a few other minor improvements to be made here. Some of this activity is because we changed the way that the ClearOS system interacts with the core and we are using a 'sudo' method which fixes some best practices issues but also made the logging issues. We still have a bunch of useless logging events and we are going to be making targeted filters so that the logs do not rotate like made with useless data that we already know about. -
Accepted Answer
-
Accepted Answer
Nick, Dave,
All seems well today, I have had no pages of log files in my reports, in fact I had no report from the server last night so whatever you guys did it has really quietened things down.
I checked through some of the other logs and nothing appears to be going mad today.
Thanks again for all your help resolving this.
Siv -
Accepted Answer
Hi All
Thank you for all the effort that was put into resolving this issue.
I was able to leave my server off until today, not everyone can do this, and waited for a solution - i just ran the update from the web interface the moment i booted.
After the update ran, i also did:
systemctl stop clearsync.service
rm -f /var/lib/csplugin-events/events.db
systemctl start clearsync.service
Everything is now responding and i do not see any more log files going "NUTS"
Thank you again for everyone involved
Leon -
Accepted Answer
Nick Howitt wrote:
Both clearsync and rsyslog should have restarted as part of the update if they were already running. This should fix all the events messages about root opening and closing sessions. You can clean the events log completely with:systemctl stop clearsync.service
rm -f /var/lib/csplugin-events/events.db
systemctl start clearsync.service
It should sort out some of the responsiveness, but I don't think it will do anything about the samba issue and that could also be hammering the events database. Only time will tell.
Nick,
Thanks for the update. I ran these three commands none gave any response so I assume they all completed successfully.
I will watch out for my emailed report tonight and will post a new thread here tomorrow if I am still getting the samba errors.
Siv -
Accepted Answer
Both clearsync and rsyslog should have restarted as part of the update if they were already running. This should fix all the events messages about root opening and closing sessions. You can clean the events log completely with:systemctl stop clearsync.service
rm -f /var/lib/csplugin-events/events.db
systemctl start clearsync.service
It should sort out some of the responsiveness, but I don't think it will do anything about the samba issue and that could also be hammering the events database. Only time will tell. -
Accepted Answer
Nick Howitt wrote:
That is weird. Just a plain old "yum update" should work as I moved them into the clearos-update this morning. The --enablerepo bit is irrelevant now and the yum command should work with or without it. Can I suggest you leave the clearsync service disabled for the moment (or until you get the updates) and then do a:yum clean all && yum update
Sorry Nick your post came in whilst I was working through Dave's recommendation.
It does appear that I have now updated the csplugin.
From the command response I posted do you think that this should do the trick or am I missing something else?
Siv -
Accepted Answer
Dave Loper wrote:
The update that you should be running is csplugin-events-1.2-3.v7
http://koji.clearos.com/koji/buildinfo?buildID=2618
You can look at what version you are running by using:
rpm -qi csplugin-events
If you are not running this version, run the following to clean up your yum cache:
yum --enablerepo=* clean all
As you can see from koji, this package is in clearos-updates. If you are running ClearOS Community you will see this by just doing a 'yum update' after doing the 'yum --enablerepo=* clean all'
If you are running ClearOS Business and have installed these updates already, then you will need to enable the clearos-udpates repo in order to grab this update:
yum --enablerepo=clearos-updates update csplugin-events
Dave,
Thanks for the advice, I ran the commands and I __was__ running the previous version.
I then did:
yum --enablerepo=* clean all
Then:
yum update
Below is the response:
[root@remote ~]# yum update
Loaded plugins: clearcenter-marketplace, fastestmirror
ClearCenter Marketplace: fetching repositories...
Determining fastest mirrors
* clearos: www.mirrorservice.org
* clearos-centos: download3.clearsdn.com
* clearos-centos-sclo-rh: download3.clearsdn.com
* clearos-centos-updates: download3.clearsdn.com
* clearos-contribs: www.mirrorservice.org
* clearos-epel: download3.clearsdn.com
* clearos-fast-updates: download3.clearsdn.com
* clearos-infra: www.mirrorservice.org
* clearos-updates: www.mirrorservice.org
* private-clearcenter-dyndns: download3.clearsdn.com:80
* private-clearcenter-roundcubemail: download1.clearsdn.com:80
clearos | 3.7 kB 00:00
clearos-centos | 3.0 kB 00:00
clearos-centos-sclo-rh | 3.0 kB 00:00
clearos-centos-updates | 3.0 kB 00:00
clearos-contribs | 3.5 kB 00:00
clearos-epel | 2.9 kB 00:00
clearos-fast-updates | 3.0 kB 00:00
clearos-infra | 3.5 kB 00:00
clearos-updates | 3.5 kB 00:00
(1/13): clearos/7/group_gz | 1.6 kB 00:00
(2/13): clearos-contribs/7/updateinfo | 96 B 00:00
(3/13): clearos-contribs/7/primary_db | 71 kB 00:00
(4/13): clearos/7/primary_db | 739 kB 00:00
(5/13): clearos-fast-updates/x86_64/primary_db | 10 kB 00:00
(6/13): clearos-infra/7/updateinfo | 96 B 00:00
(7/13): clearos-infra/7/primary_db | 11 kB 00:00
(8/13): clearos-updates/7/updateinfo | 96 B 00:00
(9/13): clearos-updates/7/primary_db | 861 kB 00:00
(10/13): clearos-centos-sclo-rh/x86_64/primary_db | 3.5 MB 00:07
(11/13): clearos-centos-updates/x86_64/primary_db | 2.3 MB 00:09
(12/13): clearos-epel/7/x86_64/primary_db | 7.4 MB 00:09
(13/13): clearos-centos/x86_64/primary_db | 5.0 MB 00:14
private-clearcenter-dyndns | 3.0 kB 00:00
private-clearcenter-dyndns/primary_db | 2.6 kB 00:00
private-clearcenter-roundcubemail | 3.0 kB 00:00
private-clearcenter-roundcubemail/primary_db | 2.5 kB 00:00
Resolving Dependencies
--> Running transaction check
---> Package app-base.noarch 1:2.6.3-1.v7 will be updated
---> Package app-base.noarch 1:2.6.5-1.v7 will be an update
---> Package app-base-core.noarch 1:2.6.3-1.v7 will be updated
---> Package app-base-core.noarch 1:2.6.5-1.v7 will be an update
---> Package csplugin-events.x86_64 0:1.2-2.v7 will be updated
---> Package csplugin-events.x86_64 0:1.2-3.v7 will be an update
--> Finished Dependency Resolution
Dependencies Resolved
================================================================================
Package Arch Version Repository Size
================================================================================
Updating:
app-base noarch 1:2.6.5-1.v7 clearos-updates 32 k
app-base-core noarch 1:2.6.5-1.v7 clearos-updates 454 k
csplugin-events x86_64 1.2-3.v7 clearos-updates 84 k
Transaction Summary
================================================================================
Upgrade 3 Packages
Total download size: 570 k
Is this ok [y/d/N]: y
Downloading packages:
Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
(1/3): app-base-2.6.5-1.v7.noarch.rpm | 32 kB 00:00
(2/3): app-base-core-2.6.5-1.v7.noarch.rpm | 454 kB 00:00
(3/3): csplugin-events-1.2-3.v7.x86_64.rpm | 84 kB 00:00
--------------------------------------------------------------------------------
Total 1.0 MB/s | 570 kB 00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Updating : 1:app-base-core-2.6.5-1.v7.noarch 1/6
Updating : 1:app-base-2.6.5-1.v7.noarch 2/6
Updating : csplugin-events-1.2-3.v7.x86_64 3/6
Cleanup : 1:app-base-2.6.3-1.v7.noarch 4/6
Cleanup : 1:app-base-core-2.6.3-1.v7.noarch 5/6
Cleanup : csplugin-events-1.2-2.v7.x86_64 6/6
Verifying : 1:app-base-core-2.6.5-1.v7.noarch 1/6
Verifying : csplugin-events-1.2-3.v7.x86_64 2/6
Verifying : 1:app-base-2.6.5-1.v7.noarch 3/6
Verifying : csplugin-events-1.2-2.v7.x86_64 4/6
Verifying : 1:app-base-2.6.3-1.v7.noarch 5/6
Verifying : 1:app-base-core-2.6.3-1.v7.noarch 6/6
Updated:
app-base.noarch 1:2.6.5-1.v7 app-base-core.noarch 1:2.6.5-1.v7
csplugin-events.x86_64 0:1.2-3.v7
Complete!
[root@remote ~]#
So I now have "csplugin-events.x86_64 0:1.2-3.v7", let's hope this qquitens down the logging of events.
I will see if after applying this update the log files stop writing events every second or so.
Should I restart the server or a specific service?
Siv -
Accepted Answer
That is weird. Just a plain old "yum update" should work as I moved them into the clearos-update this morning. The --enablerepo bit is irrelevant now and the yum command should work with or without it. Can I suggest you leave the clearsync service disabled for the moment (or until you get the updates) and then do a:yum clean all && yum update -
Accepted Answer
The update that you should be running is csplugin-events-1.2-3.v7
http://koji.clearos.com/koji/buildinfo?buildID=2618
You can look at what version you are running by using:
rpm -qi csplugin-events
If you are not running this version, run the following to clean up your yum cache:
yum --enablerepo=* clean all
As you can see from koji, this package is in clearos-updates. If you are running ClearOS Community you will see this by just doing a 'yum update' after doing the 'yum --enablerepo=* clean all'
If you are running ClearOS Business and have installed these updates already, then you will need to enable the clearos-udpates repo in order to grab this update:
yum --enablerepo=clearos-updates update csplugin-events -
Accepted Answer
@Nick,
When I ran the command it came up with "No packages marked for update":
yum update csplugin-events app-base --enablerepo=clearos-updates-testing
Loaded plugins: clearcenter-marketplace, fastestmirror
ClearCenter Marketplace: fetching repositories...
Loading mirror speeds from cached hostfile
* clearos: www.mirrorservice.org
* clearos-centos: download3.clearsdn.com
* clearos-centos-sclo-rh: download3.clearsdn.com
* clearos-centos-updates: download3.clearsdn.com
* clearos-contribs: www.mirrorservice.org
* clearos-epel: download3.clearsdn.com
* clearos-fast-updates: download3.clearsdn.com
* clearos-infra: www.mirrorservice.org
* clearos-updates: www.mirrorservice.org
* clearos-updates-testing: www.mirrorservice.org
* private-clearcenter-dyndns: download1.clearsdn.com:80
* private-clearcenter-roundcubemail: download1.clearsdn.com:80
clearos-updates-testing | 3.5 kB 00:00
(1/2): clearos-updates-testing/7/updateinfo | 96 B 00:00
(2/2): clearos-updates-testing/7/primary_db | 736 kB 00:00
No packages marked for update
[root@remote ~]# service clearsync start
Redirecting to /bin/systemctl start clearsync.service
Siv -
Accepted Answer
@Nick,
I just checked my system and no outstanding updates, the following were the updates that were applied most recently and seemed to trigger all sorts of log activity:
Package Action Date/Time
elfutils-default-yama-scope-0.172-2.el7 Updated Apr 08, 01:02:54
linux-firmware-20180911-69.git85c5d90.el ... Updated Apr 07, 05:48:51
lm_sensors-libs-3.4.0-6.20160601gitf9185 ... Updated Apr 07, 05:48:41
samba-python-4.8.3-4.3.v7 Updated Apr 07, 05:48:41
grub2-2.02.1-0.76.v7.1 Updated Apr 07, 05:48:40
samba-winbind-clients-4.8.3-4.3.v7 Updated Apr 07, 05:48:40
samba-client-4.8.3-4.3.v7 Updated Apr 07, 05:48:39
samba-dc-4.8.3-4.3.v7 Updated Apr 07, 05:48:39
libsmbclient-4.8.3-4.3.v7 Updated Apr 07, 05:48:38
samba-dc-libs-4.8.3-4.3.v7 Updated Apr 07, 05:48:38
samba-winbind-4.8.3-4.3.v7 Updated Apr 07, 05:48:38
samba-winbind-modules-4.8.3-4.3.v7 Updated Apr 07, 05:48:35
grub2-pc-2.02.1-0.76.v7.1 Updated Apr 07, 05:48:34
grub2-pc-modules-2.02.1-0.76.v7.1 Updated Apr 07, 05:48:34
grub2-tools-extra-2.02.1-0.76.v7.1 Updated Apr 07, 05:48:33
samba-4.8.3-4.3.v7 Updated Apr 07, 05:48:33
samba-common-tools-4.8.3-4.3.v7 Updated Apr 07, 05:48:27
grub2-tools-2.02.1-0.76.v7.1 Updated Apr 07, 05:48:26
grub2-tools-minimal-2.02.1-0.76.v7.1 Updated Apr 07, 05:48:26
grub2-common-2.02.1-0.76.v7.1 Updated Apr 07, 05:48:25
samba-libs-4.8.3-4.3.v7 Updated Apr 07, 05:48:25
samba-client-libs-4.8.3-4.3.v7 Updated Apr 07, 05:48:24
samba-common-libs-4.8.3-4.3.v7 Updated Apr 07, 05:48:23
libwbclient-4.8.3-4.3.v7 Updated Apr 07, 05:48:22
samba-common-4.8.3-4.3.v7 Updated Apr 07, 05:48:21
mesa-libwayland-egl-17.2.3-8.20171019.el ... Erased Apr 06, 02:07:11
iwl3160-firmware-22.0.7.0-69.el7 Updated Apr 06, 02:02:59
iwl3945-firmware-15.32.2.9-69.el7 Updated Apr 06, 02:02:59
iwl6050-firmware-41.28.5.1-69.el7 Updated Apr 06, 02:02:59
iwl100-firmware-39.31.5.1-69.el7 Updated Apr 06, 02:02:58
iwl2000-firmware-18.168.6.1-69.el7 Updated Apr 06, 02:02:58
iwl6000-firmware-9.221.4.1-69.el7 Updated Apr 06, 02:02:58
iwl7260-firmware-22.0.7.0-69.el7 Updated Apr 06, 02:02:58
iwl1000-firmware-39.31.5.1-69.el7 Updated Apr 06, 02:02:57
iwl135-firmware-18.168.6.1-69.el7 Updated Apr 06, 02:02:57
iwl5150-firmware-8.24.2.2-69.el7 Updated Apr 06, 02:02:57
iwl6000g2b-firmware-17.168.5.2-69.el7 Updated Apr 06, 02:02:57
emacs-filesystem-24.3-22.el7 Updated Apr 06, 02:02:56
iwl105-firmware-18.168.6.1-69.el7 Updated Apr 06, 02:02:56
iwl2030-firmware-18.168.6.1-69.el7 Updated Apr 06, 02:02:56
iwl4965-firmware-228.61.2.24-69.el7 Updated Apr 06, 02:02:56
iwl5000-firmware-8.83.5.1_1-69.el7 Updated Apr 06, 02:02:56
iwl6000g2a-firmware-17.168.5.3-69.el7 Updated Apr 06, 02:02:56
dialog-1.2-5.20130523.el7 Updated Apr 06, 02:02:55
dosfstools-3.0.20-10.el7 Updated Apr 06, 02:02:55
dmidecode-3.1-2.el7 Updated Apr 06, 02:02:53
iw-4.3-2.el7 Updated Apr 06, 02:02:53
iptraf-ng-1.1.4-7.el7 Updated Apr 06, 02:02:52
libgomp-4.8.5-36.el7 Updated Apr 06, 02:02:52
augeas-libs-1.4.0-6.el7_6.1 Updated Apr 06, 02:02:51
Because the initial errors I posted seemed to relate to Samba and seemed to start around the time the 7th April updates were being applied i have assumed the two things are related.
One other thing that occurred was the Windows machines that had mapped links to Flexshares on the server suddenly would not connect and I had to restart the server to get them to connect up again.
Siv -
Accepted Answer
Nick Howitt wrote:
@Siv,
I've released the programs into clearos-updates so they will update tonight. You could try Webconfig > Cloud > Updates > Software Updates and see if that pull them down. I can't test as I've updated my systems. If it shows them but does not give you the chance to update, try switching to a manual update (disable "Automatic Updates").
If you can't update, I suggest you shut down the webconfig on your PC or avoid the screens with a lot of ajax. I don't know which they are, but any with fields that update as you watch the screen, so certainly avoid the IP Settings screen.
Nick,
I finally did manage to get in via SSH and was able to run the command:
yum update csplugin-events app-base --enablerepo=clearos-updates-testing
So I am hopeful that your updates will get through and quieten things down again.
I will watch to see if the other messages come up in the emailed report I get sent at the end of the day that I initially reported as I thought they were related to this. If they do I will raise them as a new thread in these forums.
As always thanks for all you do Nick. -
Accepted Answer
-
Accepted Answer
Tony Ellis wrote:
I suspect it is just an upstream bug which someone noticed and patched and FC is way ahead of ClearOS/Centos/RHEL. We are just using the el7 version of systemd unmodified.
Nick - still the same on the latest Fedora, just tried it... thanks for the workaround...
Maybe "service" is classified under "may be requested by dependency only"
[edit]
auditd changed to systemd
[/edit] -
Accepted Answer
Please login to post a reply
You will need to be logged in to be able to post a reply. Login using the form on the right or register an account if you are new here.
Register Here »