[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Module variables being set late

From: Mark . Burgess
Subject: Re: Module variables being set late
Date: Thu, 8 Jan 2004 22:14:12 +0100 (MET)

>From the code:

   if (pass == 1)

With this test program:


   actionsequence = ( disable module:test alerts )

I see:

 Main Tree Sched: disable pass 1 @ Thu Jan  8 22:12:38 2004

Filetype all, /tmp/bla is not there - ok

 Main Tree Sched: module:test pass 1 @ Thu Jan  8 22:12:39 2004

(Plug-in /var/cfengine/modules/module:test not found)

 Main Tree Sched: alerts pass 1 @ Thu Jan  8 22:12:39 2004

This shows that things happen in the correct order. So I am guessing that
the problem is something else.


On  7 Jan, Chip Seraphine wrote:
> On Wednesday 07 January 2004 14:00, you wrote:
>> On  7 Jan, Chip Seraphine wrote:
>> > I am running a module at the top of my actionsequence, and it sets a
>> > class ("foo").  Foo *is* an AddInstallable class.
>> >
>> > Unfortunately, the module runs only *after* everything else in the
>> > actionsequence, even though it is the first item on the list.  (I'm not
>> > sure, but I believe that this is new behavior in 2.1; the problems this
>> > behavior is causing did not exist prior to that.)  This is causing the
>> > "foo" class to not be set until too late to do any good.
>> >
>> > I've tried running the module the old-style way (with
>> > ""), but that did not cause it run a the desired time.
>> >
>> > Any ideas?  Any way I can for the modules to run at the beginning of the
>> > first passs, which what I really need it to do?
>> This is factually incorrect. The modules are run in the correct place
>> in the actionsequence. Whether or not the variables are "received" by
>> the actions is a different issue.
> I'm fairly certain they are running late.  The modules also generate syslog 
> messages, and those appeared in syslogs only after logger calls from  "later" 
> in the cfengine script.
>> You need to tell us exactly what
>> you are doing.
> I have a top level file that sets some very basic parameters and then imports 
> a couple of settings-type files (, which contains or discovers my 
> network and DNS information and cf.groups, which is my "control panel" that I 
> use to regulate who does what) and then starts importing other cf files.  The 
> first of these is 'cf.main', which does all the nuts and bolts including 
> running most of the modules.  (The modules are the very first items in 
> cf.main's actionsequence).  Subsequent files are task-oriented (e.g. 
> cf.crontabs maintains a bunch of cron entries and backs up some cron-related 
> stuff) and just do things that are a little too bulky to throw in cf.main 
> without it becoming spaghetti.
> Anyway, one of the modules cf.main runs determines wether or not some 
> in-house 
> apps are supposed to be running on the current host by querying some local 
> files and databases.  (The authority point for this stuff was established 
> long before the cfengine rollout, so in this case some app file content tell 
> Cfengine what to do instead of Cfengine dictating the file contents).  I set 
> flags from this, which then tells cfengine to do various health-related tasks 
> in a manner appriate for that machine based on the flags  (process lists, 
> disk space thresholds, user passwords, the big ugly 'PRODUCTION MACHINE' 
> banner, etc).
> The problem is that this scheme results in the modules imported by cf.main 
> running after the tasks that need their results.
> I can get it to work by running my modules at the top level (cfagent.conf), 
> but this seriously uglifies my "control panel", as it means I have to assign 
> all groups that affect the modules in cfagent.conf itself so that the modules 
> can see them.  This is a problem because my cf.groups file makes use of 
> variables and classes set in preceding files; a lot of it  cannot be easily 
> done in the 'top' file without some shellcommands: or control: section 
> running before it (which is the whole reason that cf.groups is a seperate 
> file in the first place).  For example, some 'control classes' that regulate 
> behavior are turned on/off by results from my file.
> Well, that's as specific I can get without pasting in bug hunks of config :-)

Work: +47 22453272            Email:  address@hidden
Fax : +47 22453205            WWW  :

reply via email to

[Prev in Thread] Current Thread [Next in Thread]