Left over process from backup in Task Queue

[rpvw]

v72.0.4

My Backup runs at 02:00 UTC every day and the first part of the backup log looks like this

[2018-06-26 02:00:02 +0000] info [backup] Detected “/backupdrive” in /etc/fstab
[backupmount] Setting up mount
[backupmount] running: /bin/mount /backupdrive
[backupmount] running: /bin/mount -o remount,rw /backupdrive
[2018-06-26 02:00:02 +0000] info [backup] Mount found: /dev/sdb1 on /backupdrive type ext4 (rw)
[2018-06-26 02:00:02 +0000] info [backup] Setting I/O priority to reduce system load: best-effort: prio 6
[2018-06-26 02:00:02 +0000] info [backup] Pruning metadata for backup at /backupdrive/2018-06-26
[2018-06-26 02:00:02 +0000] info [backup] Creating metadata index for backup at /backupdrive/2018-06-26
[2018-06-26 02:00:02 +0000] info [backup] Hard Linking available on "/backupdrive"
[2018-06-26 02:00:02 +0000] info [backup] Starting full MySQL database backups

As can be seen, I have a dedicated disk drive (configured as /backupdrive in fstab) that is mounted on demand by the backup system to store the backups on, and then unmounted for safety on completion.

I am seeing what looks like a an orphan process left over in the Task Queue Monitor

Scheduled (1):
Scheduled Time: Jun 27, 2018 2:00:03 AM
Command: release_mount_lock /backupdrive
Enqueue Time: Jun 26, 2018 2:00:02 AM
Remaining Retries: 1
Task ID: TQ:TaskQueue-Scheduler:6148

The backup was completed successfully without errors, and I have determined that the backup drive was successfully unmounted on the completion of the backup run.

I also saw a 1B file in the /backupdrive filelist called .backupmount_locks, and I wondered if the reason for the orphaned job in the queue is that the drive umount happened before the lock could be flushed ?

Is this intentional, or just the way the backup system works ?

 

[rpvw]

v72.0.5

After last nights backup run, there was no task left in the Queue.

The backup drive was mounted, and the backups completed successfully, and the drive was unmounted.

There was still a 1B file in the /backupdrive filelist called .backupmount_locks, so my previous hypothesis appears to be invalid.

I shall update this if I observe any repeat of the previously reported behaviour.

 

[cPanelLauren]

Hi @rpvw

That task does look standard. The scheduled time for that task to complete was Yesterday at 0200 it was added to the queue on Tuesday. As long as it isn't still present it should be fine.

 

[rpvw]

And this morning, after another successful disk-mount/backup/disk-umount overnight, it was back again

Scheduled (1):
Scheduled Time: Jun 29, 2018 2:00:04 AM
Command: release_mount_lock/backupdrive
Enqueue Time: Jun 28, 2018 2:00:03 AM
Remaining Retries: 1
Task ID: TQ:TaskQueue-Scheduler:6200

I am waiting with bated breath to see what happens after the backup runs again tonight

 

[cPanelLauren]

Hi @rpvw

At this point, 0755 CST June 29 that task should have been completed at 0200 is it still present?

I am waiting with bated breath to see what happens after the backup runs again tonight

me too!!! :D

Thanks!