Skip navigation

launchd disobeying plist

2309 Views 34 Replies Latest reply: May 7, 2012 6:36 PM by Jonathan Pool RSS
  • etresoft Level 7 Level 7 (23,880 points)
    Currently Being Moderated
    May 7, 2012 8:47 AM (in response to Jonathan Pool)

    Both launchd and rsync are really meant for software developers. Documentation is always poor in this context. It is expected that developers will take a systematic approach to learning how the software works and what the documentation means. Furthermore, rsync is much more complex than launchd. You are using both. That's just painful.

     

    I suggest looking for a 3rd party, commercial solution. In addition to all of the above, rsync is "free software". Neither support nor documentation is provided. You are expected to exercise your freedom and hack up rsync as you wish. Because of this, no software developer has any incentive to make rsync easier to use like the developer of Lingon has make launchd easier to use.

  • twtwtw Level 5 Level 5 (4,580 points)
    Currently Being Moderated
    May 7, 2012 10:05 AM (in response to Jonathan Pool)

    I'll have to check the rsync man page and parse through your commands (I know they work, but I want to know precisely what they are doing).  I'll get back on that a bit later.  I assume you're using the default rsync (v. 2.6.9) and that your script starts with a bash shebang and has its executable bit set.

     

    as to the rest, launchd is no more (or less) difficult to use than cron.  it's just a different paradigm.  you seem to know how to use cron, so you are certainly capable of using launchd, and it's just a question of getting your head out of the old box and into the new.  it might help to understand the structure.  launchd has three basic elements: plist files (xml-style configuration files), jobs (things entered into launchd, usually from plist files), and utilities (utilities are scripts launched by jobs when the specific criteria laid out in plist files are met).  launchd takes care of starting and killing utilities (and their subprocesses) according to its job list.

     

    so a QueueDirectory job needs three criteria to be met in order to launch its associated utility: that the directory exist, that it be empty, and that a change occurs.  the only way those criteria can all be satisfied is by adding files to an empty directory, so that is the only time a QD job will fire.  It's assumed one can make the logical deduction that a non-empty directory must be emptied of any contents before the job will be able to fire the utility again.

  • Mark Jalbert Level 5 Level 5 (4,385 points)
    Currently Being Moderated
    May 7, 2012 12:13 PM (in response to Jonathan Pool)

    This is a simple example that I think will help you out. It writes the date and time to a log file every time a file is added to 2 directories or when a filesystem is mounted.

     

    <?xml version="1.0" encoding="UTF-8"?>
    
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    
    <plist version="1.0">
    
    <dict>
    
         <key>Label</key>
         <string>com.example.WPtest</string>
    
         <key>ProgramArguments</key>
         <array>
         <string>/usr/local/bin/wp.ksh</string>
         </array>
    
         <key>StartOnMount</key>
         <true/>
    
         <key>WatchPaths</key>
          <array>
         <string>/tmp/wptest</string>
         <string>/tmp/wptest2</string>
         </array>
    
    </dict>
    
    </plist>

    and the shell script:

     

    #!/usr/bin/env ksh
    
    date -j >> /tmp/logfile
    
  • etresoft Level 7 Level 7 (23,880 points)
    Currently Being Moderated
    May 7, 2012 12:29 PM (in response to Mark Jalbert)

    A noble effort, but the original poster wants to run rsync in the script.

     

    Can you update the script so it has the ability to modify the directories it watches

  • Mark Jalbert Level 5 Level 5 (4,385 points)
    Currently Being Moderated
    May 7, 2012 12:37 PM (in response to etresoft)

    I'm not doing all the work..:-)

  • Mark Jalbert Level 5 Level 5 (4,385 points)
    Currently Being Moderated
    May 7, 2012 12:40 PM (in response to Jonathan Pool)

    Stick with cron. It's portable and is working for you.

  • twtwtw Level 5 Level 5 (4,580 points)
    Currently Being Moderated
    May 7, 2012 12:51 PM (in response to Jonathan Pool)

    My 2¢, I think you need to give up on the idea of continuous real-time synchronization.  no sync or backup solution I know of does that; ey all work on demand or on a periodic basis. 

  • etresoft Level 7 Level 7 (23,880 points)
    Currently Being Moderated
    May 7, 2012 12:55 PM (in response to Mark Jalbert)

    Mark Jalbert wrote:

     

    Stick with cron. It's portable and is working for you.

    I think I'm going to have to agree. Cron is a crude, overused tool, but that doesn't mean it isn't useful.

     

    The problem here is one of recursion. The script would have to immediately load its launchd configuration, run rsync, and then reload the launchd configuration. That is a mess and bound to be a disaster. There are a number of tools that perform folder syncing without so much effort.

Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • This solved my question - 10 points
  • This helped me - 5 points
This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.