What is that report number?!

[Christian Linden]

Hi Gents (or is there any lady?!),

please take a look what I'm doing, I just want to get the PIDs of the three cfengine processes:

 body common control

 {

           bundlesequence => { "getPIDs"};

                   inputs => {"/var/cfengine/masterfiles/libraries/cfengine_stdlib.cf"};

 }

bundle agent getPIDs

{

vars:

  "GetPIDs" string => execresult("/bin/ps aux |grep [c]fengine|awk '{print $2}'", "useshell");

reports:

#    executed::

        "$(GetPIDs)";

}

This really works and it returns me what I want =) but as well another number I don't want!

I stopped cfengine3 and still get:

host001:~ # cf-agent -KIf /var/cfengine/inputs/R4Promises/getPIDs.cf  -b getPIDs

2015-08-24T16:33:17+0200     info: Using command line specified bundlesequence

2015-08-24T16:33:17+0200   notice: R: 1835

host001:~ #

What is that 1835 and/or where does it come from?!

Thanks!

Best,

Chris

[Neil Watson]

Your execresult command might well return multiple strings. More like a
list really. AND the first match is likely itself.

body common control
{
bundlesequence => { "getPIDs"};
}

bundle agent getPIDs
{
vars:
"GetPIDs" string
=> execresult("/bin/ps aux |grep [c]fengine|awk '{print $2}'"
, "useshell");

reports:

"$(GetPIDs)";
}
newatson@ltipc682:~/.cfagent/inputs$ /bin/ps aux |grep [c]fengine|awk '{print $2}'
7803
7953
8007
newatson@ltipc682:~/.cfagent/inputs$ cf-agent -Kf ./chris.cf
R: 2226
7803
7953
8007



--
Neil H Watson
Sr. Partner, Architecture and Infrastructure
CFEngine reporting: https://github.com/evolvethinking/delta_reporting
CFEngine policy: https://github.com/evolvethinking/evolve_cfengine_freelib
CFEngine and vim: https://github.com/neilhwatson/vim_cf3
CFEngine support: http://evolvethinking.com

[Christian Linden]

What "itself"? Is it a PID? From the report? 

I avoid to get a PID from the grep itself by grepping for [c]f.*

How can I avoid the other one?

c

[Neil Watson]

On Mon, Aug 24, 2015 at 08:05:26AM -0700, Christian Linden wrote:
>
> What "itself"? Is it a PID? From the report?

The PID from the cf-agent that ran the policy.

[Christian Linden]

makes sense.. any idea how to get rid off it?

[Nick Anderson]

On 08/24/2015 12:10 PM, Christian Linden wrote:
> makes sense.. any idea how to get rid off it?

You could potentially filter the pid.

https://docs.cfengine.com/docs/3.7/reference-special-variables-this.html#this-promiser_pid

[Aleksey Tsalolikhin]

On Mon, Aug 24, 2015 at 7:34 AM, Christian Linden <lindo...@gmail.com> wrote:

please take a look what I'm doing, I just want to get the PIDs of the three cfengine processes:

Just curious, Chris, what is the problem you are working on?

--

Aleksey Tsalolikhin

CFEngine Training & Consulting

Vertical Sysadmin, Inc.

+1-323-393-0779

[Christian Linden]

I answered Aleksey ;-)

[Christian Linden]

How do I express this: "execresult - (minus) this.promiser_pid"?

c

Am Montag, 24. August 2015 19:15:22 UTC+2 schrieb Nick Anderson

[Nick Anderson]

On 08/25/2015 07:45 AM, Christian Linden wrote:
> How do I express this: "execresult - (minus) this.promiser_pid"?

You could add a negative grep to your execresult to strip out lines that
contain the pid you don't want.

It's not clear what your goal is.

You can also get the pids from:
/var/cfengine/cf-consumer.pid
/var/cfengine/cf-hub.pid
/var/cfengine/cf-serverd.pid
/var/cfengine/cf-execd.pid
/var/cfengine/cf-monitord.pid

And then there is also the cached process table:
ls /var/cfengine/state/ | grep procs
cf_otherprocs
cf_procs
cf_rootprocs

[Aleksey Tsalolikhin]

On Tue, Aug 25, 2015 at 12:24 AM, Christian Linden <lindo...@gmail.com> wrote:

=)

I need to restart all cf-serverds.. and for QAing it I want to grep all PIDs in advance =)

[small tasks to get familiar with CFEngine] 

Please, could you reply to the list so that others can benefit from your struggles.  :)

You've taken a very practical approach (small tasks to get familiar with CFEngine), and that is the approach I take when teaching CFEngine.

You are restarting cf-serverd because you are running an older version that does not automatically read in the new config, right?  I would recommend writing a promise that signals cf-serverd if the config files have been updated within the past 15 minutes.  So you'll need to set a class if the config files mtime < 15 minutes.

You can just watch the cf-serverd restart, you don't need to put it in policy.  Once you see it works, you'll trust CFEngine more and yourself as a CFEngine policy writer.

I should mention cf-execd will restart cf-serverd if you manage to kill it.

I don't remember if the 3.5.x cf-serverd rereads it's config files on SIGHUP; if it doesn't, you'll need to SIGTERM it.

Have fun!

Best,

-at

 

[Christian Linden]

You are restarting cf-serverd because you are running an older version that does not automatically read in the new config, right? 

right

 

I would recommend writing a promise that signals cf-serverd if the config files have been updated within the past 15 minutes.  So you'll need to set a class if the config files mtime < 15 minutes.

sounds well 

You can just watch the cf-serverd restart, you don't need to put it in policy. 

?

configOlderThan15Mins::

  then what? SIGHUP? Can't find how to do it after an hr research.. 

 

Once you see it works, you'll trust CFEngine more and yourself as a CFEngine policy writer. 

I should mention cf-execd will restart cf-serverd if you manage to kill it.

realized that, thanks

[Neil Watson]

On Tue, Aug 25, 2015 at 08:28:05AM -0700, Christian Linden wrote:
>
> You can just watch the cf-serverd restart, you don't need to put it in
> policy.
>
> ?
> configOlderThan15Mins::
> then what? SIGHUP? Can't find how to do it after an hr research..

I've always had the habit of restarting cf-execd, cf-serverd, and
cf-monitord when inputs change. You can see some examples of how to do
that here:

I use methods and separate bundles. This bundle updates inputs:
https://github.com/evolvethinking/evolve_cfengine_freelib/blob/master/masterfiles/lib/3.7/EFL/efl_update.cf#L72-L75

Here it kills the services if inputs have been updated:
https://github.com/evolvethinking/evolve_cfengine_freelib/blob/master/masterfiles/lib/3.7/EFL/efl_update.cf#L189-L195

And I have separate bundle, called later, to promise that the daemons
are running. Thus they start any previously killed daemons.
https://github.com/evolvethinking/evolve_cfengine_freelib/blob/master/masterfiles/lib/3.7/EFL/efl_update.cf#L83-L87
https://github.com/evolvethinking/evolve_cfengine_freelib/blob/master/masterfiles/lib/3.7/EFL/efl_update.cf#L198-L215

[Aleksey Tsalolikhin]

On Tue, Aug 25, 2015 at 8:28 AM, Christian Linden <lindo...@gmail.com> wrote:

configOlderThan15Mins::

  then what? SIGHUP? Can't find how to do it after an hr research.. 

CFEngine 3.6 supports SIGHUP to reload promises (https://dev.cfengine.com/issues/6604) but 3.5 does not, you'll have to kill it.

 Here is an example of killing a process whose entry in the process table matches a certain pattern: 

https://github.com/cfengine/design-center/blob/fa0ae2e6f087509be8530b6bdde9aa07b14b0570/examples/verticalsysadmin_training_examples/030 

There are more examples of accomplishing basic tasks in CFEngine in https://github.com/atsaloli/design-center/tree/master/examples/verticalsysadmin_training_examples -- training materials for our course.

Best,

-at

[Christian Linden]

this link seems to be dead

On 25 Aug 2015, at 18:01, Aleksey Tsalolikhin <ale...@verticalsysadmin.com> wrote:

https://github.com/cfengine/design-center/blob/fa0ae2e6f087509be8530b6bdde9aa07b14b0570/examples/verticalsysadmin_training_examples/030 

[Aleksey Tsalolikhin]

Sorry -- try this: https://github.com/atsaloli/design-center/blob/master/examples/verticalsysadmin_training_examples/1-030-Basic_Examples-0260-Files_Processes_Commands_Processes_No_IRC_bot_process_Terminate_with_prejudice.cf

[Christian Linden]

Thanks Neil; maybe I can understand that megabundlecrosswork in a couple of months, given that I continue (trying) to work with CFEngine.

Since 2 months I try to start with and understand simple bundles/promises but this doesn't seem to be possible; hence to start with CFEngine is like running against a wall.

[Neil Watson]

On Wed, Aug 26, 2015 at 03:37:54AM -0700, Christian Linden wrote:
>
>
> Thanks Neil; maybe I can understand that megabundlecrosswork in a couple

Don't think of it as crosswork. Promises are not really connected. Each
promise is a description of an end state. So, restarting on inputs
changes reads like this:

1. A files promise to copy new inputs and set a class 'kill_cf_daemons'
if repaired.

2. A processes promise to kill CFEngine daemons when the class
kill_cf_daemons is true.

3. A processes promiser to set a restart class start_cf_daemons if the
given processes are not running.

4. A commands promise to run commands to start CFEngine daemons if
the class start_cf_daemons is true.

Break it down into parts, order those parts, if required, and then write
the promises.

[Christian Linden]

That's too complicated for my simple mind actually..

I need baby tasks to run.. and have baby probs.

I got a hell full of information with the links below, thank you very much, if will read them if I'm unemployed and without any contract next time, PROMISED!!

All I needed was this:

processes:

  "processname"

     signals => { "whatever sigs work here" };

And it works for me and I was nearly able to go home happy BUT:

I want to kill more than one process..

and neither "process1", "process2", "process3"

nor "process1, process2, process3"

nor "process1" "process2" "process3" 

works.. even if the last one is not criticised by cf-promise..

I hope it's possible to resolve this in a line, oh PLEASE!!!

bye,

chris

[Aleksey Tsalolikhin]

Good, I'm glad the example policy was useful, the whole VSA Training Examples collection is like that, lots of simple examples.

Now show us what policy you wrote (give a self-contained standalone runnable example), and what processes you are trying to match (show us the "ps" output).

Best,

-at

--
You received this message because you are subscribed to the Google Groups "help-cfengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to help-cfengin...@googlegroups.com.
To post to this group, send email to help-c...@googlegroups.com.
Visit this group at http://groups.google.com/group/help-cfengine.
For more options, visit https://groups.google.com/d/optout.

[Christian Linden]

 body common control

 {

           bundlesequence => { "killProcesses"};

                   inputs => {"/var/cfengine/masterfiles/libraries/cfengine_stdlib.cf"};

 }

bundle agent killProcesses

{

processes:

  host001::

    "cf-serverd"

        signals => { "kill" },

        classes => if_repaired("executed");

reports:

    executed::

        "obviously killed";

}

THIS WORKS!!! GREAT!!! 

But I want to kill cf-execd and cf-monitord as well and find no way. All examples just send a signal to one process.

I know that the cfengine processes can be killed in a different way. Then think about 3 whatever processes "p1", "p2" and "p3".

How do I get them in one run?

Thanks,
Chris

[Neil Watson]

On Thu, Aug 27, 2015 at 03:29:25AM -0700, Christian Linden wrote:
>
>
>  body common control
>  {
>            bundlesequence => { "killProcesses"};
>                    inputs =>
> {"/var/cfengine/masterfiles/libraries/cfengine_stdlib.cf"};
>  }
> bundle agent killProcesses
> {
> processes:
>   host001::
>     "cf-serverd"
>         signals => { "kill" },
>         classes => if_repaired("executed");
> reports:
>     executed::
>         "obviously killed";
> }

The examples I showed you had list iteration just like list iteration in
the previous files examples.

vars:
"cf_procs" slists => { "execd", "monitord", "serverd" };

processes:
host001::
"cf-${cf_procs}"
comment => "This promise is repeated for each element in the
list cf_procs.",
signals => { "term", "kill" } # Try to nicely term before kill.
classes => if_repaired( "cf_${cf_procs}_was_killed" );


reports:
"Cf${cf_procs} was killed"
comment => "This promise is repeated for each element in the
list cf_procs if the class is true.",
ifvarclass => "cf_${cf_procs}_was_killed";

Notes:

1. Loops:
https://docs.cfengine.com/docs/master/guide-language-concepts-loops.html

2. Consider using process_select for process matching. On its own the
processes promiser will match against the entire ps command line. You
want to make sure you don't match 'vim cf-serverd.cf' or similar.
https://docs.cfengine.com/docs/master/reference-promise-types-processes.html#process_select

[Christian Linden]

Neil,

this got a bit clear even if I don't understand exactly what you mean by "restarting on inputs changes"?

Which (if any) bundle?

But I'm pretty sure you mean the "kill_cf_procs" class =) (NOT kill_cf_daemons)

What cached my laymans eyes is that there are 2 matching processes: promises in the bundles "inputs_purge" and "inputs_and_modules";

they just differ in the handle.. whose meaning I didn't bother about yet.. but methods point to bundles, right? Hence this double process promise might be right, according to which bundle is called by which method.. I'm not at this level yet.. just curious..

Thanks,

Chris

Am Mittwoch, 26. August 2015 14:00:06 UTC+2 schrieb Neil Watson:

[Christian Linden]

Hey Neil,

this works, great, thanks a lot!

list iteration.. slist.. var.. just wanted to put it in directly.. theoretically it could have worked ;-) cfengine just doesn't support my simple thinking =P

c

[Christian Linden]

I never thought about using the iteration/looping magic in the reports, that's nice =)

Why doesn't it work this way:

reports:

   $(cf_procs)_was_killed::

        "$(cf_procs) was obviously killed";

or this way:

reports:

   "$(cf_procs)_was_killed"::

        "$(cf_procs) was obviously killed";

Must ifvarclass be used in this case?

I put the "cf-" into the slist like this btw:

vars:

  "cf_procs" slist => { "cf-serverd", "cf-monitord", "cf-execd" };

Thanks!

Chris

Am Donnerstag, 27. August 2015 14:03:59 UTC+2 schrieb Neil Watson:

[Neil Watson]

That syntax is not permitted. Don't ask me why, I'll just rant about
bad laziness. You must us ifvarclass when resolving variables into
classes, shorted to 'if' in 3.7.0.

On Thu, Aug 27, 2015 at 08:06:01AM -0700, Christian Linden wrote:
> I never thought about using the iteration/looping magic in the reports,
> that's nice =)
> Why doesn't it work this way:
> reports:
>    $(cf_procs)_was_killed::
>         "$(cf_procs) was obviously killed";
> or this way:
> reports:
>    "$(cf_procs)_was_killed"::
>         "$(cf_procs) was obviously killed";
> Must ifvarclass be used in this case?
> I put the "cf-" into the slist like this btw:
> vars:
>   "cf_procs" slist => { "cf-serverd", "cf-monitord", "cf-execd" };

[Nick Anderson]

On 08/27/2015 10:06 AM, Christian Linden wrote:
> I never thought about using the iteration/looping magic in the reports,
> that's nice =)
>
> Why doesn't it work this way:
> reports:
> $(cf_procs)_was_killed::
> "$(cf_procs) was obviously killed";

Because $(cf_proces)_was_killed is not a valid class expression.

Traditionally class expressions can only contain 0-9 A-Z and a-z in
addition to _ and any operator like () ! . & | or ||.

Thats why you see things like this:

(Monday|Wednesday).Hr14.WinXP::

You would need to do cf_serverd_was_killed::

> or this way:
> reports:
> "$(cf_procs)_was_killed"::
> "$(cf_procs) was obviously killed";

In 3.7 that would **almost** work. The problem is that dashes are not
valid class characters, so you will never have a class that matches
cf-serverd_was_killed. Invalid class names get automatically canonified
so it would become cf_serverd_was_killed.

> Must ifvarclass be used in this case?

There are other ways, but in this case I think the following would be
the easiest.

reports:
"$(cf_procs) was obviously killed"
ifvarclass => canonify("$(cf_procs)_was_killed");

[Nick Anderson]

On 08/27/2015 10:18 AM, Neil Watson wrote:
> That syntax is not permitted. Don't ask me why, I'll just rant about
> bad laziness. You must us ifvarclass when resolving variables into
> classes, shorted to 'if' in 3.7.0.

"$(variable)"::

works in 3.7

Note: $(variable) must expand to a valid class like cf_serverd not
cf-serverd.

[Christian Linden]

kind of complicated.. thanks for explaining, Nick!

[Aleksey Tsalolikhin]

On Thu, Aug 27, 2015 at 3:29 AM, Christian Linden <lindo...@gmail.com> wrote:

THIS WORKS!!! GREAT!!!

Great job!

 

But I want to kill cf-execd and cf-monitord as well and find no way. All examples just send a signal to one process.

I know that the cfengine processes can be killed in a different way. Then think about 3 whatever processes "p1", "p2" and "p3".

How do I get them in one run?

If you want to kill all CFEngine processes, you can use a pattern in the promiser.

E.g.

processes:

   "cf-.*"

        ....

Since it sounds like you want to shutdown the CFEngine service, consider using the "process_stop" attribute to run "/sbin/service cfengine3 stop" rather than "signals" attribute specifying SIGTERM, as it would be cleaner.

I have an example of process_stop in the Vertical Sysadmin Training Examples collection:

bundle agent example {
	processes:
	"cupsd"
	handle => "shutdown_print_services",
	comment => "Shutdown print services on machines
	that are not print servers",
	process_stop => "/etc/init.d/cups stop";
	}

Best,

-at

[Christian Linden]

Where’s the difference between a process_stop and and a command: ?

c

[Neil Watson]

On Mon, Aug 31, 2015 at 12:22:54PM +0200, Christian Linden wrote:
> Where’s the difference between a process_stop and and a command: ?

A commands promise is more flexible allowing for a contain attribute.

[Stefan Skoglund (lokal]

mån 2015-08-24 klockan 07:34 -0700 skrev Christian Linden:
>
> bundle agent getPIDs
> {
>
> vars:
> "GetPIDs" string => execresult("/bin/ps aux |grep [c]fengine|awk
> '{print $2}'", "useshell");
>
> reports:
> # executed::
> "$(GetPIDs)";
> }
>

Why the grep filter ?

Why not instead :

GetPIDs" string => execresult("/bin/ps aux |awk '/[c]fengine/ {print
$2}'", "useshell");

[Brian Bennett]

Why not pgrep?

--
Brian Bennett
Looking for CFEngine training?
http://www.verticalsysadmin.com/

[Christian Linden]

just because I never used this awk function yet ;-)

[Christian Linden]

because I forgot about it =(

It's the absolute smartest way =)

Best,

Chris

[Christian Linden]

Thanks, Neil, for explaining it so clearly =)

[Christian Linden]

got it!

[Aleksey Tsalolikhin]

Neil has a gift for clear explanation.  I learned how to use CFEngine off his writings.

ᐧ

--
You received this message because you are subscribed to the Google Groups "help-cfengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to help-cfengin...@googlegroups.com.
To post to this group, send email to help-c...@googlegroups.com.
Visit this group at http://groups.google.com/group/help-cfengine.
For more options, visit https://groups.google.com/d/optout.

[Christian Linden]

Neil, you wrote somewhere below: 

<< signals => { "term", "kill" } # Try to nicely term before kill. >>

What is this one doing, sending both signals, one after the other?

This is what it looks like:

[root@host001]# cf-agent -KIf /var/cfengine/inputs/R4Promises/killProcesses.cf

2015-09-02T14:25:31+0000     info: /default/killProcesses/processes/'cf-serverd'[0]: Signalled 'term' (15) to process 3881 (root      3881     1  3881  0.0  5.1  39568   0      5940    1 14:25       00:16 00:00:00 /var/cfengine/bin/cf-serverd)

2015-09-02T14:25:31+0000     info: /default/killProcesses/processes/'cf-serverd'[0]: Signalled 'kill' (9) to process 3881 (root      3881     1  3881  0.0  5.1  39568   0      5940    1 14:25       00:16 00:00:00 /var/cfengine/bin/cf-serverd)

2015-09-02T14:25:31+0000     info: /default/killProcesses/processes/'cf-monitord'[1]: Signalled 'term' (15) to process 3890 (root      3890     1  3890  0.3  6.1  39488   0      7096    1 14:25       00:15 00:00:00 /var/cfengine/bin/cf-monitord)

2015-09-02T14:25:31+0000    error: /default/killProcesses/processes/'cf-monitord'[1]: Couldn't send promised signal 'kill' (9) to pid 3890 (might be dead). (kill: No such process)

2015-09-02T14:25:31+0000     info: /default/killProcesses/processes/'cf-execd'[2]: Signalled 'term' (15) to process 3872 (root      3872     1  3872  0.0  2.8  35988   0      3288    1 14:25       00:16 00:00:00 /var/cfengine/bin/cf-execd)

2015-09-02T14:25:31+0000     info: /default/killProcesses/processes/'cf-execd'[2]: Signalled 'kill' (9) to process 3872 (root      3872     1  3872  0.0  2.8  35988   0      3288    1 14:25       00:16 00:00:00 /var/cfengine/bin/cf-execd)

[root@host001]#

Is there no test if the term succeeded?

Best,

Chris

Am Donnerstag, 27. August 2015 14:03:59 UTC+2 schrieb Neil Watson:

[Neil Watson]

On Wed, Sep 02, 2015 at 07:39:31AM -0700, Christian Linden wrote:
>
>
> Neil, you wrote somewhere below: 
> << signals => { "term", "kill" } # Try to nicely term before kill. >>
> What is this one doing, sending both signals, one after the other?

Yes. I do not know what happens at low level. Because I'm sending signals
rather than using a special stop script I don't care so long as the
process goes away.

https://docs.cfengine.com/docs/master/reference-promise-types-processes.html#signals

[Brian Bennett]

I've dtraced it. Signals are sent in order, either as fast as possible or with an extremely short delay between them. I don't really recommend listing both term and kill because they happen so fast it might as well be just kill. Better to set up a mechanism to send term on the first pass and kill on passes two and three.

--
Brian Bennett
Looking for CFEngine training?
http://www.verticalsysadmin.com/

[Neil Watson]

On Wed, Sep 02, 2015 at 08:06:23AM -0700, Brian Bennett wrote:
>I've dtraced it. Signals are sent in order, either as fast as possible
>or with an extremely short delay between them. I don't really recommend
>listing both term and kill because they happen so fast it might as well
>be just kill. Better to set up a mechanism to send term on the first
>pass and kill on passes two and three.

Brian, I think you should open a bug for this.

[Christian Linden]

Excellent, Brian, thanks for investigating and confirming my assumption!