Client repair fails with 'object has no attribute'

Skip to first unread message

John Meyers

Jul 24, 2018, 11:47:06 AM7/24/18
to Simian Discuss
We've noticed that when a client gets sent the repair command, it fails over and over resulting the client never fixing itself...  We're using simian-2.5-and-munkitools-3.0.3-3352 on a fresh pull.  I don't see anything previously reported about this.  Also tried a complete re-install manually of the client, but the server is still pushing the "You need to repair" flag.

INFO:root:Reinstalling Munki client....

INFO:root:Fetching repair client from:

Traceback (most recent call last):

  File "/usr/local/munki/", line 87, in <module>


  File "/usr/local/munki/", line 73, in main

    preflight.RunPreflight(runtype, server_url=server_url)

  File "/usr/local/munki/simian/lib/python2.7/site-packages/simian-2.5-py2.7.egg/simian/mac/client/", line 393, in RunPreflight


  File "/usr/local/munki/simian/lib/python2.7/site-packages/simian-2.5-py2.7.egg/simian/mac/client/", line 910, in RepairClient

    updatecheck.getResourceIfChangedAtomically('%s/repair' % url, download_path)

AttributeError: 'module' object has no attribute 'getResourceIfChangedAtomically'

Will Holtz

Jul 25, 2018, 12:44:41 AM7/25/18
to Simian Discuss
Hi John,

I ran into this same problem. The existing code tries to call getResourceIfChangedAtomically from updatecheck. That method does not exist in updatecheck but is in fetch. So I made the following change:

diff --git a/src/simian/mac/client/ b/src/simian/mac/client/

index d21f810..9690731 100755

--- a/src/simian/mac/client/

+++ b/src/simian/mac/client/

@@ -907,7 +907,7 @@ def RepairClient():

     DownloadError = fetch.DownloadError



-    updatecheck.getResourceIfChangedAtomically('%s/repair' % url, download_path)

+    fetch.getResourceIfChangedAtomically('%s/repair' % url, download_path)

   except DownloadError as e:

     raise RepairClientError(

         u'MunkiDownloadError getting Munki client: %s' % e)


Even with this modification, my repairs still fail, but this allows the preflight to complete. In my case this allowed my clients to get to a point where they no longer triggered the repair.


John Meyers

Jul 30, 2018, 5:03:48 PM7/30/18
to Simian Discuss
Thanks!   Yes, I concur it allows the client to get passed the issue.  When it attempts to download the repair package, the server returns a 403 error, presumably because the fetch call is not authenticated.

One possible solution would be to get rid of the whole client-managed repair process and instead call Google's own MacOps 'planb', which will re-install Simian, Puppet, and other critical management tools.  I'm hesitant to do that refactoring without the Google folks chiming in.

Reply all
Reply to author
0 new messages