{"id":106,"date":"2015-06-08T12:07:23","date_gmt":"2015-06-08T17:07:23","guid":{"rendered":"https:\/\/adamkuj.net\/blog\/?p=106"},"modified":"2021-05-11T08:59:57","modified_gmt":"2021-05-11T13:59:57","slug":"protip-forcing-clean-exit-status-on-linux-bourne-shell-commandsscripts-with","status":"publish","type":"post","link":"https:\/\/adamkuj.net\/blog\/2015\/06\/08\/protip-forcing-clean-exit-status-on-linux-bourne-shell-commandsscripts-with\/","title":{"rendered":"ProTip: Forcing clean exit status on Linux (Bourne Shell) commands\/scripts with “;:”"},"content":{"rendered":"

Often times in Linux (or BSD, Unix, etc) you want to trigger external commands, but don’t care if they succeed or fail. For example, in Debian, you can execute scripts and commands from \/etc\/network\/interfaces<\/code> using the [pre-]up<\/code> and [post-]down<\/code> directives. However, if something goes wrong and the command doesn’t exit cleanly, the interface action (ifup<\/code> or ifdown<\/code>) will fail. This can happen, for example, when adding a static route (ip route add ...<\/code>) or alias address (ip addr add ...<\/code>) that already exists (\"RTNETLINK answers: File exists\"<\/code>). Another common scenario is using 'ethtool'<\/code> to set interface parameters such as Tx\/Rx queue sizes. If the ethtool<\/code> command “fails” because the value is already set, that will cause the 'ifup'<\/code> or 'ifdown'<\/code> command to fail as well.<\/p>\n

For example, on this particular NIC, ethtool reports that the Maximum RX ring length is 511 descriptors, with a current (default) size of 200 descriptors:<\/p>\n

adam-desktop ~ # ethtool -g eth0
\nRing parameters for eth0:
\nPre-set maximums:
\nRX:\t\t511<\/strong>
\nRX Mini:\t0
\nRX Jumbo:\t0
\nTX:\t\t511
\nCurrent hardware settings:
\nRX:\t\t200<\/strong>
\nRX Mini:\t0
\nRX Jumbo:\t0
\nTX:\t\t511<\/code><\/p>\n

To enhance NIC performance, you can use ethtool<\/code> to max-out the RX descriptors, and the command succeeds (exit status 0):<\/p>\n

adam-desktop ~ # ethtool -G eth0 rx 511
\nadam-desktop ~ # echo $?
\n0
\nadam-desktop ~ # ethtool -g eth0
\nRing parameters for eth0:
\nPre-set maximums:
\nRX:\t\t511<\/strong>
\nRX Mini:\t0
\nRX Jumbo:\t0
\nTX:\t\t511
\nCurrent hardware settings:
\nRX:\t\t511<\/strong>
\nRX Mini:\t0
\nRX Jumbo:\t0
\nTX:\t\t511<\/code><\/p>\n

That’s all fine and dandy. But what but what if you repeat the 'ethtool -G eth0 rx 511'<\/code> command?<\/p>\n

adam-desktop ~ # ethtool -G eth0 rx 511
\nrx unmodified, ignoring
\nno ring parameters changed, aborting
\nadam-desktop ~ # echo $?
\n80<\/code><\/p>\n

If you were running this ethtool<\/code> command as part of a pre-up<\/code> command in Debian’s \/etc\/network\/interfaces<\/code>, it would work fine the first time you ran 'ifup eth0'<\/code>. However, if you then ran 'ifdown eth0'<\/code> followed by another 'ifup eth0'<\/code>, then eth0 would fail to come up the second time around. That behavior fails the principle of least astonishment<\/a>, and is the sort of thing that can cause outages and service failures.<\/p>\n

However, simply appending \";:\"<\/code> to the command causes it to always exit with status 0 (success). When used in a the context of a pre-up<\/code> interface directive, you can ensure that the interface will always come up cleanly. i.e.<\/p>\n

adam-desktop ~ # ethtool -G eth0 rx 511;:
\nrx unmodified, ignoring
\nno ring parameters changed, aborting
\nadam-desktop ~ # echo $?
\n0<\/code><\/p>\n

What’s happening here is that the semi-colon (;<\/code>) is a command separator, and the colon (:<\/code>) effectively means 'true'<\/code>. The exit status of the first command (ethtool -G eth0 rx 511)<\/code> is ignored, and only the exit status of the last command (:)<\/code> is reported.<\/p>\n

A more verbose example of this principle in action:<\/p>\n

adam-desktop ~ # false
\nadam-desktop ~ # echo $?
\n1
\nadam-desktop ~ # true
\nadam-desktop ~ # echo $?
\n0
\nadam-desktop ~ # false;true
\nadam-desktop ~ # echo $?
\n0
\nadam-desktop ~ # true;false
\nadam-desktop ~ # echo $?
\n1<\/code><\/p>\n","protected":false},"excerpt":{"rendered":"

Often times in Linux (or BSD, Unix, etc) you want to trigger external commands, but don’t care if they succeed or fail. For example, in Debian, you can execute scripts and commands from \/etc\/network\/interfaces using the [pre-]up and [post-]down directives. However, if something goes wrong and the command doesn’t exit cleanly, the interface action (ifup […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":["post-106","post","type-post","status-publish","format-standard","hentry","category-networking-tools"],"_links":{"self":[{"href":"https:\/\/adamkuj.net\/blog\/wp-json\/wp\/v2\/posts\/106","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/adamkuj.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/adamkuj.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/adamkuj.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/adamkuj.net\/blog\/wp-json\/wp\/v2\/comments?post=106"}],"version-history":[{"count":21,"href":"https:\/\/adamkuj.net\/blog\/wp-json\/wp\/v2\/posts\/106\/revisions"}],"predecessor-version":[{"id":315,"href":"https:\/\/adamkuj.net\/blog\/wp-json\/wp\/v2\/posts\/106\/revisions\/315"}],"wp:attachment":[{"href":"https:\/\/adamkuj.net\/blog\/wp-json\/wp\/v2\/media?parent=106"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/adamkuj.net\/blog\/wp-json\/wp\/v2\/categories?post=106"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/adamkuj.net\/blog\/wp-json\/wp\/v2\/tags?post=106"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}