Summary

Resolves #7473 /claim #7473

Database backups with custom timeouts always fail at 3600s because the shell-level timeout command wrapping the SSH process ignores the user’s configured backup timeout.

Root Cause

The custom backup timeout flows through two layers:

1. PHP Process timeout (Process::timeout()) — correctly uses custom timeout
2. Shell timeout command (wrapping the SSH command) — always uses config('constants.ssh.command_timeout') (3600s)

The shell timeout kills the SSH process at 3600s regardless of what the user configured in the backup settings.

Fix

2 files, 4 lines changed:

1. SshMultiplexingHelper::generateSshCommand() — Added optional ?int parameter. When provided, uses it instead of the hardcoded config value for the shell timeout command.

2. instant_remote_process() — Now passes the effective timeout to generateSshCommand() so the shell timeout matches the PHP process timeout.

Before/After

Before: Backup configured with 10800s timeout -> SSH command runs timeout 3600 ssh ... -> killed at 3600s After: Backup configured with 10800s timeout -> SSH command runs timeout 10800 ssh ... -> completes successfully

Backward Compatibility

When no custom timeout is passed (all existing call sites that don’t pass a timeout), behavior is identical — config('constants.ssh.command_timeout') is used as before. Only callers that explicitly pass a timeout (like DatabaseBackupJob) benefit from the fix.