0

The "sweep" daemon job that I developed in Is there an easy way to automatically schedule a move of files matching a certain pattern from a user directory to a USB drive? and What went wrong with my launchd plist? seems to be working just fine. The last time it actually had files to transfer to the external drives was yesterday morning; this morning, it had no actual work to do, so I don't know whether it ran or not.

This morning, I created another launchd plist ("backlocal," which backs up a couple of rarely-changed Samba shares every six months), and I did a launchd load on it just now, followed by a launchd list, to verify that it was loaded.

"backlocal" was indeed in the launchd list, but "sweep" was not (I immediately did a launchd load to manually reload it).

I don't know whether it ran this morning or not. All I do know is that if I bring up the console, and search "all messages" for "sweep," I get:

5/20/23 8:00:09.787 AM com.apple.xpc.launchd[1]: (sweep[3314]) Service exited with abnormal code: 1
5/21/23 8:00:05.558 AM com.apple.xpc.launchd[1]: (sweep[3573]) Service exited with abnormal code: 1
5/22/23 8:00:05.744 AM com.apple.xpc.launchd[1]: (sweep[3828]) Service exited with abnormal code: 1
5/23/23 8:00:15.388 AM com.apple.xpc.launchd[1]: (sweep[590]) Service exited with abnormal code: 1

I took a look at a couple of threads that came up automatically when I entered the above log messages, What does "Service exited with abnormal code: 1" mean? and launchd notification on abnormal exit but I'm not sure if they have any bearing here.

Could these messages have something to do with my not seeing "sweep" in launchd load? I will note that "sweep" did successfully sweep a file to the external backup drives on the 23rd. I will also note that the most recent reboot was about Noon on Monday.

As of this moment, "sweep.plist" looks like:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>sweep</string>
<key>Program</key>
<string>/Users/europa/sweep.sh</string>
<key>StartCalendarInterval</key>
<dict>
<key>Hour</key>
<integer>8</integer>
<key>Minute</key>
<integer>0</integer>
</dict>
</dict>
</plist>

(but I'm about to add StandardOutPath and StandardErrorPath tags, as suggested by launchd.info), and sweep.sh looks like:

#!/bin/bash
cd /Users/mercury
cp *.savf /Volumes/BACKUP/mercury
mv *.savf /Volumes/BACKUP2/mercury

cd /Users/venus
cp *.savf /Volumes/BACKUP/venus
mv *.savf /Volumes/BACKUP2/venus
Improve this question
11
  • 1
    I assume your script name is "sweep," correct? The error message (and the links you supplied) are accurate; the script terminated with an error code of -1. That means launchd ran your script, but it failed and then exited. This could be for any number of reasons. To find out why, we need to see the script and ideally, you want to do some error trapping in your scripts to generate your own error codes so you know what failed and when.
    – Allan
    Commented May 24, 2023 at 21:13
  • @Allan: Thanks. I've just added the plist and shell script. I don't know anything about error trapping in bash; on the other hand, I could probably teach a class in how to do it in CL, on an IBM Midrange box!
    – hbquikcomjamesl
    Commented May 24, 2023 at 21:50
  • 1
    At the end of the script, and an exit 0 and see if that fixes it.
    – Allan
    Commented May 24, 2023 at 22:06
  • 1
    Yes. Any changes you make, it needs to be reloaded.
    – Allan
    Commented May 24, 2023 at 22:19
  • 1
    There may be another source of confusion here: when you run launchctl as a regular user (i.e. not root), many options (including load, unload, and list) interact with the list of that user's launch agents. To interact with the list of launch daemons, you need to run launchctl as root (e.g. with sudo launchctl ...).
    – Gordon Davisson
    Commented May 24, 2023 at 23:11

1 Answer 1

Reset to default
0

Turned out to be a false alarm. And based on what showed up in the the redirection files for stdout (nothing) and stderr (just complaints about nothing to copy or move) no doubt the log messages I'd seen were about that.

Improve this answer
4
  • As I stated in the comments above, some error checking would go a long way here. Checking that the volume exists to be written to and if files exist prior to the copy action would solve this issue of the script erroring out by giving it a path to exit cleanly (no error code)
    – Allan
    Commented May 26, 2023 at 15:20
  • @Allan: If I were to do anything to handle the case of the external drives spontaneously unmounting, or files colliding with each other on them (something I proactively prevent in the process that FTPs them onto the Mini in the first place, by renaming them with an embedded datestamp), I would want it to scream bloody murder, rather than just quietly ignoring the error.
    – hbquikcomjamesl
    Commented May 26, 2023 at 15:42
  • Error trapping can send messages to stderr or stdout that can notify you. The idea is error trapping doesn’t break other things but handles conditions gracefully.
    – Allan
    Commented May 26, 2023 at 15:54
  • Haven't bothered with error trapping, since as of yet, nothing stops the scripts from working, but I did add another script, one set to go off at 9:00 AM every day: it checks both external drives, by name, to see if they're present (I tested it both with unmounting the disk normally, and with unceremoniously disconnecting it; it detects the absence either way), and checks them to see if their free space has dropped below 100G, and if any of those conditions appears, it will speak up about it. Literally.
    – hbquikcomjamesl
    Commented May 26, 2023 at 21:26

Not the answer you're looking for? Browse other questions tagged .