Recently, the command "sudo periodic daily weekly monthly" no longer works from terminal.
If one's Mac is not on at 1am to 3am, how can one be sure the unix maintenance scripts are being run on the Mac.
Thank you.
[Re-Titled by Moderator]
MacBook Air 15″, macOS 15.0
This is an excellent review of what the periodic maintenance scripts did and why they are no longer needed:
These scripts come from the 1990s NeXTStep which ran FreeBSD UNIX utilities and the Mach Darwin kernel. All of the things these scripts do is entirely obsolete. Most of it is ancient FreeBSD features Apple doesn't use nor anyone else either.
At first the periodic maintenance was run with the old cron command. Then Apple moved the jobs to Launchd and now they have removed the /etc/perodic scripts entirely. There are a metric ton of not well documented launchd services running on every Mac. The real maintenance tasks happen automatically with these Apple services.
FYI - Booting into Safe Mode performs some maintenance items and flushes the system caches. You don't see it happening but merely booting into Safe Mode giving it a few minutes then reboot can resolve bizarre issues that are likely related to a corrupted cache entry, etc.
Gordon Davisson @ StackExchange 2021 - Credit where credit is due
https://apple.stackexchange.com/questions/413272/what-does-each-one-of-the-sudo-periodic-options-d
Here's a summary of what the various scripts do. Note that the scripts have not changed much between versions of macOS; I compared them between El Capitan (10.11.6), High Sierra (10.13.6), Catalina (10.15.) and Big Sur (11.2.3), and the only change I noticed was that /etc/periodic/weekly/320.whatis vanished sometime between 10.11.6 and 10.13.6, although something else seems to have taken over its function.
The general goal of the scripts is to clean up things (like temp files) that otherwise would accumulate, check and record system status, and create/maintain various parts of the system.
As you'll see, almost all of them are pretty obsolete -- they relate to things that either aren't used much or don't exist in modern versions of macOS. The only one that I'd really consider relevant today is /etc/periodic/daily/110.clean-tmps, which (as the name suggests) cleans up temporary files. I suspect this is mostly because the periodic system was inherited from FreeBSD, and Apple tends to do cleanup/maintenance on their components differently, so most of these scripts are leftovers from when macOS (well, Mac OS X at the time) inherited this system from FreeBSD.
Note that all of these scripts load settings from /etc/defaults/periodic.conf, (and also /etc/periodic.conf and /etc/periodic.conf.local, but they don't exist by default).
Daily scripts:
* 110.clean-tmps -- deletes old files in /tmp (actually /private/tmp). Note that this does not clean up /var/tmp (actually /private/var/tmp) or the temporary items under /var/folders (actually /private/var/folders); those directories are (intentionally) less temporary than /tmp.
* 130.clean-msgs -- deletes old "system messages". This relates to the msgs command, which I doubt anyone has actually used on macOS. Ever. The modification time on this script (listed at the top) is 2000/09/14.
* 140.clean-rwho -- deletes stale files in /var/rwho. This relates to the rwho command, about as relevant as msgs, script also dates from 2000/09/14.
* 199.clean-fax -- deletes old fax scratch files in /var/spool/fax. I'm not even sure the feature that creates files there still exists in macOS.
* 310.accounting -- rotates system accounting files in /var/account/acct, which relates to the ac command, which I again doubt anyone still uses. This script dates from 2001/05/30.
* 400.status-disks -- checks how full the local disks are with df -h -l, but doesn't seem to do anything useful with the information. (It gets recorded in /var/log/daily.out, but who checks that?)
* 420.status-network -- checks the status of the local network interfaces with netstat -i, but again the info just gets recorded in /var/log/daily.out.
* 430.status-rwho -- seems to mostly just get the system's uptime (how long since last boot); again, it's recorded in /var/log/daily.out.
* 999.local -- runs /etc/daily.local if it exists (it doesn't by default). This is for backward compatibility with an older organization of the periodic files that was obsolete when this script was written: 2001/06/01. Wow.
Weekly scripts:
* 320.whatis -- this creates/updates a database of man pages for the whatis command to search. This script was removed sometime between 10.11.6 and 10.13.6, although the whatis command still exists and seems to work (I guess it's updated some other way now).
* 999.local -- runs /etc/weekly.local if it exists. More extreme backward compatibility.
Monthly scripts:
* 199.rotate-fax -- rotates old fax logs in /var/log/fax. Again, I'm not sure this feature exists anymore.
* 200.accounting -- more to do with that system accounting system I don't think anyone still uses.
* 999.local -- runs /etc/monthly.local if it exists. More extreme backward compatibility.
The fact is whatever portions of the OS and/or Mac are responsible for executing the unix maintenance scripts, and PRAM 'zap' cannot run them if those portions are malfunctioning.
Thus, having a manual way to execute these is reasonable and prudent.
That's my peace.
Here's the crux of the problem for me:
I have noted some minor issues - as most Mac users do, and now without a way to 'zap' PRAM, and run the unix maintenance scripts, perhaps the problems would be rectified with one of the aforementioned tools.
I mentioned this to multiple agents. Fuel to the fire that there is no good reason for Apple to have taken them away from us. Routinely done or not, they should never have been removed from manual triggering by users. And I still see no proof that any of it is being done.
Is there a problem doing multiple PRAM 'zaps', multiple unix maintenance scripts executions? In the past there wasn't.
When verification is impossible, I do not trust. Trust, but verify.
I have noted some minor issues -
Once again, I am asking you to explain them. I won't be asking again.
... as most Mac users do,
I don't, nor do I believe most Mac users do. All anyone needs to do is let them work.
Do understand, the Operating System is actually Leased to the User
Under the Term and Condition of a Lease, the Owner ( Apple ) is well within their Right to Modify, Remove, Add etc any part of the Operating System
The hard truth of the matter maybe hard to accept but it is what it is
Alright, you asked, Safari recently began Force Quitting say three or four times a day. One agent suggested deleting cache files, including booting into Safe Boot Mode (she said Safe Boot clears some caches that cannot be cleared manually)
This did positively impact the Force Quitting, and it still happened with less frequency.
Another agent asked me to leave caches alone - I still clear history and web data.
So far I can remember one Force Quit since.
Now as I advised both agents, the PRAM 'zap', and unix scripts would have been among the first measures I would have executed, and right now there is no proof that either is being done.
That's one.
I understand that PRP_53, thus my requests of agents to restore user access to PRAM 'zap' and unix maintenance scripts execution.
And I point out again, these tools should never have been removed from user execution.
Force quitting — as in Safari became unresponsive, requiring that you needed to force the app to quit? Or did Safari crash on its own? For the latter, posting the ensuing crash report may help.
Pending that clarification, Safe Mode is a good initial troubleshooting step, but I would also recommend reviewing If Safari doesn't open a page or work as expected on your Mac - Apple Support. Those suggestions range from the mundane to relevant and useful, but to rule out all causes you need to methodically exhaust each one of them.
In any case EtreCheck often reveals actionable information. Instructions: How to use the Add Text Feature When Posting Large Amounts of Text, i.e. an Etrecheck Report - Apple Community.
What used to be PRAM is now NVRAM (for nonvolatile RAM) and as far as our ability to alter its contents may as well not exist in M series Macs. Restarting a Mac effectively resets it on them. Effecting an SMC Reset requires a restart or shutdown followed by a deliberate press of the power button (not just any key). I doubt either one of those actions will have any effect on Safari misbehavior though.
I doubt Apple provided any useful information to you, but they never recommend EtreCheck. I do.
TheGoldenKnight wrote:
Here's the crux of the problem for me:
I have noted some minor issues - as most Mac users do, and now without a way to 'zap' PRAM, and run the unix maintenance scripts, perhaps the problems would be rectified with one of the aforementioned tools.
The Unix maintenance scripts have done nothing useful for the GUI in about a decade. Running them won’t fix your Safari problems.
I mentioned this to multiple agents. Fuel to the fire that there is no good reason for Apple to have taken them away from us. Routinely done or not, they should never have been removed from manual triggering by users.
Why not? I think the only utility them is to periodically update the locate database. That is only useful in the command line to find things. It has nothing to do with Spotlight.
And I still see no proof that any of it is being done.
Is there a problem doing multiple PRAM 'zaps', multiple unix maintenance scripts executions? In the past there wasn't.
There is pretty much nothing stored in NVRAM that would help if you reset it.
When verification is impossible, I do not trust. Trust, but verify.
If you want to piddle with your computer, install Linux or Windows.
TheGoldenKnight wrote:
No I do not wish to "Piddle" - whatever that means.
I wish to have access to maintenance tools to address issues as they arise.
You seem to not understand those tools do nothing and haven’t for at least a decade.
TheGoldenKnight wrote:
Alright, you asked, Safari recently began Force Quitting say three or four times a day.
It would be better to start a new thread specific to your Safari problem. Force Quitting is something that users do, not Safari. If Safari is locking up or something, then you might be the one doing the force quitting. Hard to say what the cause might be. The number of crazy things I've seen people do in this forum - it could be anything. Make sure you don't have any 3rd party system modifications, especially any "security" apps or "network filters". Disable extensions, yada, yada, yada.
One agent suggested deleting cache files, including booting into Safe Boot Mode (she said Safe Boot clears some caches that cannot be cleared manually)
Which agent? 007? Technically Safe Boot will do that, but it probably isn't going to help.
Now as I advised both agents, the PRAM 'zap', and unix scripts would have been among the first measures I would have executed, and right now there is no proof that either is being done.
I gave you that proof. Perhaps you didn't see it. Go to that little control at the bottom right corner of your original question and change "Sort by" to "Newest". The default setting is "rank" and that's going to totally confuse you and cause you to miss all kinds of great responses that may directly solve your problem. But since no one has "upvoted" those solutions, you'll never, ever see them unless you set the sort order to "Newest".
There is nothing wrong with updating the locate database!
When did I say there was? I just pointed out that was about the only useful thing the unix maintenance scripts did for about a decade, but they don't do that either, now.
TheGoldenKnight wrote:
I understand that PRP_53, thus my requests of agents to restore user access to PRAM 'zap' and unix maintenance scripts execution.
And I point out again, these tools should never have been removed from user execution.
Apple does what Apple Believes is Best for Apple and has always worked that way
The best we can do, is adopt to the New Realities or perish trying to adapt
As for zapping the PRAM - it is NVRAM
If you have a Mac with Apple silicon
The steps to reset NVRAM don't apply to Mac computers with Apple silicon, and aren't needed on those computers
g_wolfman wrote:
Umm...I wasn't being confrontational, I was being humourous. Or trying to, at least...clearly my 5th generation supercruise humour fell flat on your 4th generation afterburner sensibilities.
Much like all of the 5th-gen stuff, try a ctrl-alt-del to reboot the glitching humor function.
James Brickley wrote:
The problem is the macOS logs are very noisy with debug messages, while useful for developers
Apple's new logging system is not useful for developers. And it's not just me saying that. Here is another developer complaining about it. The response from Apple is pretty funny. They say developers don't have to use it and point out that Apple's own Swift developers actually implemented their own logging system.
the man spends a lot of time reverse engineering and documenting what he finds.
But why? Supposedly, the new logging system was designed specifically for internal and external Apple developers. The Apple engineer who calls the logging system a developer's "best friend" also recommends against reading too much into it. So why would someone push so heavily for non-developers to use the logging system to look for problems?
The only practical use that I've seen for the logging system has been to help fuel paranoid delusions of targeting hacking. I always find it disturbing when people feed that kind of illness instead of trying to direct people towards more useful, practical, and beneficial practices.
You are welcome to your opinion. You have not read what I wrote, and I am not going to argue.
Where is the /var/log directory, please?
Command "sudo periodic daily weekly monthly" no longer works from terminal in sequoia
