Command "sudo periodic daily weekly monthly" no longer works from terminal in sequoia

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.

TheGoldenKnight wrote:

First, upon what do you base the assertion that the maintenance scripts will run upon the Mac waking?

Second, what about shut down at bed time, and powered up in the morning - will the unix maintenance scripts run at power up?

On modern versions of macOS, all of this logic is managed via the launchd system. Look at the manual page (run "man launchd.plist" in the Terminal) to see the definition of "StartCalendarInterval":

This optional key causes the job to be started every calendar interval as specified. Missing arguments are considered to be wildcard. The semantics are similar to crontab(5) in how firing dates are specified. Multiple dictionaries may be specified in an array to schedule multiple calendar intervals.

Unlike cron which skips job invocations when the computer is asleep, launchd will start the job the next time the computer wakes up.  If multiple intervals transpire before the computer is woken, those events will be coalesced into one event upon wake from sleep.

You can see where this key is used by running "grep StartCalendarInterval /System/Library/Launch*/*" in the Terminal.

For the past several years, macOS has used a new "Unified" logging system that stores data in a variety of SQLite databases. You can access the contents via the "log" command line. But I recommend you don't do that. The modern macOS approach to system "maintenance" is not to do it at all. So if you start diving deep and exploring, you had better be prepared for literally hundreds of thousands of random frameworks, resources, log files, text files, databases, AI models, in addition to some scary-sounding stuff. I've seen more than more person literally lose their minds looking at that stuff.

For several releases of macOS (measured in years), the operating system performs the periodic functions at 3 am or the first boot of your Mac in the morning as normal housekeeping tasks. The command line version of the periodic command was unnecessary and Apple has finally removed it.

And because Apple is free to do anything they want with the operating system, you may not find /System/Library/LaunchAgents or /System/Library/LaunchDaemons that bear any naming convention now to suggest that its function is a scheduled periodic StartCalendarInterval key setting. One test would be to look at the process table when the Mac first boots to see if anything is performing a periodic function, but there may not be if Apple has altered its name or function.

Manually invoking those tasks has not been required for about two decades. Neither for that matter is ensuring your Mac is on during certain times or the day, nor is routine rebooting, etc. None of that is required.

Your followup comments implies something isn't right though. If you have reason to believe your Mac isn't running as it should, by all means write back.

In order to obtain 'proof' and 'verify'. Then you need to learn all about Unified Logs. It is an advanced skillset.

The files in /var/log are only part of it. The vast majority of logging is going on in the Unified Logs. The Unified Log is accessed via the Console app or the command line 'log' command. The problem is the macOS logs are very noisy with debug messages, while useful for developers, it makes it harder for a regular user to spot useful things in the logs. You'll need to learn how to query and filter to find what you are looking for. But you'll also have to reverse engineer what Apple has done internally to know what to look for in the logs.

To learn more about logging here's some resources:

Console User Guide for Mac - Apple Support

https://cloud.google.com/blog/topics/threat-intelligence/reviewing-macos-unified-logs

https://www.kandji.io/blog/mac-logging-and-the-log-command-a-guide-for-apple-admins

https://www.crowdstrike.com/en-us/blog/how-to-leverage-apple-unified-log-for-incident-response/

Howard Oakley's blog, The Eclectic Light Company has a lot of extremely useful information about logging as well as many other topics. He's written utilities to help make it easier to find stuff in the logs. Check his other blog entries, the man spends a lot of time reverse engineering and documenting what he finds.

Log literacy: an essential skill for advanced users

Log literacy: Reducing log entries shown

Log Literacy: Navigation

Log literacy: all about the log

Log literacy: the power of message types, and Ulbow 1.10

Log Literacy: Extending Ulbow with predicates, filters & styles

Log Literacy: Hunting bugs with Ulbow’s Chart View

Log Literacy: How to make and use logarchives

Removing privacy censorship from the log

These blogs are nice, they show how an engineer uses the logs:

Analysis of Apple Unified Logs: Quarantine Edition [Entry 1] – Converting Log Archive Files on 10.15 (Catalina)

Analysis of Apple Unified Logs: Quarantine Edition [Entry 2] – sudo make me a sandwich

Analysis of Apple Unified Logs: Quarantine Edition [Entry 3] – Playing in the Sandbox, Enumerating Files and Directories

Analysis of Apple Unified Logs: Quarantine Edition [Entry 4] – It’s Login Week!

Analysis of Apple Unified Logs: Quarantine Edition [Entry 5] – Login Inception!? Yes! – Local Logins!

Analysis of Apple Unified Logs: Quarantine Edition [Entry 6] – Working From Home? Remote Logins

Analysis of Apple Unified Logs: Quarantine Edition [Entry 7] – Exploring USBMSC devices with --style

Analysis of Apple Unified Logs: Quarantine Edition [Entry 8] – Man! What a process!?

Analysis of Apple Unified Logs: Quarantine Edition [Entry 9] – We all know you're binging Netflix! Now Playing on your Apple Devices!

Analysis of Apple Unified Logs: Quarantine Edition [Entry 10] – You down with TCC? Yea, you know me! Tracking App Permissions and the TCC APOLLO Module

Analysis of Apple Unified Logs: Quarantine Edition [Entry 11] – AirDropping Some Knowledge

Analysis of Apple Unified Logs [Entry 12] – Quick & Easy Unified Log Collection from iOS Devices for Testing

Or you can take a step back and realize the Mac is working fine.

TheGoldenKnight wrote:

Unfortunately, I have no idea what I'm looking at - yet. I see no "daily", "weekly", or "monthly".

Here's what I see when I look in /var/log on a Mac running Sonoma. That's what I have access to right now, not one on Sequoia, but this /var/log folder has looked similar for many years, so I hope the Sequoia one looks similar:

Note the files DAILY.OUT, WEEKLY.OUT, MONTHLY.OUT. Those are produced when those maintenance procedures are run. By looking at the dates, one can see they are running recently as one might expect. You can also look into them with a text editor but I don't understand what is inside those files, but it appears to be some sort of record of what they were doing.

But as others with a lot more experience than me here have already pointed out, there are MANY other maintenance procedures running behind the scenes on your Mac. Maybe many dozens, possibly over a hundred. SO it's not clear to me why you are focusing on just these there. And as I and others pointed out, the panacea of resetting PRAM or SMC on modern Macs is no longer even possible, the hardware architecture has changed so one cannot even do that anymore.

It has been many years since a user could just run maintenance scripts or clear PRAM or SMC to "fix" their Macs. I feel like those were more like panaceas anyway, the most common fix to most issues is simply restarting one's Mac. Maybe SOMETIMES it helps to start in safe mode because that could clear out a corrupted cache file, but even that is a long shot nowadays.

It would be better to open a new thread and provide details about the actual issues you have experienced. For example, unexpected quits of Safari are being caused by SOMETHING. I spend a lot of time reading these forms, mostly to get educated and be a more knowledgable Mac user, and the most common cause I have seen for such unexpected quits or freezes is something that the user has installed. It won't always be obvious because sometimes it was installed years ago, back multiple versions of the MacOS.

As others suggested, downloading Etrecheck and posting its report here will possibly help the diagnosis, it's an anonymous report but provides a lot of information about the configuration and what is installed. See this (link provided below) for how to post an Etrecheck report. Etresoft, one of the people who responded to you earlier, created Etrecheck years ago and it has helped scores of users resolve odd problems that are hard to diagnose. It is a free program but I have a paid up version because I believe that one should support those who take the time to create such useful tools.

How to use the Add Text Feature When Post… - Apple Community

Yes, it appears that the periodic command is no longer available in Sequoia.

However, I believe that this has not been a problem for quite some time now, as in case it had been asleep at the scheduled time, your mac would run these tasks when later woken up.

In the Finder, under the Go menu, select Go to folder ... and type in the box

/var/log

That folder is in a private area that Apple sets up to prevent users from changing anything in there, but you can certainly view what is there and view what is inside the log files there. Look for files with names like DAILY, WEEKLY, MONTHLY and look to see their dates, which may be indicative of when they are created or modified. Since you seem to be interested in general maintenance processes of the Mac, there are many other files in there that you can inspect as well. Again, I would guard against deleting or changing anything, however. Older logs are also archived there, you can even look in those.

Well, my problem is I see no verification that any maintenance measures are ever running.

The proof you seek is a Mac that's running well.

macOS archives, rotates, and deletes its log files periodically. If you have reason to believe that isn't happening, then by all means provide those details. Otherwise you will just drive yourself insane looking for trouble when there is none to be found.

There is a reason for my question. I happen to know that certain notorious "cleaning" scam products can absolutely cause a Mac to run poorly even after those products were completely and correctly removed. The cause was deliberately removing (i.e. "cleaning") certain files that macOS expects to be present even in the user space. If they are not present in their expected locations and formats macOS expects them to be, things break.

But if your Mac is running well, then there is no justification for verifying it's working the way Apple designed it to work. The reason for periodic is rooted in macOS antiquity and hasn't been required for years.

macOS performs copious maintenance tasks. Are you going to verify all of them? Which ones? Will you be doing the same with your iPhone / iPad? After all iOS does most of the same things macOS does. Do you trust them?

You can look inside this directory:

/var/log

I suggest LOOKING but not modifying anything there. You will see files created when the periodic scripts run. They are log files and have names like DAILY, WEEKLY, MONTHLY, etc. You can view their contents. On my Mac they run regularly but not always in the middle of the night. So clearly the MacOS has changed the way these scripts are handled.

TheGoldenKnight wrote:

My thought is what happens when the portion of the OS or Mac itself responsible for running these malfunctions?

What makes you think they are malfunctioning. We have Macs that range in age from < 1 year to as old as 14 years old. None of us has ever manually run those scripts in all that time. I checked that directory on each one and can see that the regular maintenance scripts are running automatically daily, weekly, monthly, etc. on all those Macs, old and new.

It seems you want to be able to "do" things to your Mac maintenance-wise, but the MacOS has been evolving so as to make it unnecessary or even impossible to "do" those things anymore. Because they are no longer necessary to be executed manually with modern Macs. If you want to have a more hands on approach for you Mac, you should explore writing software and coding or something that might be more productive than trying to find ways to "maintain" your Mac.

TheGoldenKnight wrote:

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.

You are living in the past. Modern Macs (Silicon) do not have a way to zap PRAM manually to my knowledge, it effectively does that upon each startup. And modern Silicon Macs don't have an SMC to reset. If your MacOS is damaged such that it stops running maintenance scripts, you should probably reinstall the MacOS. I think you are trying to "fix" something that is not broken, or trying to use techniques from the past.

When the locate command is executed in the Terminal it will display the following if it's not enabled.

WARNING: The locate database (/var/db/locate.database) does not exist.

To create the database, run the following command:

sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.locate.plist

Please be aware that the database can take some time to generate; once the database has been created, this message will no longer appear.

I could not find any official document saying so, but it seems that this has been the case for a very long time, apparently since the days of Leopard, or Snow Leopard.

If I find any official documentation about this, I will post the link here.