Since the last update I’m getting hundreds of these every day
Process Core Dump (PID 869766/UID 0): 1 Time(s) Process Core Dump (PID 869788/UID 0): 1 Time(s) Process Core Dump (PID 869810/UID 0): 1 Time(s) Process Core Dump (PID 869832/UID 0): 1 Time(s)
On my mail server and one of my other servers. Linux always manages to come up with some new horror that wastes hours of people’s time.
How can I fix this?
Can you confirm what you mean by “last update”, because there was also an out-of-band update.
Check the logs to find out the name of the process that dumped core, your output only shows the pid.
Which log should I check?
Pretty much everything gets logged in /var/log/messages so something should appear in there. Once we know what the process is, then we can figure out what is actually failing, be it postfix, or something else on your server.
One more thing would be to check if there is enough CPU/ram allocated to the server, and see if the server has started to swap. If it has, then this could mean lack of cpu/ram resources. Although I would expect to see “OOM Killer” messages in the log file if this was the case (worth checking the logs for this too).
If you don’t want to debug and find out where the problem lies (although I don’t recommend that), you could just disable core dumps so that they don’t get saved to the disk. It would be best to figure out why though. I can’t imagine updates alone are doing this, but rather something else, be it lack of cpu/ram, or something else.
Could the coredumpctl tool have access to some additional logs?
The man systemd-coredump writes:
systemd-coredump@.service is a system service to process core dumps. It will log a summary of the event to systemd-journald.service(8), including information about the process identifier, owner, the signal that killed the process, and the stack trace if possible. It may also save the core dump for later processing. See the “Information about the crashed process” section below.
…
coredumpctl(1) can be used to retrieve saved core dumps independently of their location, to display information, and to process them e.g. by passing to the GNU debugger (gdb).
Does this help?
gnome-terminal-server.service: Failed with result ‘exit-code’.: 1 Time(s)
gnome-terminal-server.service: Main process exited, code=exited, status=1/FAILURE: 1 Time(s)
iscsi.service: Unit cannot be reloaded because it is inactive.: 4 Time(s)
systemd 239 (239-78.el8) running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=legacy): 4 Time(s)
systemd-journald.service: Scheduled restart job, restart counter is at 1.: 2 Time(s)
systemd-journald.service: Service has no hold-off time (RestartSec=0), scheduling restart.: 2 Time(s)
tracker-extract.service: Failed with result ‘core-dump’.: 4236 Time(s)
tracker-extract.service: Main process exited, code=dumped, status=31/SYS: 3530 Time(s)
tracker-extract.service: Scheduled restart job, restart counter is at 1.: 706 Time(s)
tracker-extract.service: Scheduled restart job, restart counter is at 2.: 706 Time(s)
tracker-extract.service: Scheduled restart job, restart counter is at 3.: 706 Time(s)
tracker-extract.service: Scheduled restart job, restart counter is at 4.: 706 Time(s)
tracker-extract.service: Scheduled restart job, restart counter is at 5.: 706 Time(s)
tracker-extract.service: Service RestartSec=100ms expired, scheduling restart.: 3530 Time(s)
tracker-extract.service: Start request repeated too quickly.: 706 Time(s)
webmin.service: Can’t open PID file /var/webmin/miniserv.pid (yet?) after start: No such file or directory: 2 Time(s)
webmin.service: Failed with result ‘timeout’.: 7 Time(s)
webmin.service: Scheduled restart job, restart counter is at 1.: 2 Time(s)
webmin.service: Scheduled restart job, restart counter is at 2.: 2 Time(s)
webmin.service: Scheduled restart job, restart counter is at 3.: 2 Time(s)
webmin.service: Scheduled restart job, restart counter is at 4.: 1 Time(s)
webmin.service: Service RestartSec=2s expired, scheduling restart.: 7 Time(s)
webmin.service: start operation timed out. Terminating.: 7 Time(s)
xdg-desktop-portal-gtk.service: Failed with result ‘exit-code’.: 1 Time(s)
xdg-desktop-portal-gtk.service: Main process exited, code=exited, status=1/FAILURE: 1 Time(s)
No not really. You will have to do some correlation with your logs, to find what processes are stopping/restarting, what PID matches with the ones you posted in your initial post in this thread. We do not have access to your logs so we cannot see if what you posted above matches the PID’s that were core dumping or not.
Also, @jlehtone suggested using coredumpctl to find out more information which could help you determine what was causing problems.
I also asked, how many CPU/ram does your server have, because maybe you do not have enough cpu cores available, or ram based on what you have installed on your server. Also, you need to explain as well what is actually installed on the server. You say mail server, but that usually comprises of a number of components, postfix/exim/sendmail (one of these), and other things like maybe a mysql database, apache web server for webmail. You list above gnome-terminal-server, so that means you also have a GUI environment running on your server, which also needs more cpu/ram resources.
So a lot more info is required as to your server setup, to determine if it is overloaded by lack of cpu/ram or other things.
You see, to be perfectly honest, I’m completely out of my depth here. The server was setup ove 2 years ago, by someone on this forum. NOTHING has been added, nothing has changed. I hesitate to ‘fiddle with things’ because I don’t know enough about it. I was a Novell engineer. Linux just gets more and more complicated and less and less easy to work with.
Since the server was installed all I added was fail2ban and that was about a year ago. There are no new users. all the server does is mail with Postfix and Dovecot. There have been no addirtions to mail users and we get few messages because my family and I use Protonmail. The only reason I’ve kept this server going is because it was my old address when I worked and I still have a few people who know this address and every now and then someone out of the blue I haven’t seen for years, sends me an email.
It runs on VMware. It’s got 2xCPUs allocated and 6GB RAM. Its been working fine and suddenly after the last updates this happemed. and I see this morning that another sever installed at the same time with a webserver only, has the same problem.
NONE of the servers DO anything other than mail and the other 2 x PhpBB websites.
It was easy for me to sort out eDirectory/NDS problems with Netware until Novell brought out a GUI to make it easy I used to send users step by step dicument with screen shots to talk them through it. Linux would rather take the GUI’s away. And I ran mailservers with GroupWise and thousands of users with less than 6GB RAM
It’s always the fault of the user, who is automatically assumed to have ‘done’ something to cause the problem, NEVER a fault of the OS. updates or anything else.
Looking at Linux logs (there are 1,000 Let’sEncrypt logs alone) is a bit like reading a book in Chinese. I should match PID. coredumpctl. YOU might know what these mean I haven’t a clue. I’m 83 and well out of my depth. Its so sad Novell allowed Microsft to drive them out of business and destroy NetWare 6.5.
I asked you in my previous post to check the log files using the PID’s from the first post you made. I will quote your first post below:
You see in big letters PID - and you see a number after it? Now check the log files under /var/log/ I think a good one would be /var/log/messages to start with, and then go through others if you do not find it. Do you know how to use grep to check log files? In case you do not here is a tutorial to help you with that: Grep Command in Linux/UNIX | DigitalOcean which I found with Google. You can find a lot of information using Google, just in case you haven’t heard of it already.
Let’s google coredumpctl and see what that gives us? From the very first result we have: coredumpctl which if you read it does tell you the command you can use to get information. So now, if we use one of the PID’s from your post above:
coredumpctl list 869766
that should give you something back. Now you can get more detail with:
coredumpctl info 869766
Other commands can also be found in that link that I googled for you.
Well Novell is like 10 - 20 years old, so memory requirements are not the same as they are now. So you cannot expect systems that exist today to use the same or less amount of memory than servers that are 20+ years old.
The internet is a wonderful place where search engines can help you get a lot of information. However, it means you do have to put more effort in by searching your own server for logs and information that might help us to help you. If you do not provide it, or expect someone to spoon feed you with commands because you cannot be bothered to read about commands that we gave you, or cannot even do a simple google search to find out about a command we gave you, then you just make our life more difficult/impossible.
If that is too difficult for you, I suggest you should purchase a mail service like Outlook 365 or Zoho Mail and have your old email domain redirected there. Then all you have to do is send/receive emails, and you don’t have to worry about configuring and running a server that you have no idea about and seem unwilling to learn because it isn’t Novell. You can also pay for shared hosting solutions as well that offer PHPBB - which would also save you from having to administer it. The servers would be maintained and upgraded by the shared hosting provider.
We didn’t say that the updates didn’t cause it, we have been trying to assist you, but you are extremely difficult to work with as you are unwilling to give the information we asked for - especially when we’ve given explicit information as to what log file to check, and then all you need to do is look at it, search for info, and provide it here.
If you come to the forums asking for help, you need to be prepared to put in effort into giving the information we ask for. If you do not know how to do that, Google can give you access to a lot of information that can help you do that. We are not here to google for you, since you won’t learn anything that way if someone just tells you what to do all the time. And it’s lazy to think so otherwise.
If all that sounds hash, well I’m sorry but what we have asked you to do is really simple Linux admin commands - they are not difficult. And even if you don’t know them, it’s very easy to find information on them if you put in a little bit more effort.
Messages
May 6 03:41:56 hermes dbus-daemon[2776]: [session uid=0 pid=2776] Activating via systemd: service name=‘org.freedesktop.Tracker1.Miner.Extract’ unit=‘tracker- extract.service’ requested by ‘:1.69’ (uid=0 pid=3172 comm="/usr/libexec/tracker-miner-fs “) May 6 03:41:56 hermes systemd[2739]: Starting Tracker metadata extractor… May 6 03:41:56 hermes journal[168039]: Setting scheduler policy to SCHED_IDLE May 6 03:41:56 hermes journal[168039]: Setting priority nice level to 19 May 6 03:41:56 hermes journal[168039]: tracker_module_manager_load_modules: assertion ‘initialized == TRUE’ failed May 6 03:41:56 hermes systemd[1]: Started Process Core Dump (PID 168053/UID 0). May 6 03:41:56 hermes systemd-coredump[168054]: Resource limits disable core dumping for process 168039 (tracker-extract). May 6 03:41:56 hermes systemd-coredump[168054]: Process 168039 (tracker-extract) of user 0 dumped core. May 6 03:41:56 hermes systemd[2739]: tracker-extract.service: Main process exited, code=dumped, status=31/SYS May 6 03:41:56 hermes systemd[2739]: tracker-extract.service: Failed with result ‘core-dump’. May 6 03:41:56 hermes systemd[2739]: Failed to start Tracker metadata extractor. May 6 03:41:56 hermes systemd[1]: systemd-coredump@4031-168053-0.service: Succeeded. May 6 03:41:56 hermes systemd[2739]: tracker-extract.service: Service RestartSec=100ms expired, scheduling restart. May 6 03:41:56 hermes systemd[2739]: tracker-extract.service: Scheduled restart job, restart counter is at 1. May 6 03:41:56 hermes systemd[2739]: Stopped Tracker metadata extractor. May 6 03:41:56 hermes systemd[2739]: Starting Tracker metadata extractor… May 6 03:41:56 hermes journal[168064]: Setting scheduler policy to SCHED_IDLE May 6 03:41:56 hermes journal[168064]: Setting priority nice level to 19 May 6 03:41:56 hermes journal[168064]: tracker_module_manager_load_modules: assertion ‘initialized == TRUE’ failed May 6 03:41:56 hermes systemd[1]: Started Process Core Dump (PID 168078/UID 0). May 6 03:41:56 hermes systemd-coredump[168079]: Resource limits disable core dumping for process 168064 (tracker-extract). May 6 03:41:56 hermes systemd-coredump[168079]: Process 168064 (tracker-extract) of user 0 dumped core. May 6 03:41:56 hermes systemd[2739]: tracker-extract.service: Main process exited, code=dumped, status=31/SYS May 6 03:41:56 hermes systemd[2739]: tracker-extract.service: Failed with result ‘core-dump’. May 6 03:41:56 hermes systemd[2739]: Failed to start Tracker metadata extractor. May 6 03:41:56 hermes systemd[1]: systemd-coredump@4032-168078-0.service: Succeeded. May 6 03:41:56 hermes systemd[2739]: tracker-extract.service: Service RestartSec=100ms expired, scheduling restart. May 6 03:41:56 hermes systemd[2739]: tracker-extract.service: Scheduled restart job, restart counter is at 2. May 6 03:41:56 hermes systemd[2739]: Stopped Tracker metadata extractor. May 6 03:41:56 hermes systemd[2739]: Starting Tracker metadata extractor… May 6 03:41:56 hermes journal[168086]: Setting scheduler policy to SCHED_IDLE May 6 03:41:56 hermes journal[168086]: Setting priority nice level to 19 May 6 03:41:57 hermes journal[168086]: tracker_module_manager_load_modules: assertion ‘initialized == TRUE’ failed May 6 03:41:57 hermes systemd[1]: Started Process Core Dump (PID 168100/UID 0). May 6 03:41:57 hermes systemd-coredump[168101]: Resource limits disable core dumping for process 168086 (tracker-extract). May 6 03:41:57 hermes systemd-coredump[168101]: Process 168086 (tracker-extract) of user 0 dumped core. May 6 03:41:57 hermes systemd[2739]: tracker-extract.service: Main process exited, code=dumped, status=31/SYS May 6 03:41:57 hermes systemd[2739]: tracker-extract.service: Failed with result ‘core-dump’. May 6 03:41:57 hermes systemd[1]: systemd-coredump@4033-168100-0.service: Succeeded. May 6 03:41:57 hermes systemd[2739]: Failed to start Tracker metadata extractor. May 6 03:41:57 hermes systemd[2739]: tracker-extract.service: Service RestartSec=100ms expired, scheduling restart. May 6 03:41:57 hermes systemd[2739]: tracker-extract.service: Scheduled restart job, restart counter is at 3. May 6 03:41:57 hermes systemd[2739]: Stopped Tracker metadata extractor. May 6 03:41:57 hermes systemd[2739]: Starting Tracker metadata extractor… May 6 03:41:57 hermes journal[168108]: Setting scheduler policy to SCHED_IDLE May 6 03:41:57 hermes journal[168108]: Setting priority nice level to 19 May 6 03:41:57 hermes journal[168108]: tracker_module_manager_load_modules: assertion ‘initialized == TRUE’ failed May 6 03:41:57 hermes systemd[1]: Started Process Core Dump (PID 168122/UID 0). May 6 03:41:57 hermes systemd-coredump[168123]: Resource limits disable core dumping for process 168108 (tracker-extract). May 6 03:41:57 hermes systemd-coredump[168123]: Process 168108 (tracker-extract) of user 0 dumped core. May 6 03:41:57 hermes systemd[2739]: tracker-extract.service: Main process exited, code=dumped, status=31/SYS May 6 03:41:57 hermes systemd[2739]: tracker-extract.service: Failed with result ‘core-dump’. May 6 03:41:57 hermes systemd[2739]: Failed to start Tracker metadata extractor. May 6 03:41:57 hermes systemd[1]: systemd-coredump@4034-168122-0.service: Succeeded. May 6 03:41:57 hermes systemd[2739]: tracker-extract.service: Service RestartSec=100ms expired, scheduling restart. May 6 03:41:57 hermes systemd[2739]: tracker-extract.service: Scheduled restart job, restart counter is at 4. May 6 03:41:57 hermes systemd[2739]: Stopped Tracker metadata extractor. May 6 03:41:57 hermes systemd[2739]: Starting Tracker metadata extractor… May 6 03:41:57 hermes journal[168132]: Setting scheduler policy to SCHED_IDLE May 6 03:41:57 hermes journal[168132]: Setting priority nice level to 19 May 6 03:41:58 hermes journal[168132]: tracker_module_manager_load_modules: assertion ‘initialized == TRUE’ failed May 6 03:41:58 hermes systemd[1]: Started Process Core Dump (PID 168146/UID 0). May 6 03:41:58 hermes systemd-coredump[168147]: Resource limits disable core dumping for process 168132 (tracker-extract). May 6 03:41:58 hermes systemd-coredump[168147]: Process 168132 (tracker-extract) of user 0 dumped core. May 6 03:41:58 hermes systemd[2739]: tracker-extract.service: Main process exited, code=dumped, status=31/SYS May 6 03:41:58 hermes systemd[1]: systemd-coredump@4035-168146-0.service: Succeeded. May 6 03:41:58 hermes systemd[2739]: tracker-extract.service: Failed with result ‘core-dump’. May 6 03:41:58 hermes systemd[2739]: Failed to start Tracker metadata extractor. May 6 03:41:58 hermes systemd[2739]: tracker-extract.service: Service RestartSec=100ms expired, scheduling restart. May 6 03:41:58 hermes systemd[2739]: tracker-extract.service: Scheduled restart job, restart counter is at 5. May 6 03:41:58 hermes systemd[2739]: Stopped Tracker metadata extractor. May 6 03:41:58 hermes systemd[2739]: tracker-extract.service: Start request repeated too quickly. May 6 03:41:58 hermes systemd[2739]: tracker-extract.service: Failed with result ‘core-dump’. May 6 03:41:58 hermes systemd[2739]: Failed to start Tracker metadata extractor. May 6 03:43:56 hermes dbus-daemon[2776]: [session uid=0 pid=2776] Failed to activate service ‘org.freedesktop.Tracker1.Miner.Extract’: timed out (service_start_timeout=120000ms) May 6 03:43:57 hermes dbus-daemon[2776]: [session uid=0 pid=2776] Activating via systemd: service name=‘org.freedesktop.Tracker1.Miner.Extract’ unit=‘tracker- extract.service’ requested by ‘:1.69’ (uid=0 pid=3172 comm=”/usr/libexec/tracker-miner-fs ") May 6 03:43:57 hermes systemd[2739]: Starting Tracker metadata extractor… May 6 03:43:57 hermes journal[168210]: Setting scheduler policy to SCHED_IDLE May 6 03:43:57 hermes journal[168210]: Setting priority nice level to 19 May 6 03:43:57 hermes journal[168210]: tracker_module_manager_load_modules: assertion ‘initialized == TRUE’ failed May 6 03:43:57 hermes systemd[1]: Started Process Core Dump (PID 168224/UID 0). May 6 03:43:57 hermes systemd-coredump[168225]: Resource limits disable core dumping for process 168210 (tracker-extract). May 6 03:43:57 hermes systemd-coredump[168225]: Process 168210 (tracker-extract) of user 0 dumped core. May 6 03:43:57 hermes systemd[2739]: tracker-extract.service: Main process exited, code=dumped, status=31/SYS May 6 03:43:57 hermes systemd[2739]: tracker-extract.service: Failed with result ‘core-dump’. May 6 03:43:57 hermes systemd[2739]: Failed to start Tracker metadata extractor. May 6 03:43:57 hermes systemd[1]: systemd-coredump@4036-168224-0.service: Succeeded. May 6 03:43:57 hermes systemd[2739]: tracker-extract.service: Service RestartSec=100ms expired, scheduling restart. May 6 03:43:57 hermes systemd[2739]: tracker-extract.service: Scheduled restart job, restart counter is at 1. May 6 03:43:57 hermes systemd[2739]: Stopped Tracker metadata extractor. May 6 03:43:57 hermes systemd[2739]: Starting Tracker metadata extractor… May 6 03:43:57 hermes journal[168235]: Setting scheduler policy to SCHED_IDLE May 6 03:43:57 hermes journal[168235]: Setting priority nice level to 19 May 6 03:43:57 hermes journal[168235]: tracker_module_manager_load_modules: assertion ‘initialized == TRUE’ failed May 6 03:43:57 hermes systemd[1]: Started Process Core Dump (PID 168249/UID 0). May 6 03:43:57 hermes systemd-coredump[168250]: Resource limits disable core dumping for process 168235 (tracker-extract). May 6 03:43:57 hermes systemd-coredump[168250]: Process 168235 (tracker-extract) of user 0 dumped core. May 6 03:43:57 hermes systemd[2739]: tracker-extract.service: Main process exited, code=dumped, status=31/SYS May 6 03:43:57 hermes systemd[2739]: tracker-extract.service: Failed with result ‘core-dump’. May 6 03:43:57 hermes systemd[2739]: Failed to start Tracker metadata extractor. May 6 03:43:57 hermes systemd[1]: systemd-coredump@4037-168249-0.service: Succeeded. May 6 03:43:57 hermes systemd[2739]: tracker-extract.service: Service RestartSec=100ms expired, scheduling restart. May 6 03:43:57 hermes systemd[2739]: tracker-extract.service: Scheduled restart job, restart counter is at 2. May 6 03:43:57 hermes systemd[2739]: Stopped Tracker metadata extractor. May 6 03:43:57 hermes systemd[2739]: Starting Tracker metadata extractor… May 6 03:43:57 hermes journal[168258]: Setting scheduler policy to SCHED_IDLE May 6 03:43:57 hermes journal[168258]: Setting priority nice level to 19 May
coredumpctl list 869766
no coredumps found
Running processes
UNIT LOAD ACTIVE
SUB DESCRIPTION
accounts-daemon.service loaded active running Accounts
Service
atd.service loaded active running Job spooling
tools
auditd.service loaded active running Security Auditing
Service
avahi-daemon.service loaded active running Avahi mDNS/DNS-SD
Stack
chronyd.service loaded active running NTP
client/server
colord.service loaded active running Manage, Install and
Generate Col>
crond.service loaded active running Command
Scheduler
cups.service loaded active running CUPS
Scheduler
dbus.service loaded active running D-Bus System Message
Bus
dovecot.service loaded active running Dovecot IMAP/POP3 email
server
fail2ban.service loaded active running Fail2Ban
Service
firewalld.service loaded active running firewalld - dynamic
firewall dae>
gdm.service loaded active running GNOME Display
Manager
gssproxy.service loaded active running GSSAPI Proxy
Daemon
httpd.service loaded active running The Apache HTTP
Server
irqbalance.service loaded active running irqbalance
daemon
ksmtuned.service loaded active running Kernel Samepage Merging
(KSM) Tu>
libstoragemgmt.service loaded active running libstoragemgmt plug-in
server da>
mcelog.service loaded active running Machine Check Exception
Logging >
ModemManager.service loaded active running Modem
Manager
mysqld.service loaded active running MySQL 8.0 database
server
NetworkManager.service loaded active running Network
Manager
opendkim.service loaded active running DomainKeys Identified
Mail (DKIM>
packagekit.service loaded active running PackageKit
Daemon
php-fpm.service loaded active running The PHP FastCGI Process
Manager
polkit.service loaded active running Authorization
Manager
postfix.service loaded active running Postfix Mail Transport
Agent
rpcbind.service loaded active running RPC
Bind
rsyslog.service loaded active running System Logging
Service
rtkit-daemon.service loaded active running RealtimeKit Scheduling
Policy Se>
smartd.service loaded active running Self Monitoring and
Reporting Te>
sshd.service loaded active running OpenSSH server
daemon
sssd-kcm.service loaded active running SSSD Kerberos Cache
Manager
systemd-journald.service loaded active running Journal
Service
systemd-logind.service loaded active running Login
Service
systemd-machined.service loaded active running Virtual Machine and
Container Re>
systemd-udevd.service loaded active running udev Kernel Device
Manager
tuned.service loaded active running Dynamic System Tuning
Daemon
udisks2.service loaded active running Disk
Manager
upower.service loaded active running Daemon for power
management
user@0.service loaded active running User Manager for UID
0
vgauthd.service loaded active running VGAuth Service for open-
vm-tools
vmtoolsd.service loaded active running Service for virtual
machines hos>
webmin.service loaded active running Webmin server
daemon
wpa_supplicant.service loaded active running WPA
supplicantLOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of
SUB.
SUB = The low-level unit activation state, values depend on unit
type.45 loaded units listed. Pass --all to see loaded but inactive units,
too.
It will be best to filter the logs for the latest lines similar to “Process Core Dump” since it could well be that the PID’s from your original message here have had the coredumps overwritten. I would grep the logs for Process Core Dump as you found before, and then get the latest lines and check those with the coredumpctl commands.
If still nothing found then that would be strange. Especially even more so if your server works perfectly fine in terms of mail server and web server with PHPBB. That would then suggest that some other processes unrelated to these services are being core dumped instead.
Sadly, if we cannot get any results from the coredumpctl command when ran against all the PID’s listed, then it’s going to be impossible to find out why and what is causing it.
Tracker-extract.service is terminating and restarting. Looks like Gnome is installed probably on Centos 7 guests. Need to run systemctl --no-pager -l status tracker-extract.service?
I believe his system is Rocky 8, not CentOS. He could have the tracker-miners package installed since this does include the tracker-extract.service file.
Gnome ‘tracker’ is basically desktop search, it allows you to quickly find local documents, music etc. There were big changes between Rocky 8.x and Rocky 9.x so we need to know the exact o/s version. One thing to try is to simply turn off “search” in Gnome settings (easy in Rocky 9, but don’t know about Rocky 8). It won’t completely disable tracker, but has been known to reduce activity by a substatial amount.
Part of the problem with the service shown in the logs, is that it’s set to restart on failure, so it goes into a massive loop crashing each time.
Thanks @gerry666uk I turned the search feature off. I’ll let you know if it works
It’s not at all a case of being reluctant to give you the informatuon you ask for, its a question of not telline me how to get it or where from. As you said YOU know, I don’t unless you tell me how to get what you want.
If you treat me as a dumb user, that’s fine by me. When it comes to Linux, that’s me. Most people at 83 are lying in bed in a nursing home waiting to die. All I ask is a little respect and it you tell me HOW and WHERE to find the info you request, I have no problem giving it to you.
I don’t have enough time left in my life to go hunting millions of documents all telling me something different and none of them giving a result. God help poor dumb users in places like the NHS or even General Motors if this is the way you respond to there pleas for assistance.
“Yeah, just go through the logs and grep what you want there’s plenty of info for you to waste one of your remaining years trying to make head or tail of the hundreds of commands that you need to use grep.”
“Which logs? Yeah, just look it up on the internet and when it sends you here, ignore it because we expect you to know the answers before you ask the question.”
I told you to check your logs files. There are not many log files under /var/log you seem to make out as if there are 1000’s of log files here when there are not. The fact you won’t check them is just pure laziness from your part.
You expect respect, and disrespect me and everyone here because you are too lazy to read what we have posted so far, and you are too lazy to check the log files under /var/log because you expect me to tell you every single piece of information. You could use google to read about commands that people have posted, but it seems you do not want to do that, or cannot be bothered to do it because you expect me to google and do everything for you. That is not how it works.
Then I suggest you forget about running your own server, move your PHPBB to a shared hosted service and you pay them to do it for you. Do the same with your mail server is well. Then you do not need to waste any more of your time on something that you have no clue about and no wish to read about to fix it. Pay people to host your PHPBB and your email, and then you have more time to do whatever else you want to do. Do not expect me or anyone else to give up their own precious time helping you when you cannot be bothered to read or check your log files (as already said there are not many of them).
Yes, that’s laziness on your part. Because you cannot be bothered, you expect everyone else to do it for you.
Look under /var/log if you can be bothered.
I am no longer going to offer my help to someone who disrespects me and wastes my time like you do.