When the scheduler checks whether the last run of a job has finished,
it dies if the task log of that run does not exist. The job is then
skipped with 'could not update job state, skipping - no such task' on
every iteration, so it never runs again until its state file is
cleaned up manually.
The task log can be gone, for example after a crash. If the task is
not running anymore, treat it as stopped with an error status instead,
so that the job gets scheduled again, like Proxmox Backup Server does
since commit 48fbce07 ("fix #4895: scheduled jobs: ignore task-log not
found error").
The check now comes after the one whether the task is still running,
so a running task does not get marked as stopped.
Signed-off-by: Michal Fox <me@dualfroz.com>
All backup job API calls that take an existing job ID use the
'pve-backup-jobid' option, which is limited to 50 characters. The
create call uses its own 'id' parameter without that limit, so a longer
ID can be created, but the job can then neither be read, updated nor
deleted through the API or the web UI, and has to be removed from
jobs.cfg by hand.
Apply the same limit when creating the job.
Signed-off-by: Michal Fox <me@dualfroz.com>
A backup job in pool mode keeps referencing its pool after the pool got
deleted. Resolving the guests of such a job dies with "pool '<name>'
does not exist", and since get_included_vmids() did not catch this, the
whole /cluster/backup-info/not-backed-up call failed. The GUI then hides
the "Show guests without backup job" button, so users lose exactly the
overview that would tell them some guests are no longer backed up.
Catch the error per job, warn about it and continue with the remaining
jobs. The broken job does not back up anything, so its guests correctly
show up as not covered by any backup job.
Add a test for get_included_vmids() covering this case.
Signed-off-by: Michal Fox <me@dualfroz.com>
dualfroz
upstream