5

I'm using OS X Yosemite, just updated to 10.10.3 and the at command and related (atq, atrm etc) have stopped working. Has atd been disabled in the latest 10.10.3? If so how do I investigate and reenable the required permissions?

~$ atq
atq: cannot regain privs: Operation not permitted

As background, I have a job that runs daily (using launchd) and submits a list of jobs to atd. The list of jobs are related to events occurring that day so they change times daily. So I use atd to run these jobs based on the daily event times.

It has been working fine up until the recent upgrade to 10.10.3.

/usr/libexec/atrun is enabled and running fine, according to launchd.

3
  • Seems a bug (I can reproduce it on several machines)
    – Matteo
    Commented Apr 16, 2015 at 8:04
  • Is it a bug ... or a "security feature"? Commented Apr 17, 2015 at 4:54
  • 1
    Again Linux/UNIX 'at' is designed to submit a background job running as the submitting user. The binary /usr/bin/at is SUID root!
    – mdpc
    Commented May 29, 2015 at 22:58

2 Answers 2

2

That message suggests that you don't have the correct privileges to run atq. Try running it with sudo from the command line to see if that helps i.e.:

> atq
atq: cannot regain privs: Operation not permitted
> sudo atq
Password:
>
5
  • 1
    Yes it works using sudo. However I am submitting jobs from a bash script so I can't use sudo as I can't provide a password from the script. I don't understand why I don't have permissions now. It used to work before the upgrade. /var/at/at.deny is empty and I added /var/at/at.allow with my username. That doesn't work though.
    – alpatters
    Commented Apr 17, 2015 at 12:10
  • You can run the parent script with sudo if you're kicking it off manually, or you can run it as root via cron. Apple occasionally upgrades the permissions needed to run some command line tools. For example xcodebuild was originally all available to users, but then in one Xcode upgrade the --switch flag started requiring sudo.
    – Ɱark Ƭ
    Commented Apr 17, 2015 at 12:29
  • The 'at' command is SUID to root and really should NOT require root privs UNLESS you are submitting an at job to be run as root and not a specific user.
    – mdpc
    Commented May 29, 2015 at 22:57
  • @mdpc I agree and it used to work like that just fine until the 10.10.3 update. Now I am not able to run it as my normal user account, even though I added that to at.allow and it's not in at.deny. I can see nothing wrong with my setup (that used to work fine).
    – alpatters
    Commented Jun 2, 2015 at 7:26
  • I have experiemented with this a little more, and what I found is that at root, all that is simply done is just put the job in the "jobs" queue where it basically remains forever. Thus you can do the 'at' and a job is indeed created just NEVER run (OSX 10.10.3).
    – mdpc
    Commented Jun 3, 2015 at 2:30
1

I just installed the 10.10.4 update from Apple today.

I noticed that the at command works. But that is not all you have to do to enable the service. What you have to do is to edit the /System/Library/LaunchDaemons/com.apple.atrun.plist and change the "true" to "false" after the disabled XML section. Then you can use command

 launchctl load /System/Library/LaunchDaemons/com.apple.atrun.plist

to start it up.

You must log in to answer this question.

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