On Sat, Oct 08, 2022 at 07:25:26PM +0000, Klemens Nanni wrote:
> If /usr is mounted read-only, kernel relinking fails silently without
> any log trace.
>
> # ksh /usr/libexec/reorder_kernel
> /usr/libexec/reorder_kernel[35]: cannot create
> /usr/share/relink/kernel/GENERIC.MP/relink.log: Read-only file system
>
> This stderr line does not show up during boot because init(8) redirects
> stdout/err to /dev/null, executes rc(8) which inherits this and executes
> reorder_kernel with both streams thus discarded.
>
> Eventually, I'd like reorder_kernel to temporarily remount $KERNEL_DIR
> read-write, just like rc's reorder_libs() does. I have a diff for that
> but would like to approach things in smaller steps.
>
> So first, defer the logfile setup after the syslog/console setup such
> that mkdir's failure triggers the ERR trap and users get notified:
>
> # ksh ./reorder_kernel.sh
> ./reorder_kernel.sh[40]: cannot create
> /usr/share/relink/kernel/GENERIC.MP/relink.log: Read-only file system
> # tail -n1 /var/log/daemon
> Oct 13 17:04:06 pbp reorder_kernel.sh: kernel relinking done
>
> As of now, this logs success despite actual failure because of ksh's
> redirection/trap bug (see mail on tech@): mkdir does not fail because
> the directory already exists, so `exec 1>$LOGFILE' tries to truncate but
> fails to trigger the ERR trap, thus hitting the non-default EXIT trap.
>
> With ksh fixed this would log
> Oct 13 17:04:06 pbp reorder_kernel.sh: failed -- see
> /usr/share/relink/kernel/GENERIC.MP/relink.log
> which admittedly misleading, given that creating/truncating that vary
> logfile is the failure reason, but it seems better than silent nothing.
ksh's exec got fixed, so failure is now logged with this diff:
# tail -n0 -f /var/log/messages
[1] 95776
# /usr/libexec/reorder_kernel
/usr/libexec/reorder_kernel[35]: cannot create
/usr/share/relink/kernel/GENERIC.MP/relink.log: Read-only file system
no log except stderr
# ksh ./reorder_kernel.sh
./reorder_kernel.sh[40]: cannot create
/usr/share/relink/kernel/GENERIC.MP/relink.log: Read-only file system
Oct 16 09:16:37 eru reorder_kernel.sh: failed -- see
/usr/share/relink/kernel/GENERIC.MP/relink.log
same "failed" message in xconsole(1)
> It could set up an intermediate trap or truly silently bail out on
> read-only FFS just like it does for NFS now, but it seems best to handle
> ro /usr as mentioned as a follow-up step.
Anyone?
This diff now works as expected; not perfect but an improvement, imho.
Feedback? Objection? OK?
Index: reorder_kernel.sh
===================================================================
RCS file: /cvs/src/libexec/reorder_kernel/reorder_kernel.sh,v
retrieving revision 1.11
diff -u -p -r1.11 reorder_kernel.sh
--- reorder_kernel.sh 13 May 2022 13:20:16 -0000 1.11
+++ reorder_kernel.sh 10 Oct 2022 00:15:58 -0000
@@ -30,15 +30,15 @@ LOGFILE=$KERNEL_DIR/$KERNEL/relink.log
PROGNAME=${0##*/}
SHA256=/var/db/kernel.SHA256
-# Create kernel compile dir and redirect stdout/stderr to a logfile.
-mkdir -m 700 -p $KERNEL_DIR/$KERNEL
-exec 1>$LOGFILE
-exec 2>&1
-
# Install trap handlers to inform about success or failure via syslog.
trap 'trap - EXIT; logger -st $PROGNAME \
"failed -- see $LOGFILE" >>/dev/console 2>&1' ERR
trap 'logger -t $PROGNAME "kernel relinking done"' EXIT
+
+# Create kernel compile dir and redirect stdout/stderr to a logfile.
+mkdir -m 700 -p $KERNEL_DIR/$KERNEL
+exec 1>$LOGFILE
+exec 2>&1
if [[ -f $KERNEL_DIR.tgz ]]; then
rm -rf $KERNEL_DIR/$KERNEL/*
