Bug 450946 - RFE: Comment to be added to "daemon" function
RFE: Comment to be added to "daemon" function
Status: CLOSED NEXTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: initscripts (Show other bugs)
5.2
All Linux
low Severity low
: rc
: ---
Assigned To: initscripts Maintenance Team
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-11 16:40 EDT by David Tonhofer
Modified: 2009-03-20 11:17 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-20 11:17:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
A simple shell script; creates files in /tmp (1005 bytes, application/x-sh)
2008-06-12 16:45 EDT, David Tonhofer
no flags Details

  None (edit)
Description David Tonhofer 2008-06-11 16:40:10 EDT
Description of problem:

The "daemon" function of "/etc/rc.d/init.d/functions" is confusing. A remark
shall help! Proposal:

-------------
The "daemon" function erases the environment, so one has to pass everything
as parameters. "daemon" uses "initlog" on the to-be-started-program, so any
stdout/stderr will go to some syslog destination, instead of current
stdout/stderr, except if the program exits <> 0. 'daemon()' behaves
unintuitively, in effect it just takes several options and a __single__
argument, which is a string that will be passed to bash for execution. If you
pass multiple arguments, they will be fused into a single one by enclosure into
a double-quote. Complex arguments with whitespace inside will only survive if
single-quoted (but not if double-quoted). Double quotes within any arguments
will lead to failure of the daemon call. An example of passing multiple
arguments would be:

daemon --user=tomcat "'$script' stop '$TOMCAT_INSTANCE_ID' '$CATALINA_HOME'
'$CATALINA_BASE'"
-------------
Comment 1 Bill Nottingham 2008-06-12 11:53:33 EDT
Well, the first two sentences are just wrong - there's no specific environment
cleaning done, and it's not run through initlog in RHEL 5.
Comment 2 David Tonhofer 2008-06-12 16:45:42 EDT
Created attachment 309141 [details]
A simple shell script; creates files in /tmp

Running this will create a script in /tmp to be run through "daemon". "daemon"
is then called, calling the script in /tmp, which writes a result, also to
/tmp. That result is then "catted"
Comment 3 David Tonhofer 2008-06-12 16:47:49 EDT
Yes, you are right, this is shite. It applies to RHES4, not RHES5, as the
scripts changed. I have not checked behaviour on RHES5.

-------- On RHES5:

# And start it up.
if [ -z "$user" ]; then
   $nice /bin/bash -c "$corelimit >/dev/null 2>&1 ; $*"
else
   $nice runuser -s /bin/bash - $user -c "$corelimit >/dev/null 2>&1 ; $*"
fi

-------- On RHES4:

# And start it up.
if [ -z "$user" ]; then
   $nice initlog $INITLOG_ARGS -c "$*"
else
   $nice initlog $INITLOG_ARGS -c "runuser -s /bin/bash - $user -c \"$*\""
fi

-----------------

So let's discuss RHES4. Product should be changed to RHES4 - so maybe the
problem is moot.

There indeed is no specific environment cleaning done. Still, the program called
through daemon() does not "see" any of envvariables set in the rc.d script (a
good thing, probably) - so you have to pass parameters instead. However,
daemon() does not take kindly to those, thus the rather complex quoting -- the
only one I got to work. But even so, daemon() will spit out an error in this line:

 # See if it's already running. Look *only* at the pid file.
 if [ -f /var/run/${base}.pid ]; then

as "base" is not a program name only but the program name with its parameters.

See the little attached script.




Comment 4 Bill Nottingham 2009-03-20 11:17:01 EDT
I believe this is fixed in RHEL 5, with the move away from initlog.
Red Hat does not currently plan to provide a resolution for this in a Red hat Enterprise Linux 4 update for currently deployed systems.

With the goal of minimizing risk of change for deployed systems, and in response to customer and partner requirements, Red Hat takes a conservative approach when evaluating changes for inclusion in maintenance updates for currently deployed products. The primary objectives of update releases are to enable new hardware platform support and to resolve critical defects.

Note You need to log in before you can comment on or make changes to this bug.