Using the 'timeout' command

In Linux there is timeout command (usually in /usr/bin/timeout) which is very handy when you really want to restrict possibly long running commands. Here I want to show a couple of invocations to explain its usage.

First of all: timeout exits with error code 124 if the timeout has been reached.
Of particular interest is the handling of exit codes if commands are failing.

I am playing with various invocations of a timeout setting of 3 seconds and a sleep command of 5 seconds and vice versa.

	Output	Exit code
The timeout threshold is reached.
timeout 3 sleep 5		124
timeout 3 sh -c "sleep 5; exit 1"		124
timeout 3 sh -c "echo something; sleep 5; exit 1"	something	124	Failure but part of the commands ran successfully creating output.
timeout 3 sh -c " sleep 5; echo something; exit 1"		124
The timeout threshold is not reached.
timeout 5 sleep 3		0	Success. The command finished before the timeout threshold.
timeout 3 sh -c "exit 1"		1	Failure. The command finished before the timeout threshold but with an error.
timeout 3 sh -c "echo something; exit 1"	something	1	Failure. The commands ran and finished before the timeout threshold but with an error.

Here is an example that shows how a loop gets executed partially.

timeout 3 sh -c "for i in 1 2 3; do sleep 1; echo i=\$i;  done"

i=1
i=2

and exit code 124

In this case one needs to carefully continue and understand possible consequences of a partially executed command chain and how to recover from timeout errors.

Error handling could be done this way:

case $? in
0)
  # all ok
  ;;
124)
  # this was a timeout
  ;;
*)
  # some other error induced by the executed command(s)
  ;;
esac

Maybe this usage is also helpful sometimes: capture only the timeout exit code.

timeout 3 sh -c "echo something; sleep 5" || { [ $? -eq 124 ] && echo TIMEOUT; }
echo $?

will show output of the executed command, the timeout exit code check and an exit code 0

something
TIMEOUT
0

Interesting to see what happens when the executed command fails. The exit code of the failed command is still available to subsequent checks.

timeout 3 sh -c "echo something; exit 1" || { [ $? -eq 124 ] && echo TIMEOUT; }
echo $?

will show output of the executed command(s) and the exit code of the command chain

something
1

Ansible tags with 'include'

When using the include directive things do not quite work as I would expect when I also add a tag to the include section.

Note: this was tested with Ansible 2.5.2 and python 2.7.15

Scenario

I split the playbook of the previous example into two:
The tasks (tagged in the same fashion as before) have been moved to a new file include_this.yml:

---

- name: Debug No Tag
  debug:
    msg: "No tag"

- name: Debug Tag A
  debug:
    msg: "Tag A"
  tags:
    - tagA

- name: Debug Tag B
  debug:
    msg: "Tag B"
  tags:
    - tagB

- name: Debug Tag A and B
  debug:
    msg: "Tag A and B"
  tags:
    - tagA
    - tagB

The playbook playbook.yml has been reduced to two tasks:

• one debug task
• one include task

I am testing two versions: the second one has an additional tag for the include directive.

Version 1	Version 2
- name: Debug Playbook hosts: localhost tasks: - name: Debug No Tag in Playbook debug: msg: "No tag in playbook" - name: Include include: include_this.yml	- name: Debug Playbook hosts: localhost tasks: - name: Debug No Tag in Playbook debug: msg: "No tag in playbook" - name: Include include: include_this.yml tags: - tagA

The playbook is run as

ansible-playbook [--tags tagA] [--skip-tags tagB] playbook.yml

Results for version 1

If called with --tags or --skip-tags version 1 delivers the same results as described in my previous post when the include file was part of the playbook.
The additional 5th task in playbook.yml is executed in case of --skip-tags tagB or when no arguments are supplied.

no args	TASK [Debug No Tag in Playbook] TASK [Debug No Tag] TASK [Debug Tag A] TASK [Debug Tag B] TASK [Debug Tag A and B]
--tags tagA	TASK [Debug Tag A] TASK [Debug Tag A and B]
--tags tagA --skip-tags tagB	TASK [Debug Tag A]
--skip-tags tagB	TASK [Debug No Tag in Playbook] TASK [Debug No Tag] TASK [Debug Tag A]
Now I am reversing tagA and tagB in the call which leads to the expected results.
--tags tagB	TASK [Debug Tag B] TASK [Debug Tag A and B]
--tags tagB --skip-tags tagA	TASK [Debug Tag B]

Results for version 2

no args	TASK [Debug No Tag in Playbook] TASK [Debug No Tag] TASK [Debug Tag A] TASK [Debug Tag B] TASK [Debug Tag A and B]	Same as version 1. All five tasks are being executed for both version of the playbook. This works as expected. No restrictions of any sort apply.
--tags tagA	TASK [Debug No Tag] TASK [Debug Tag A] TASK [Debug Tag B] TASK [Debug Tag A and B]	All four task of the included files are being executed. No filtering by tagA for the included file takes place. This was a complete suprise to me. It seems that the tagging of the include step supersedes somehow the tags of the included file.
--tags tagA --skip-tags tagB	TASK [Debug No Tag] TASK [Debug Tag A]	The negative filter is applied to the result before and leaves two tasks for execution.
--skip-tags tagB	TASK [Debug No Tag in Playbook] TASK [Debug No Tag] TASK [Debug Tag A]	Same as version 1. The two tasks with tagB are skipped and the other three are executed.
--tags tagB	TASK [Debug Tag B] TASK [Debug Tag A and B]	Same as version 1. The two tasks with tagB are executed and the tag setting in the include directive is not taken into account.
--tags tagB --skip-tags tagA	... nothing ...	Now here is a surprise. The --skip-tags tagA has skipped the whole include file and no task is being executed at all.

An explanation using sets

Let's look at it from a set perspective.

--tags tagA	--skip-tags tagA
These two results are complementary and - if joined - build the complete set.
TASK [Debug No Tag] TASK [Debug Tag A] TASK [Debug Tag B] TASK [Debug Tag A and B]	TASK [Debug No Tag in Playbook]
Here the same complimentary sets for tagB.
--tags tagB	--skip-tags tagB
TASK [Debug Tag B] TASK [Debug Tag A and B]	TASK [Debug No Tag in Playbook] TASK [Debug No Tag] TASK [Debug Tag A]

Now any invocation of --skip-tags leads to an intersection with the respective sets.
Example: --tags tagB --skip-tags tagA: the sets have no task in common and thus nothing will be executed.

Conclusion

My idea was that a tag for the include directive would determine whether the include happens or not. Obviously wrong. It seems that it only determines which other tasks in the playbook.yml are executed i.e. it prohibits the untagged task from being run. The include takes place in any case (see the examples when using tagB either in --tags or --skip-tags) but in a strange way since only other tags than the supplied one are applied. I find this hard to remember or explain so my personal rule of mutual tag exclusion will be:

• tagged include section => no tags in the included file
• tags in the included file => no tag for the include section

Ansible tags

Lately I got a little confused about properly using Ansible tags so I thought I spend a couple of minutes to create a simple example to show how to use them and also explain the pitfalls (at least how I see them).

Note: this was tested with Ansible 2.5.2 and python 2.7.15

Scenario

My example scenario is simple:

• I have a small playbook with 4 tasks: one task without tag, two tasks with a different tag each and the 4th task with both tags

  - name: Debug Playbook
    hosts: localhost
    tasks:
      - name: Debug No Tag
        debug:
          msg: "No tag"
  
      - name: Debug Tag A
        debug:
          msg: "Tag A"
        tags:
          - tagA
  
      - name: Debug Tag B
        debug:
          msg: "Tag B"
        tags:
          - tagB
  
      - name: Debug Tag A and B
        debug:
          msg: "Tag A and B"
        tags:
          - tagA
          - tagB
  

• I am running 4 invocations of the playbook with a mix of --tags and --skip-tags to show the effects on the possible outcomes

Results

• No tag arguments:

  ansible-playbook playbook.yml

  All tasks are executed.

  TASK [Debug No Tag] *****************************
  ok: [localhost] => {
      "msg": "No tag"
  }
  
  TASK [Debug Tag A] ******************************
  ok: [localhost] => {
      "msg": "Tag A"
  }
  
  TASK [Debug Tag B] ******************************
  ok: [localhost] => {
      "msg": "Tag B"
  }
  
  TASK [Debug Tag A and B] ************************
  ok: [localhost] => {
      "msg": "Tag A and B"
  }
  

• Supply --tags tagA:

  ansible-playbook --tags tagA playbook.yml

  All tasks are executed where tagA is listed. This works as expected: --tags acts as a filter.

  TASK [Debug Tag A] ******************************
  ok: [localhost] => {
      "msg": "Tag A"
  }
  
  TASK [Debug Tag A and B] ************************
  ok: [localhost] => {
      "msg": "Tag A and B"
  }
  

• Use both --tags and --skip-tags:

  ansible-playbook --tags tagA --skip-tags tagB playbook.yml

  Only the task tagged tagA is executed. The task with both tags is skipped.
  This actually got me confused. Now when writing this blog it seems obvious: --skip-tags acts as a negative filter i.e. it will skip all tasks where tagB is mentioned.

  TASK [Debug Tag A] ******************************
  ok: [localhost] => {
      "msg": "Tag A"
  }
  

• Supply --skip-tags tagB:

  ansible-playbook --skip-tags tagB playbook.yml

  All tasks are skipped where tagB is listed, in particular the task without tags is also executed.

  TASK [Debug No Tag] *****************************
  ok: [localhost] => {
      "msg": "No tag"
  }
  
  TASK [Debug Tag A] ******************************
  ok: [localhost] => {
      "msg": "Tag A"
  }
  

To remember

• As soon as you switch to using tags via --tags none of the untagged tasks will be executed any longer. If you want the untagged task to be executed in any case you need to supply all possible tags of your playbooks.
• When mixing --tags and --skip-tags in one call both filters work in conjunction: --tags selects all tasks with the given tags(s), --skip-tags reduces this set by all tasks with the given skip tags.

---

The scenario can get a bit trickier when invoking include sections. I will explain this in another blog.

A list of Google fonts

Here is a list of Google fonts. It is constructed with Javascript and CSS and dynamically embedded into this blog.

Some fonts can be made more effective in bigger sizes or by applying font effects but that would be too much for this overview.
Enjoy and find your font.

How to use Google fonts (even in this blog)

Google provides a huge list of fonts and it describes how to use them in detail, in particular applying font effects and more.

I thought it worthwhile to capture the essence of using fonts and also I wanted to see if I could use Google fonts in this blog.

Using Google fonts boils down to three things actually:

• load the font from Google by supplying a link in the <head> section of your HTML document

  <link href="https://fonts.googleapis.com/css?family=Amarante" rel="stylesheet">
  

• defining a corresponding style e.g. a class style with a name

  <style>
    .coolFont { font-family: Amarante }
  </style>
  

• applying this font to any element with

  < ... class="coolFont" ... >
  

Here is a Javascript code snippet (which I actually included in the HTML text) which dynamically loads three fonts and defines three correponding styles. It applies each of the styles to an h1 element.

<script>
var fonts = [ 'Acme', 'Amarante', 'Audiowide' ]

for( i=0; i<fonts.length; i++ ) {
  var style = document.createElement( 'STYLE' );
  // Define class style '.font0', '.font1' etc.
  style.innerHTML = ".font" + i + "{ font-family: " + fonts[i] + ";}"
  document.getElementsByTagName('head')[0].appendChild( style );

  var  link = document.createElement( 'LINK' );
  link.setAttribute( 'href', 'https://fonts.googleapis.com/css?family=' + encodeURI( fonts[i] ) );
  link.setAttribute( 'rel', "stylesheet" ) ;
  document.getElementsByTagName('head')[0].appendChild( link );
}
</script>

<h1 class="font0">Cool font, dude! </h1>
<h1 class="font1">Cool font, dude! </h1>
<h1 class="font2">Cool font, dude! </h1>

This will create a links like this

<link href="https://fonts.googleapis.com/css?family=Amarante" rel="stylesheet">

and styles

.font1 {
  font-family: Amarante;
}

and here is the result

Cool font, dude!

Cool font, dude!

Cool font, dude!