problem posts

Openrsync issues resolved (I hope)

I think I have finally worked through and fixed the issues caused by Mac OS 15.4 switching from rsync to openrsync. With the switch, many of my backup and other rsync scripts broke, throwing errors and not finishing the sync. As of that last post, I had gotten things mostly working, but had to disable incremental snapshotting and still sometimes had failures that I had to deal with.

Some of the errors I’ve had include:

… copy_file dfd: openat: Too many open files …
… empty link …
… error: unexpected end of file …
… No such file or directory …
… opendir … failed: Interrupted system call …

For Too many open files, I had to reduce the file count in my really gigantic backups. Instead of backup up the entire /Users directory, I made a loop to do each user separately. I also excluded various cache directories and the like that have lots of files that aren’t important for a backup. It took searching and repeated runs to find and add enough such folders to the list. These include:

rsync … \
--exclude '.brew' \
--exclude '.cache' \
--exclude '.node-gyp' \
--exclude '.npm' \
--exclude '.pnpm-store' \
--exclude '.sass-cache' \
--exclude 'node_modules' \
--exclude 'Data/Library/Caches/' \
--exclude '/Library/Application Support/Adobe/Fireworks CS6' \
--exclude '/Library/Application Support/Amazon Music' \
--exclude '/Library/Application Support/Firefox/Profiles/*/storage' \
--exclude '/Library/Application Support/Chromium/*/Service Worker/CacheStorage' \
--exclude '/Library/Metadata/CoreSpotlight' \
--exclude '/Library/Caches' \
--exclude '/Library/Cookies' \
--exclude '/Library/Logs' \
…

For unexpected end of file, I had to add the --inplace option. I think this has some risks to it. The man page mentions possible issues with hard links: Not sure if that relates to the --link-dest option and if it may cause overwrites of previous snapshots or anything like that. But I needed it for the incremental snapshots to work at all.

For Interrupted system call, there were certain folders, mostly in user library folders, that I found I needed to exclude. The error message unfortunately gave no hint to where the error happened in the filesystem, so I had to do a time consuming process to find the problem files. I excluded large folders until things worked and then added back items within those until I had added back what wasn’t causing the error, up to the amount of time I was willing to spend going deeper or when I was dealing with folders whose content didn’t matter for backup. I don’t remember all of them, but I believe they included:

rsync … \
--exclude '/Applications' \
--exclude '/Library/Application Support/iTerm2' \
--exclude '/Library/Containers/com.apple.Safari/Data/Library/Caches' \
--exclude '/Previously Relocated Items*' \
…

As mentioned in the previous post, for empty link, I had to remove or exclude symlinks that weren’t pointing anywhere. Some of those were for stuff that does point to something when shared with a virtual machine, which had to be excluded. Others were simply links whose originals must’ve been removed at some point or whatever, and could be removed without issue.

For many use cases, using the homebrew version of rsync (brew install rsync) will be the normal version and not have these issues. But I don’t want to run homebrew stuff with my root user, and I need to use the root user to broadly back up all of my users’ data at once.

I’m not sure why Apple had to switch to openrsync, and I’m not sure why openrsync has so many troubles that regular rsync doesn’t. It took up a fair amount of my time and frustration to get things fully working again. But I’m glad I seem to have solved the issues.


Candle incident

Yesterday evening, I lit a candle while watching an episode of Columbo. It’s one of those fat kinds that develops a wall of wax around the outside. Previously, a hole had formed in the wall and some wax had dripped out. I had fixed the hole, but there were still some hunks of this wax left. So I put one in the candle wall yesterday, leaned up against it, hoping it would slowly melt away.

This morning, I woke up and thought to myself that I didn’t remember putting out the candle.

Continue reading post "Candle incident"

Doing my federal (US) taxes this year, I was finding myself unable to create an account on the Free Fillable Forms site. I kept getting kicked back to the start after filling out and submitting my information. This Reddit thread led me to figure out that it was related to my T-Mobile Home Internet. I turned that off and turned on my phone hotspot and used that to get in. My phone is also T-Mobile, but apparently different enough to not have that issue. Later, I was able to get back in with my Home Internet, so it seems to be just related to something on that initial registration process.


Low oil

Last Monday, my car’s (Subaru Impreza) low oil light came on while I was driving down the highway. I didn’t know what the light was and nothing sounded wrong so I kept driving. When I got to my parents’, I looked up the symbol and then learned it was probably not a good idea for me to have kept going. Luckily, no harm seems to have been done.

Continue reading post "Low oil"

In January, I made another of my cinnamon roll cheesecake’s. I was in a rush and did not let it set in the fridge at all. And it really came out as a gooey circle of glop. The center sunk in and it was hard to serve. Really wouldn’t have been presentable if it weren’t just to my close family. I’ve learned how important that setting is for cheesecake.

However, it was still quite tasty. It was huge for four people, but it did eventually get eaten over a week-long period.

This one had three changes from normal. One, I mixed in most of the cinnamon crumble to the main batter in the mixer. I think this just turned out better and I will probably do it again. Two, I used duck eggs instead of chicken eggs. That was all Whole Foods had in a six pack at the time. They were expensive too, more expensive than the dozen chicken eggs, but I didn’t want to waste any. Three, I didn’t put the frosting on top because I was in such a rush that I didn’t have time to make it.


xz backdoor

Reading this weekend about a backdoor introduced to the open source xz project. It doesn’t appear to affect my Ubuntu servers, so I had assumed it wasn’t relevant to me. However, the homebrew version on my Mac was “vulnerable”. It sounds like the exploit would only work on some versions of Linux, but if it does work on Macs, that could be bad. I do a lot of stuff on this computer, including banking, email, coding, etc. They know about it backdooring ssh, but if there’s something they don’t yet know about, it might be a problem.

I have a Fedora install as well. I haven’t checked it yet, but Fedora is usually on the bleeding edge, so if it’s on there, I’ll probably wipe and reinstall. I’ve been considering anyway. Luckily, I don’t do anything important on there.

Even if it didn’t actually do anything bad on the Mac, it may have done something. I had noticed some weeks or months ago (I can’t remember when) that running PHP on the command line was going slow. Running anything would take a minimum of about five seconds, including something simple like php -r 'echo "hello\n";'. I know when I had been making scripts in the past they hadn’t been taking long at all. I did some searches on the web for anybody mentioning something like that and couldn’t find anything. So I kinda just figured maybe it had something to do with the new opcode / whatever cacheing newer versions do or something, like it takes some initial setup that the server can reuse but not the command line. I assumed I was stuck with it and even started moving some scripts to bash partly because of it. When I downgraded xz via homebrew though, I decided to test it. time says the simple php -r line took 0.092 seconds. Nice and snappy. So maybe xz was doing some checks to see if the device was exploitable. It was in the dependency graph of PHP through curl and gd. Can’t say for sure that it just sped up though and if the xz change was what caused it.

I’m glad my scripts finally run quickly again, but hope that nothing was exploited here. I’ll keep an eye on the web to see if anything comes up about Macs being exploitable, and if so I’ll probably reinstall the OS to be safe.

Note: If you have used homewbrew to install PHP, curl, or anything else that might depend on xz, run brew update; brew upgrade to be safe. The dangers of being on the bleeding edge I guess.