Re: [munki-dev] Munki Postflight
69 views
Skip to first unread message
Gregory Neagle
Oct 11, 2012, 11:48:04 PM10/11/12
to munk...@googlegroups.com
managedsoftwareupdate itself checks for other instances of itself running using munkicommon.pythonScriptRunning('managedsoftwareupdate') -- perhaps you could use a similar method.
As for the other point, it looks like there are several possible ways to exit without running the postflight. Whether or not that should be fixed is certainly a point for discussion, but with the current behavior, no, you cannot be certain the postflight will execute.
-Greg
On Oct 11, 2012, at 6:13 PM, Bizzaro <ma...@mwowm.com> wrote:
> Hi all,
>
> I am attempting to use a Munki Pre/Postflight script combination to provide a method for other scripts to determine whether managedsoftwareupdate is running or not. I am currently doing this by touching a .lock file in the preflight and rm it in the postflight. I noticed in testing that if Munki is not configured to correctly use a repo URL (ie the default "http://munki/repo") it appears to not run the postflight script. Is this expected behavior? Is there a better way to determine if the process is running?
>
> I've tried using methods involving looking for the process directly with limited success. It seems managedsoftwareupdate runs with a pid of "Python" and a couple curl instances, so the results of a "pgrep" or "ps ax" are inconclusive.
>
> BTW I'm running version 0.8.2.1475
As for the other point, it looks like there are several possible ways to exit without running the postflight. Whether or not that should be fixed is certainly a point for discussion, but with the current behavior, no, you cannot be certain the postflight will execute.
-Greg
On Oct 11, 2012, at 6:13 PM, Bizzaro <ma...@mwowm.com> wrote:
> Hi all,
>
> I am attempting to use a Munki Pre/Postflight script combination to provide a method for other scripts to determine whether managedsoftwareupdate is running or not. I am currently doing this by touching a .lock file in the preflight and rm it in the postflight. I noticed in testing that if Munki is not configured to correctly use a repo URL (ie the default "http://munki/repo") it appears to not run the postflight script. Is this expected behavior? Is there a better way to determine if the process is running?
>
> I've tried using methods involving looking for the process directly with limited success. It seems managedsoftwareupdate runs with a pid of "Python" and a couple curl instances, so the results of a "pgrep" or "ps ax" are inconclusive.
>
> BTW I'm running version 0.8.2.1475
Hugh Burt
Oct 12, 2012, 5:50:49 AM10/12/12
to munk...@googlegroups.com
| Hello Everyone Does anyone know a way how to "tag" pending Apple updates onto a forced by date Munki install, so they get installed in the same "session" as the forced munki install? I am finding Munki really useful, especially now I have got Munkiwebadmin working, but the number of pending Apple updates, I keep seeing on staff machines, is disturbing. Thanks |
Gregory Neagle
Oct 12, 2012, 12:59:14 PM10/12/12
to munk...@googlegroups.com
The only way to do this currently is to download the standalone updates from Apple and import them into Munki.
-Greg
Bizzaro
Oct 27, 2012, 11:45:23 PM10/27/12
to munk...@googlegroups.com
Thanks for the clarification Greg. I was able to determine if managedsoftwareupdate is running using:
ps -eo command=
and greping for the lines I'm interested in.
This leads me to another question. Right now I have Munki set to install Apple updates as well as managed installs. My goal is to be sure Munki isn't in the middle of something when I force a nightly restart of the machine. I noticed that Munki installs happen in two chunks. One for managed installs, and then again for Apple Updates. Do these run back to back? Or is there a randomized sleep timer between the two jobs?
Reply all
Reply to author
Forward
0 new messages