basename: invalid option -- 'b' in maintenance-tick process reaper #392

New issue

Closed

opened 2026-07-15 21:01:06 +00:00 by igor · 0 comments

igor commented

2026-07-15 21:01:06 +00:00

Collaborator

Diagnosis

During the maintenance/recovery portion of the tick, a basename invocation is receiving an argument that begins with a dash (-b...), so it's being parsed as an option flag instead of a path. This is the classic "unguarded argument" shell bug: a variable containing a value starting with - (or a missing -- end-of-options guard) is passed straight to basename.

It fired in two separate ticks this hour (15:38 and 15:41), from tick subprocesses spawned right after recovery sweep (igor) and just before maintenance: no repos eligible this week. The timing lines up with the newly-merged #389 ("reap stale headless-browser process trees at the top of the maintenance tick") — that reaper likely feeds a process arg/command string into basename without quoting or a -- guard, so this looks like a regression from that change rather than something a recent commit already fixes.

The tick itself still completes ("-- continuing"), so this is non-fatal, but the reaping step is almost certainly failing silently, defeating the purpose of #389.

Evidence

Jul 15 15:38:22 igor.sherver.org tick.sh[1424253]: basename: invalid option -- 'b'
Jul 15 15:38:22 igor.sherver.org tick.sh[1424253]: Try 'basename --help' for more information.
Jul 15 15:41:10 igor.sherver.org tick.sh[1426896]: basename: invalid option -- 'b'
Jul 15 15:41:10 igor.sherver.org tick.sh[1426896]: Try 'basename --help' for more information.

Fixed looks like

The reaper's basename call is hardened — e.g. basename -- "$path" (or basename "./$path") — so command/arg strings beginning with - no longer get misparsed, and the maintenance tick runs without emitting basename: invalid option warnings.

service: agent.service
severity: medium
window: 2026-07-15 15:00-16:00 (filed by the hourly logwatch pass)

## Diagnosis During the maintenance/recovery portion of the tick, a `basename` invocation is receiving an argument that begins with a dash (`-b...`), so it's being parsed as an option flag instead of a path. This is the classic "unguarded argument" shell bug: a variable containing a value starting with `-` (or a missing `--` end-of-options guard) is passed straight to `basename`. It fired in two separate ticks this hour (15:38 and 15:41), from tick subprocesses spawned right after `recovery sweep (igor)` and just before `maintenance: no repos eligible this week`. The timing lines up with the newly-merged #389 ("reap stale headless-browser process trees at the top of the maintenance tick") — that reaper likely feeds a process arg/command string into `basename` without quoting or a `--` guard, so this looks like a regression from that change rather than something a recent commit already fixes. The tick itself still completes ("-- continuing"), so this is non-fatal, but the reaping step is almost certainly failing silently, defeating the purpose of #389. ## Evidence ``` Jul 15 15:38:22 igor.sherver.org tick.sh[1424253]: basename: invalid option -- 'b' Jul 15 15:38:22 igor.sherver.org tick.sh[1424253]: Try 'basename --help' for more information. Jul 15 15:41:10 igor.sherver.org tick.sh[1426896]: basename: invalid option -- 'b' Jul 15 15:41:10 igor.sherver.org tick.sh[1426896]: Try 'basename --help' for more information. ``` ## Fixed looks like The reaper's `basename` call is hardened — e.g. `basename -- "$path"` (or `basename "./$path"`) — so command/arg strings beginning with `-` no longer get misparsed, and the maintenance tick runs without emitting `basename: invalid option` warnings. --- service: agent.service severity: medium window: 2026-07-15 15:00-16:00 (filed by the hourly logwatch pass)