3

I have a machine on which I do not want finder to run, so initially I made it unexecutable:

sudo chmod -R a-x /System/Library/CoreServices/Finder.app

But then realised that launchd was still trying to launch finder multiple times every second, resulting in colossal log files consisiting of millions of lines of:

com.apple.launchd.peruser.502[109] (com.apple.Finder[93799]) <Error>: posix_spawn("/System/Library/CoreServices/Finder.app/Contents/MacOS/Finder", ...): Permission denied
com.apple.launchd.peruser.502[109] (com.apple.Finder[93799]) <Warning>: Exited with exit code: 1

So I edited /System/Library/LaunchAgents/com.apple.Finder.plist so that it would not launch anymore. The problem I have now is forcing launchd to reload the plist, and therefore stop trying to launch finder. However, I cannot restart the machine.

I have tried using launchctl to both remove and unload the process but that doesn't appear to work:

$ sudo launchctl unload -w /System/Library/LaunchAgents/com.apple.Finder.plist 
launchctl: Error unloading: com.apple.Finder
$ sudo launchctl remove com.apple.Finder
launchctl remove error: No such process

Is there anyway I can stop launchd continuously trying to load finder without restarting the machine?

DanielGibbs
  • 573
  • 5
  • 12
  • 31
  • Why don't you want Finder to run? Wouldn't it be better just to leave the machine at the login screen? – Neil Mayhew Jul 06 '11 at 03:53
  • It is an internet kiosk, and it is much harder to exploit if Finder is not running. – DanielGibbs Jul 06 '11 at 22:43
  • 1
    Good point. You could try to run your kiosk application as if it was the Finder, maybe by making /System/Library/CoreServices/Finder.app a symlink to it. – Neil Mayhew Jul 07 '11 at 04:06

6 Answers6

2

Finder is a LaunchAgent, not a LaunchDaemon, which means it's loaded as part of your login session. Either use launchctl unload without sudo, or just log out & back in.

Gordon Davisson
  • 11,036
  • 3
  • 27
  • 33
  • I can not log out and back in as I only have remote access via SSH. I have tried `launchctl unload` and `sudo -u [user] launchctl unload` where [user] is the user with Finder trying to run, but the first gets `launchctl: Error unloading: com.apple.Finder` and the second gets `Bug: launchctl.c:2325 (23930):13: (dbfd = open(g_job_overrides_db_path, O_RDONLY | O_EXLOCK | O_CREAT, S_IRUSR | S_IWUSR)) != -1` – DanielGibbs Jul 07 '11 at 02:56
  • Are you ssh'ing in as the same user that's running Finder? – Gordon Davisson Jul 07 '11 at 03:01
  • No, that user doesn't have an SSH login for security reasons. – DanielGibbs Jul 07 '11 at 03:15
  • There's probably an easier way, but try this: get the PID of the Finder you're trying to kill, and then run `sudo launchctl bsexec [FinderPID] sudo -u [user] launchctl unload /System/Library/LaunchAgents/com.apple.Finder.plist` If you didn't parse all that, what it does is become root (the first `sudo`), switch to the same mach bootstrap context as the Finder (`launchctl bsexec [FinderPID]`), then become the same user as the Finder (`sudo -u [user]`), then unload the agent (`launchctl unload ...`). – Gordon Davisson Jul 07 '11 at 03:26
  • Finder isn't actually running though, it keeps trying to via launchd, but doesn't actually run. – DanielGibbs Jul 07 '11 at 03:49
  • Oh, that's right. Then find another process running as part of the login session that Finder *would* be part of, and use that PID instead. – Gordon Davisson Jul 07 '11 at 03:56
  • I've been able to use launchctl from ssh on jobs that are running from the console, so I don't think the mach bs context matters. – Neil Mayhew Jul 07 '11 at 04:14
  • Done! I used `sudo kill -9 \`sudo launchctl list | grep peruser.502 | cut -f1\`` and that appears to work perfectly. Thanks heaps Gordon, and Neil for your help. Maybe put this as a separate answer? – DanielGibbs Jul 07 '11 at 04:18
  • 1
    Killing the user launchd process may have other ... implications. I don't think I'd make this the recommended way of doing it. – Gordon Davisson Jul 07 '11 at 04:29
  • 1
    I agree. Killing the entire launchd process is very heavy-handed. Although that worked in this particular situation, I don't think it should be put forward as THE solution. – Neil Mayhew Jul 11 '11 at 01:07
1

Your log shows that Finder is being run for user 502, but you are running launchctl with sudo, and root isn't running a Finder. Try the launchctl unload without sudo.

Neil Mayhew
  • 121
  • 4
  • I have tried `launchctl unload` and `sudo -u [user] launchctl unload` where [user] is the user with Finder trying to run, but the first gets `launchctl: Error unloading: com.apple.Finder` and the second gets `Bug: launchctl.c:2325 (23930):13: (dbfd = open(g_job_overrides_db_path, O_RDONLY | O_EXLOCK | O_CREAT, S_IRUSR | S_IWUSR)) != -1` – DanielGibbs Jul 07 '11 at 02:56
1

As Gordon said, you need to execute your launchctl unload ... command in the same mach bootstrap context of the user. launchctl itself has a facility to do this via bsexec, you just need to provide it a PID of any process running in that user context, Finder isn't running so pick a different one. The user-relative root process is loginwindow console, so this makes the most sense:

USERNAME=yourusername;export USERNAME; sudo launchctl bsexec "$(ps auxww | grep loginwindow\ console | grep "$USERNAME" | grep -v grep | awk '{print $2}')" sudo -u "$USERNAME" launchctl unload -wF /System/Library/LaunchAgents/com.apple.Finder.plist 

replace yourusername with the username you're affecting and voila.

1

System
Mac OS X, version: 10.6.8 (Snow Leopard)

Task
I wanted to prohibit, mostly the initial auto-starting but also, the automatic re-launching of the Finder (as a "simple" fix for decrypting encrypted disks) before the Finder would try (and fail) to load (and in that process discard) it's old (preferences'd) list of previous open locations..

Reliability
I seldom restart my computer (and haven't had any much crashes with the Finder) so
i haven't gotten to see the effect of this configuration (that feels more like a hack) that many times.

I also see now that i haven't backed my original up so i cannot see exactly what changes i've made.

Procedure
Anyhow, it seems that the re-launching is removed (as expected) by setting <key>KeepAlive</key> in the Finder's launchctl(1)/launchd(8) property list to <false/>;
But, setting the <key>RunAtLoad</key> (again, to <false/>) seems to have no effect (on the Finder as it probably is started ~hardcoded”).

On a side-note I can say that creating a LaunchAgent - for/with any other regular application - with <key>RunAtLoad</key> set to <true/> works great if you, like I, have an app (share-service) that crashes often.


References

  • file:///System/Library/LaunchAgents/com.apple.Finder.plist
  • The list of property list directives i was looking for i found referenced (appropriately enough) as the
    launchd.plist(5) manual page at Apple's technical note #2083 on the subject (2011-12-28: "Last updated: 2007-11-05")

And a little utility
If i may recommend a graphical application for these LaunchAgents/LaunchDaemons configuring tasks i'd like to promote (without any affiliation, other than developing nationality) Lingon (note the different (Snow) Leopard and Lion versions).


Finally
Sorry for the long post on this rather trivial issue.
Hope most of this is still true in version 10.7 Lion as well. Though the Finder's behaviour could be better (somehow, suggestivly not totaly discarding unreacahble locations) in line with "Resume" Lion feature along with "Auto Save"..
Now i just still have one other little mac thing (file sizes) to comment on at unix.stackexchange).

vike
  • 163
  • 4
0

The error message given in some of the comments:

Bug: launchctl.c:2325 (23930):13: (dbfd = open(g_job_overrides_db_path, O_RDONLY | O_EXLOCK | O_CREAT, S_IRUSR | S_IWUSR)) != -1

shows that launchctl is trying to open a file and failing. This could be due to permissions, but that seems unlikely, given the use of sudo -u. Much more likely is something related to the O_EXLOCK flag. Presumably launchd locks the database when starting a job, perhaps to check if the job is disabled, and it's retrying the job so frequently that the database file is locked most of the time.

Running a loop that continually tries to unload the job should eventually get in when launchd doesn't have the file locked:

for ((i = 0; i < 100; i++))
do
    echo -n "$i "
    launchctl unload ... && break
done

I know that unloading a job from ssh normally works, because I've done it many times, so I think the problem must be due to the frequency of the failure/reload cycle.

Neil Mayhew
  • 121
  • 4
0

I get what you're trying to do, but you're going about it entirely the wrong way.

Use the Parental Controls to set up a restricted account. Set it to use the Simple Finder.

bahamat
  • 6,193
  • 23
  • 28