Changeset View
Standalone View
etc/rc
Show First 20 Lines • Show All 114 Lines • ▼ Show 20 Lines | |||||
esac | esac | ||||
# The firstboot sentinel might be on a newly mounted filesystem; look for it | # The firstboot sentinel might be on a newly mounted filesystem; look for it | ||||
# again and unset skip_firstboot if we find it. | # again and unset skip_firstboot if we find it. | ||||
if [ -e ${firstboot_sentinel} ]; then | if [ -e ${firstboot_sentinel} ]; then | ||||
skip_firstboot="" | skip_firstboot="" | ||||
fi | fi | ||||
files=`rcorder ${skip} ${skip_firstboot} /etc/rc.d/* ${local_rc} 2>/dev/null` | if checkyesno rc_parallel; then | ||||
for _rc_elem in ${files}; do | _rc_parallel='-p' | ||||
else | |||||
_rc_parallel='' | |||||
fi | |||||
files=`rcorder ${_rc_parallel} ${skip} ${skip_firstboot} /etc/rc.d/* ${local_rc} 2>/dev/null` | |||||
echo "$files" | while read line | |||||
do | |||||
cem: Usual style convention in this file seems to be `; do` on the same line as the `while` or `if`. | |||||
for _rc_elem in ${line}; do | |||||
case "$_rc_elem_done" in | case "$_rc_elem_done" in | ||||
Not Done Inline ActionsWhere is this variable set? ngie: Where is this variable set? | |||||
Not Done Inline ActionsLines 97-100 above. The name is a little confusing/misleading; it contains the set of "early" rc scripts that were completed already, in the loop lines 98-105. It is not updated as regular rc scripts are run (before or after this change). (Also, this section of the code isn't really changed in this revision, it's just indented an extra level.) cem: Lines 97-100 above. The name is a little confusing/misleading; it contains the set of "early"… | |||||
*" $_rc_elem "*) continue ;; | *" $_rc_elem "*) continue ;; | ||||
esac | esac | ||||
if [ -n ${_rc_parallel} ]; then | |||||
cemUnsubmitted Not Done Inline ActionsMight be more clearly expressed as if checkyesno rc_parallel, but I don't feel strongly about it. cem: Might be more clearly expressed as `if checkyesno rc_parallel`, but I don't feel strongly about… | |||||
impUnsubmitted Not Done Inline Actionsother places use it, and while consistency is the hobgoblins of small minds, it's a useful hobgoblin... imp: other places use it, and while consistency is the hobgoblins of small minds, it's a useful… | |||||
run_rc_script ${_rc_elem} ${_boot} & | |||||
cemUnsubmitted Not Done Inline ActionsAs ngie points out, this doesn't really handle failing scripts in the same way (I think — I'm not a shell expert). run_rc_script traps SIGQUIT (just to print out a message about what script was interrupted before re-raising the signal) and SIGINT (to exit rc(8)); as well as handling SIGINFO to print a diagnostic about the running script. In this patch's rc_parallel mode, both the QUIT and INT handlers are broken (if I understand correctly). If an rc script receives QUIT, it will not forward QUIT to the parent rc process but instead exit with signal itself. If an rc script receives INT, it will do basically the same thing — exit with error rather than signal, but either way, the parent rc process is not signaled, and we do not return to single user. Additionally, the user pressing ^C or ^\ at the console will no longer signal a running rc script, but instead the primary rc process. I don't know good ways to fix these differences in shell. wait without arguments always returns zero, but theoretically we could count the number of commands in $line and wait for each individual background job. Then we could check for SIGQUIT exit (128+3) or SIGINT exit (1) and return to single user. That addresses one aspect of the difference, but not the lack of console interaction with running scripts. I don't have a good solution for that. cem: As ngie points out, this doesn't really handle failing scripts in the same way (I think — I'm… | |||||
else | |||||
run_rc_script ${_rc_elem} ${_boot} | run_rc_script ${_rc_elem} ${_boot} | ||||
fi | |||||
done | |||||
[ -n ${_rc_parallel} ] && wait | |||||
impUnsubmitted Not Done Inline ActionsThis is completely lame. We do each layer then wait. But that's lame, given the topology sort we're doing, we'll wind up doing more waiting than we need to. imp: This is completely lame. We do each layer then wait. But that's lame, given the topology sort… | |||||
done | done | ||||
# Remove the firstboot sentinel, and reboot if it was requested. | # Remove the firstboot sentinel, and reboot if it was requested. | ||||
# Be a bit paranoid about removing it to handle the common failure | # Be a bit paranoid about removing it to handle the common failure | ||||
# modes since the consequence of failure can be big. | # modes since the consequence of failure can be big. | ||||
# Note: this assumes firstboot_sentinel is on / when we have | # Note: this assumes firstboot_sentinel is on / when we have | ||||
# a read-only /, or that it is on media that's writable. | # a read-only /, or that it is on media that's writable. | ||||
if [ -e ${firstboot_sentinel} ]; then | if [ -e ${firstboot_sentinel} ]; then | ||||
Show All 15 Lines |
Usual style convention in this file seems to be ; do on the same line as the while or if.