Bug 50241
| Summary: | /etc/init.d/functions has fragile default-setting of variables | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | dkk |
| Component: | initscripts | Assignee: | Bill Nottingham <notting> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Brock Organ <borgan> |
| Severity: | low | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | rvokal |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 8.31.5-1 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-07-09 03:02:02 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
This should be fixed in FC5, at least for init.d/functions. Thanks for your report. |
From Bugzilla Helper: User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.16-22 i686) Description of problem: When an initscript starts with ``#!/bin/bash'' it may well involve user customizations (e.g. via $BASH_ENV). Bash has an option ("set -u" or "set -o nounset") which causes the shell to treat unset variables as an error. This can cause init scripts to fail for some users. You can make "functions" more robust by replacing lines like this: ``[ -z "$COLUMNS" ] && COLUMNS=80'' with lines like this: ``${COLUMNS:=80}'' The effect should be the same, and would allow those of us who like to use bash with the "nounset" option to keep doing so without tripping over init script failures. Some such init scripts are atd, gpm, halt, netfs and sshd. How reproducible: Always Steps to Reproduce: 1. log in as root 2. append "set -o nounset" to ~/.bashrc 3. try `/etc/init.d/sshd status` Actual Results: The sshd init script bombed out (exit value 1) with: /etc/init.d/sshd: COLUMNS: unbound variable That error comes from the following line in "functions", which is dot-sourced by the sshd init script: [ -z "$COLUMNS" ] && COLUMNS=80 Expected Results: The sshd init script should have told me the status of the sshd service, rather than exiting with a non-zero value. Additional info: My first thought was that init scripts should stick to /bin/sh rather than /bin/bash, but concluded that "functions" is the appropriate place for the fix. Init scripts have valid reasons to use bash functions instead of minimal sh capabilities, and there will always be people you don't know about writing init scripts.