Bug 1518429
Summary: | /etc/init.d/functions uses non-posix syntax - in recent update | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Chris Cheney <ccheney> | |
Component: | initscripts | Assignee: | David Kaspar // Dee'Kej <deekej> | |
Status: | CLOSED ERRATA | QA Contact: | Daniel Rusek <drusek> | |
Severity: | urgent | Docs Contact: | Petr Bokoc <pbokoc> | |
Priority: | urgent | |||
Version: | 6.9 | CC: | bbreard, deekej, drusek, fsumsal, initscripts-maint-list, kdudka, mkolaja, msekleta, svashisht, thozza | |
Target Milestone: | rc | Keywords: | Regression | |
Target Release: | --- | |||
Hardware: | All | |||
OS: | All | |||
Whiteboard: | ||||
Fixed In Version: | initscripts-9.03.59-1.el6 | Doc Type: | Bug Fix | |
Doc Text: |
*KSH* no longer fails to process `/etc/init.d/functions`
The Korn Shell (*KSH*) is unable to process code where the word `local` appears on the same line as an array definition. This previously caused *KSH* to fail to source the `/etc/init.d/functions` file. This update provides a workaround to the *KSH* limitation, and the function file is now being sourced as expected.
Note that *KSH* may still be unable use some of the functions in `/etc/init.d/functions` file. This update only allows KSH to not fail during the sourcing of `/etc/init.d/functions`.
|
Story Points: | --- | |
Clone Of: | ||||
: | 1554364 (view as bug list) | Environment: | ||
Last Closed: | 2018-06-19 05:20:44 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1494481, 1554364 |
Description
Chris Cheney
2017-11-28 21:58:47 UTC
Hello Chris,
looking at this piece of code I can tell you this:
* the syntax used there was chosen to obtain the stat value directly from the shell script (i.e. to not use any subshells/subprocesses, which would have different stat value)
* because of this limitation some utilities (like 'cat' for example) can't be used to solve this in other way
However, based on my testing I have found out this:
* if you use 'local stat=', you will get the syntax error
* if you use just 'stat=', the ksh will parse it successfully
This looks like a bug in ksh, and I will discuss with ksh maintainer what to do about it.
For now, the workaround for this issue could be this:
---------------------------------
diff --git a/rc.d/init.d/functions b/rc.d/init.d/functions
index e1d6ecd..e8e3bfd 100644
--- a/rc.d/init.d/functions
+++ b/rc.d/init.d/functions
@@ -111,8 +111,12 @@ __kill_pids_term_kill() {
local try=0
local delay=3;
local pid=
- local stat=($(< /proc/self/stat))
+
+ # 'stat' variable can't be a local variable, because it leads to syntax
+ # error when ksh is used. Therefore we use global variable & unset it later.
+ stat=($(< /proc/self/stat))
local base_stime=${stat[21]}
+ unset stat
if [ "$1" = "-d" ]; then
delay=$2
---------------------------------
> THIS IS FOR TESTING PURPOSES ONLY! DO NOT USE IT ON PRODUCTION MACHINES!
Problem while sourcing the functions in ksh isn't the local keyword (even though it will blow up if you try to call the function using it), but the combination of local keyword and arrays on the same line. This is the original piece of code that causes source in ksh to fail, local stat=($(/proc/self/stat)) However, if you instead rewrite it as follows, then sourcing in ksh will work. local stat= stat=($(/proc/self/stat)) I propose to use this approach instead of a workaround suggested in comment #4, because this approach has the benefit that it doesn't change the semantics for users running bash, i.e. it is safer. (In reply to Michal Sekletar from comment #10) > This is the original piece of code that causes source in ksh to fail, > local stat=($(/proc/self/stat)) Minor correction. Original code reads, local stat=($(< /proc/self/stat)) Hence, fix should look as follows, local stat stat=($(< /proc/self/stat)) Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:1908 |