GIMP will no longer launch

Discussion in 'Mac Apps and Mac App Store' started by Doctor Q, May 12, 2008.

  1. Doctor Q Administrator

    Doctor Q

    Staff Member

    Joined:
    Sep 19, 2002
    Location:
    Los Angeles
    #1
    In a classroom we installed GIMP (by dragging the executable into the Applications folder) on a bunch of Macs. We installed X11 too. GIMP worked on all Macs for a while, but now one Mac (and just one Mac) can no longer launch GIMP.

    Perhaps a student did something "funny" on this Mac, but I can't find evidence of that. Students do not have admin privileges.

    When you double-click it, it launches, appears for a split second in the menu bar and dock, and then immediately quits. There are no messages displayed. Restarting the Mac does not help. Repairing permissions does not help. Other applications can still be launched. The problem happens no matter who you log in as, either as a student or as an administrator.

    My next thought was to delete its preference and/or application support files, but I can't find any preference or application support files for GIMP.

    Just in case, I trashed X11 and GIMP and reinstalled them. The problem remained.

    What might be wrong? How might I gather more clues?
     
  2. yellow Moderator emeritus

    yellow

    Joined:
    Oct 21, 2003
    Location:
    Portland, OR
  3. Doctor Q thread starter Administrator

    Doctor Q

    Staff Member

    Joined:
    Sep 19, 2002
    Location:
    Los Angeles
    #3
    Code:
    [0x0-0x119119].org.gimp.Gimp[1956] /
    
    [0x0-0x119119].org.gimp.Gimp[1956] Could not get password database information for UID of current process: Failed to get groups for username "admin" primary GID 20: Unknown error: 0
    
    [0x0-0x119119].org.gimp.Gimp[1956] Failed to start message bus: Memory allocation failure in message bus
    
    [0x0-0x119119].org.gimp.Gimp[1956] EOF in dbus-launch reading address from bus daemon
    
    [0x0-0x119119].org.gimp.Gimp[1956] No matching processes belonging to you were found
     
  4. yellow Moderator emeritus

    yellow

    Joined:
    Oct 21, 2003
    Location:
    Portland, OR
    #4
    That looks to be from system.log or console.log, how about the crashlog (assuming there is one)?

    And does X11 start normally?
     
  5. Doctor Q thread starter Administrator

    Doctor Q

    Staff Member

    Joined:
    Sep 19, 2002
    Location:
    Los Angeles
    #5
    I think it's from the console log (this was from a week ago).

    I'll have to try it again and check crash.log.

    Yes. And the same problem happens if you launch X11 first, then GIMP. X11 is happy; GIMP isn't.
     
  6. Cromulent macrumors 603

    Cromulent

    Joined:
    Oct 2, 2006
    Location:
    The Land of Hope and Glory
    #6
    Did you update the machines to use the latest version of Xquartz? X11 on Leopard has serious issues. Plus are you running the latest builds of GIMP from here?
     
  7. Doctor Q thread starter Administrator

    Doctor Q

    Staff Member

    Joined:
    Sep 19, 2002
    Location:
    Los Angeles
    #7
    Don't know... will check.

    Don't know... will check.

    Thank you to both of you for the tips.
     
  8. yellow Moderator emeritus

    yellow

    Joined:
    Oct 21, 2003
    Location:
    Portland, OR
    #8
    If you login as an admin user, does Gimp start normally?
     
  9. Doctor Q thread starter Administrator

    Doctor Q

    Staff Member

    Joined:
    Sep 19, 2002
    Location:
    Los Angeles
    #9
    No. Admin has the same problem -- GIMP launches and insta-quits.

    The biggest clue is that it works fine on all of the other (identically installed) Macs, so presumabaly it doesn't need different software versions. There's just some bit of bad data somewhere.
     
  10. yellow Moderator emeritus

    yellow

    Joined:
    Oct 21, 2003
    Location:
    Portland, OR
    #10
    OK, I'll have to install it here to see what kinda detritus it leaves.

    What OS version was this again?
     
  11. Doctor Q thread starter Administrator

    Doctor Q

    Staff Member

    Joined:
    Sep 19, 2002
    Location:
    Los Angeles
    #11
    The latest Leopard. I'm heading to school right now to run experiments.
     
  12. Shadow macrumors 68000

    Shadow

    Joined:
    Feb 17, 2006
    Location:
    Keele, United Kingdom
    #12
    I'd also try running some other programs in X11 to see if its GIMP or X11 thats messing up.
     
  13. yellow Moderator emeritus

    yellow

    Joined:
    Oct 21, 2003
    Location:
    Portland, OR
    #13
    PPC or Intel?

    Q,

    There's a ~/Library/Application Support/Gimp/

    also, some mention of Gimp-related stuff in

    /Library/Caches/com.apple.LaunchServices-n.csstore

    So you might wanna remove those too.





    .
     
  14. Doctor Q thread starter Administrator

    Doctor Q

    Staff Member

    Joined:
    Sep 19, 2002
    Location:
    Los Angeles
    #14
    These are 2006 Intel iMacs.

    It's the latest X11 (2.2.1) and the latest Gimp (2.4.5).

    Nothing gets written to the crash log when Gimp insta-quits upon launch, but I did find two more lines in the console log preceding those I show above:
    Code:
    rm: /tmp/skl/Gimp.app: Permission denied
    ln: /tmp/skl/Gimp.app/Gimp.app: Permission denied
    Something is trying to unlink Gimp? :confused:

    If all else fails, I can restore the iMac from the original installation disk image and apply changes we've made since then, but I was hoping to avoid that and to educate myself too.

    Students were taking tests today, so I couldn't get much hands-on time. Next time I'll check for ~/Library/Application Support/Gimp/ (which I didn't see previously when I looked for preference or application support files) and /Library/Caches/com.apple.LaunchServices-n.csstore. And I'll try another X11 app.

    Thanks.
     
  15. yellow Moderator emeritus

    yellow

    Joined:
    Oct 21, 2003
    Location:
    Portland, OR
    #15
    Sorry, where n is a random(ish) number. I left that out..

    Interestingly enough, in my /tmp I have:

    Code:
    null:~ yellow$ ls -laF /private/tmp | grep skl
    drwxr-xr-x    3 yellow  wheel   102 May 13 12:29 skl/
    null:~ yellow$ ls -laF /private/tmp/skl
    total 8
    drwxr-xr-x    3 yellow  wheel   102 May 13 12:29 ./
    drwxrwxrwt  233 root    wheel  7922 May 13 13:49 ../
    lrwxr-xr-x    1 yellow  wheel    22 May 13 12:29 Gimp.app@ -> /Applications/Gimp.app
    
    Perhaps someone moved the Gimp.app and gimp wanted to remove the bad link and relink but cannot without being an admin or sudoing, or that it's owned by someone else that isn't part of the student group (wheel?) and they cannot effect any changes to it? Seems POSIX related.

    Try removing that tmp folder altogether by hand and then running Gimp.app?

    The tmp folder was re-created when I ran Gimp again.
     
  16. Doctor Q thread starter Administrator

    Doctor Q

    Staff Member

    Joined:
    Sep 19, 2002
    Location:
    Los Angeles
    #16
    Removing ~/Library/Application Support/Gimp/ and /Library/Caches/com.apple.LaunchServices-*.csstore does not help.

    Other X11 apps, like xcalc and xeyes, run just fine, either launched from within xterm or double-clicked. But Gimp is a different kind of animal, packaged as a real Mac application, so maybe I need to try some other *.app-style X11 application. Which one might be a good choice?

    I have the same files in /tmp that you saw, and I see them being recreated if I trash them and try to launch Gimp.

    Three more clues:
    1. Gimp fails whether or not you pre-launch X11, and when Gimp doesn't work it doesn't launch X11.
    2. Another Mac in the classroom has now "gone bad" and won't launch Gimp. That means that students, who do not have admin access, are able to do something that makes gimp stop working. The two Macs that have this problem were used by different students.
    3. We are using portable home directories, so each user's files are synced between their Mac and the server each time they log in or out. I don't know why this would be a factor, but it's worth noting. However, where Gimp doesn't work for students, it doesn't work for admin either, and admin has a local (non-portable) home directory.
    I checked all of the directories we've mentioned here for ACLs. None of them have any. Only UNIX permissions, which shouldn't differ between a good Mac and a bad Mac.

    I may need to do some directory-by-directory and file-by-file comparisons between machines.
     
  17. tersono macrumors 68000

    tersono

    Joined:
    Jan 18, 2005
    Location:
    UK
    #17
    I don't have GIMP installed on here at present, so can't check right now, but if memory serves, GIMP creates an invisible directory at the root level of your home directory - and may also do the same elsewhere. Unlike native OS X apps, if the hidden pref file gets corrupted, Gimp will not re-create, it just dies.

    Worth having a hunt around with dotfiles visible (Tinkertool can turn that on for you, or use something like Pathfinder).
     
  18. Gentile macrumors regular

    Gentile

    Joined:
    Apr 29, 2007
    Location:
    Ohio
    #18
    How about uninstalling both Gimp and X11 on the one imac using something like Appdelete. Then reinstalling them.
     
  19. yellow Moderator emeritus

    yellow

    Joined:
    Oct 21, 2003
    Location:
    Portland, OR
    #19
    Odd...

    Code:
    sudo fs_usage -f -w Gimp.app > ~/Desktop/GimpOutput.txt
    Then run Gimp and maybe this will help up pinpoint where it fails. Of course, Cntl-C it to stop it. Beware, this file will grow and grow quickly.
     
  20. chambers macrumors newbie

    Joined:
    May 28, 2008
    #20
    Hi

    not sure if you still having problems with this, but i was having the same problem. i could install gimp on our power pc macs fine, however, when i installed X11 and gimp on our intel macs the same thing would happen to me where it would start and shut down instantly.

    i ran a software update for X11 and gimp ran straight away. not sure if you've tried this but it worked for me so thought i'd run it by you.

    good luck
     
  21. Doctor Q thread starter Administrator

    Doctor Q

    Staff Member

    Joined:
    Sep 19, 2002
    Location:
    Los Angeles
    #21
    I'm still fighting this problem. What version of X11 did you update to, chambers?

    * * *

    I checked some other settings and tried some other experiments.

    1. In X11 we get the bash-3.2 shell, with a path of /usr/bin /bin /usr/sbin /sbin.

    2. The command
    Code:
    open -a Gimp.app
    in an X11 shell launches and immediately quits Gimp, just as launching from the Finder does.

    3. If I log in as a brand new user (not having used the Mac before), the Gimp problem still occurs.

    4. Leopard Server manages preferences for these computers, so I tried releasing a Mac from managed preferences. I'm not sure if I really untangled all dependencies on the server, but the Mac still had the same problem with Gimp.

    5. Running fs_usage showed that the process is accessing some "interesting" files. Among them is file /Applications/Gimp.app/Contents/Resources/etc/dbus-1/session.conf, whose contents are this:
    Code:
    <!-- This configuration file controls the per-user-login-session message bus.
         Add a session-local.conf and edit that rather than changing this 
         file directly. -->
    
    <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
     "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
    <busconfig>
      <!-- Our well-known bus type, don't change this -->
      <type>session</type>
    
      <listen>unix:tmpdir=/tmp</listen>
    
      <standard_session_servicedirs />
    
      <policy context="default">
        <!-- Allow everything to be sent -->
        <allow send_destination="*" eavesdrop="true"/>
        <!-- Allow everything to be received -->
        <allow eavesdrop="true"/>
        <!-- Allow anyone to own anything -->
        <allow own="*"/>
      </policy>
    
      <!-- Config files are placed here that among other things, 
           further restrict the above policy for specific services. -->
      <includedir>session.d</includedir>
    
      <!-- This is included last so local configuration can override what's 
           in this standard file -->
      <include ignore_missing="yes">session-local.conf</include>
    
      <include if_selinux_enabled="yes" selinux_root_relative="yes">contexts/dbus_contexts</include>
    
      <!-- For the session bus, override the default relatively-low limits 
           with essentially infinite limits, since the bus is just running 
           as the user anyway, using up bus resources is not something we need 
           to worry about. In some cases, we do set the limits lower than 
           "all available memory" if exceeding the limit is almost certainly a bug, 
           having the bus enforce a limit is nicer than a huge memory leak. But the 
           intent is that these limits should never be hit. -->
    
      <!-- the memory limits are 1G instead of say 4G because they can't exceed 32-bit signed int max -->
      <limit name="max_incoming_bytes">1000000000</limit>
      <limit name="max_outgoing_bytes">1000000000</limit>
      <limit name="max_message_size">1000000000</limit>
      <limit name="service_start_timeout">120000</limit>  
      <limit name="auth_timeout">240000</limit>
      <limit name="max_completed_connections">100000</limit>  
      <limit name="max_incomplete_connections">10000</limit>
      <limit name="max_connections_per_user">100000</limit>
      <limit name="max_pending_service_starts">10000</limit>
      <limit name="max_names_per_connection">50000</limit>
      <limit name="max_match_rules_per_connection">50000</limit>
      <limit name="max_replies_per_connection">50000</limit>
      <limit name="reply_timeout">300000</limit>
    
    </busconfig>
    File session.conf has a companion file /Applications/Gimp.app/Contents/Resources/etc/dbus-1/system.conf, whose contents are this:
    Code:
    <!-- This configuration file controls the systemwide message bus.
         Add a system-local.conf and edit that rather than changing this 
         file directly. -->
    
    <!-- Note that there are any number of ways you can hose yourself
         security-wise by screwing up this file; in particular, you
         probably don't want to listen on any more addresses, add any more
         auth mechanisms, run as a different user, etc. -->
    
    <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
     "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
    <busconfig>
    
      <!-- Our well-known bus type, do not change this -->
      <type>system</type>
    
      <!-- Run as special user -->
      <user>messagebus</user>
    
      <!-- Fork into daemon mode -->
      <fork/>
    
      <!-- We use system service launching using a helper -->
      <standard_system_servicedirs/>
    
      <!-- This is a setuid helper that is used to launch system services -->
      <servicehelper>/tmp/skl/Gimp.app/Contents/Resources/libexec/dbus-daemon-launch-helper</servicehelper>
    
      <!-- Write a pid file -->
      <pidfile>/tmp/skl/Gimp.app/Contents/Resources/var/run/dbus/pid</pidfile>
    
      <!-- Only allow socket-credentials-based authentication -->
      <auth>EXTERNAL</auth>
    
      <!-- Only listen on a local socket. (abstract=/path/to/socket 
           means use abstract namespace, don't really create filesystem 
           file; only Linux supports this. Use path=/whatever on other 
           systems.) -->
      <listen>unix:path=/tmp/skl/Gimp.app/Contents/Resources/var/run/dbus/system_bus_socket</listen>
    
      <policy context="default">
        <!-- Deny everything then punch holes -->
        <deny send_interface="*"/>
        <deny receive_interface="*"/>
        <deny own="*"/>
        <!-- But allow all users to connect -->
        <allow user="*"/>
        <!-- Allow anyone to talk to the message bus -->
        <!-- FIXME I think currently these allow rules are always implicit 
             even if they aren't in here -->
        <allow send_destination="org.freedesktop.DBus"/>
        <allow receive_sender="org.freedesktop.DBus"/>
        <!-- valid replies are always allowed -->
        <allow send_requested_reply="true"/>
        <allow receive_requested_reply="true"/>
      </policy>
    
      <!-- Config files are placed here that among other things, punch 
           holes in the above policy for specific services. -->
      <includedir>system.d</includedir>
    
      <!-- This is included last so local configuration can override what's 
           in this standard file -->
      <include ignore_missing="yes">system-local.conf</include>
    
      <include if_selinux_enabled="yes" selinux_root_relative="yes">contexts/dbus_contexts</include>
    
    </busconfig>
    
    File system.conf contains references to three files under /tmp/skl/Gimp.app/Contents/Resources/:
    1. libexec/dbus-daemon-launch-helper ("a setuid helper used to launch system services")
    2. var/run/dbus/pid (for the process ID)
    3. var/run/dbus/system_bus_socket (local socket)
    So this /tmp folder seems to have a direct role. My best guess is that our use of network-defined users is somehow involved, and that we have some kind of permissions problem.

    Meanwhile, 3 Macs in the classroom now have this problem, so something happens to "break" a Mac's copy of Gimp while a student (non-admin account) is using it.
     
  22. yellow Moderator emeritus

    yellow

    Joined:
    Oct 21, 2003
    Location:
    Portland, OR
    #22
    Dang. I wish we could recreate what breaks it.
     
  23. chambers macrumors newbie

    Joined:
    May 28, 2008
    #23
    i updated to X11 1.1.3

    first i uninstalled X11 and gimp, reloaded X11, ran the software update and then reinstalled gimp after that.

    unfort thats all i have for you... hope you manage to sort it out!
     
  24. yellow Moderator emeritus

    yellow

    Joined:
    Oct 21, 2003
    Location:
    Portland, OR
    #24
    I agree with this assessment, though I wonder why it remains broken for the local admin.

    Just to make sure, have you removed every piece/part involved in X11 on these boxes? I know that X11 still works fine for you, but we might as well start fresh from there.

    But I'm still interested in seeing what happens with a brand-new user.

    [NOTE: EDITED RETURNED LISTS FOR BORTH BELOW]

    Code:
    yellow$ sudo find / -name "*X11*" -print
    Password:
    /Applications/Utilities/SuperDuper!.app/Contents/Resources/Copy Scripts/Share X11 applications.dset
    /Applications/Utilities/X11.app
    /Library/Receipts/boms/com.apple.pkg.X11DocumentationLeo.bom
    /Library/Receipts/boms/com.apple.pkg.X11SDKLeo.bom
    /Library/Receipts/boms/com.apple.pkg.X11User.bom
    /private/etc/manpaths.d/X11
    /private/etc/paths.d/X11
    /System/Library/LaunchAgents/org.x.X11.plist
    /Users/yellow/Library/Preferences/org.x.X11.plist
    /usr/include/X11
    /usr/X11
    Code:
    yellow$ sudo find / -name "*gimp*" -print
    Password:
    /Applications/Gimp.app
    /Users/yellow/Library/Application Support/Gimp
     
  25. yellow Moderator emeritus

    yellow

    Joined:
    Oct 21, 2003
    Location:
    Portland, OR
    #25
    Are you using AD, or strictly OD here?

    Interesting note..

    The 10.5.3 Server update mentions:

    "using Managed Preferences when clients are bound to Active Directory"
     

Share This Page