Canceling multiple jobs by job name.
16 views
Skip to first unread message
Brock Palen
Apr 14, 2020, 1:14:46 PM4/14/20
to bareos-users
I common have a case where schedule jobs get pilled on top of each other for a number of reasons.
I cannot use Allow Duplicate Jobs = no because that cancels consolidate jobs for those clients.
Anyway
help cancel
Arguments:
storage=<storage-name> |
jobid=<jobid> |
job=<job-name> |
ujobid=<unique-jobid> |
state=<job_state> |
all yes
Leads me to think I can do
cancel job=<jobname>
This instead prompts me like I ran cancel with with no arguments. Appending all actually selects all queued jobs not just jobs with that name.
Is this a bug or intended behavior?
eg current queue:
26016 Full BackupCatalog.2020-04-11_08.00.00_35 is waiting for higher priority jobs to finish
26110 Full Consolidate.2020-04-12_08.00.00_46 is waiting for higher priority jobs to finish
26111 Full Copy-To-Offsite-Full.2020-04-12_08.00.00_47 is waiting execution
26112 Full Copy-To-Offsite-Incremental.2020-04-12_08.00.00_48 is waiting execution
26113 Full Copy-To-Offsite-Catalog.2020-04-12_08.00.00_49 is waiting execution
26114 Full Migrate_To_Longterm_Full.2020-04-12_08.00.00_50 is waiting execution
26163 Increme melani-surface-Users.2020-04-14_00.06.28_11 is waiting for its start time at 14-Apr-20 13:34
26172 Increme melani-surface-Users.2020-04-14_02.33.03_20 is waiting on max Client jobs
26173 Increme melani-surface-Users.2020-04-14_03.52.09_22 is waiting for its start time at 14-Apr-20 13:20
26174 Increme melani-surface-Users.2020-04-14_05.11.15_23 is waiting on Storage "File"
26175 Increme melani-surface-Users.2020-04-14_07.11.24_24 is waiting on max Client jobs
26184 Increme melani-surface-Users.2020-04-14_09.11.05_43 is waiting for its start time at 14-Apr-20 13:36
26188 Increme mills-feldman-Photos.2020-04-14_10.00.00_47 is waiting for its start time at 14-Apr-20 13:39
26190 Increme melani-surface-Users.2020-04-14_11.51.08_52 is waiting on max Client jobs
*cancel job=melani-surface-Users
Select Job:
1: JobId=26016 Job=BackupCatalog.2020-04-11_08.00.00_35
2: JobId=26110 Job=Consolidate.2020-04-12_08.00.00_46
3: JobId=26111 Job=Copy-To-Offsite-Full.2020-04-12_08.00.00_47
4: JobId=26112 Job=Copy-To-Offsite-Incremental.2020-04-12_08.00.00_48
5: JobId=26113 Job=Copy-To-Offsite-Catalog.2020-04-12_08.00.00_49
6: JobId=26114 Job=Migrate_To_Longterm_Full.2020-04-12_08.00.00_50
7: JobId=26163 Job=melani-surface-Users.2020-04-14_00.06.28_11
8: JobId=26172 Job=melani-surface-Users.2020-04-14_02.33.03_20
9: JobId=26173 Job=melani-surface-Users.2020-04-14_03.52.09_22
10: JobId=26174 Job=melani-surface-Users.2020-04-14_05.11.15_23
11: JobId=26175 Job=melani-surface-Users.2020-04-14_07.11.24_24
12: JobId=26184 Job=melani-surface-Users.2020-04-14_09.11.05_43
13: JobId=26188 Job=mills-feldman-Photos.2020-04-14_10.00.00_47
14: JobId=26190 Job=melani-surface-Users.2020-04-14_11.51.08_52
I just want to cancel all the jobs called melani-surface-Users
Again if I change it to
*cancel job=melani-surface-Users all
It prompts to confirm cancel of _all_ queued jobs not just those with that name.
Thanks
Brock Palen
1 (989) 277-6075
bro...@mlds-networks.com
www.mlds-networks.com
Websites, Linux, Hosting, Joomla, Consulting
I cannot use Allow Duplicate Jobs = no because that cancels consolidate jobs for those clients.
Anyway
help cancel
Arguments:
storage=<storage-name> |
jobid=<jobid> |
job=<job-name> |
ujobid=<unique-jobid> |
state=<job_state> |
all yes
Leads me to think I can do
cancel job=<jobname>
This instead prompts me like I ran cancel with with no arguments. Appending all actually selects all queued jobs not just jobs with that name.
Is this a bug or intended behavior?
eg current queue:
26016 Full BackupCatalog.2020-04-11_08.00.00_35 is waiting for higher priority jobs to finish
26110 Full Consolidate.2020-04-12_08.00.00_46 is waiting for higher priority jobs to finish
26111 Full Copy-To-Offsite-Full.2020-04-12_08.00.00_47 is waiting execution
26112 Full Copy-To-Offsite-Incremental.2020-04-12_08.00.00_48 is waiting execution
26113 Full Copy-To-Offsite-Catalog.2020-04-12_08.00.00_49 is waiting execution
26114 Full Migrate_To_Longterm_Full.2020-04-12_08.00.00_50 is waiting execution
26163 Increme melani-surface-Users.2020-04-14_00.06.28_11 is waiting for its start time at 14-Apr-20 13:34
26172 Increme melani-surface-Users.2020-04-14_02.33.03_20 is waiting on max Client jobs
26173 Increme melani-surface-Users.2020-04-14_03.52.09_22 is waiting for its start time at 14-Apr-20 13:20
26174 Increme melani-surface-Users.2020-04-14_05.11.15_23 is waiting on Storage "File"
26175 Increme melani-surface-Users.2020-04-14_07.11.24_24 is waiting on max Client jobs
26184 Increme melani-surface-Users.2020-04-14_09.11.05_43 is waiting for its start time at 14-Apr-20 13:36
26188 Increme mills-feldman-Photos.2020-04-14_10.00.00_47 is waiting for its start time at 14-Apr-20 13:39
26190 Increme melani-surface-Users.2020-04-14_11.51.08_52 is waiting on max Client jobs
*cancel job=melani-surface-Users
Select Job:
1: JobId=26016 Job=BackupCatalog.2020-04-11_08.00.00_35
2: JobId=26110 Job=Consolidate.2020-04-12_08.00.00_46
3: JobId=26111 Job=Copy-To-Offsite-Full.2020-04-12_08.00.00_47
4: JobId=26112 Job=Copy-To-Offsite-Incremental.2020-04-12_08.00.00_48
5: JobId=26113 Job=Copy-To-Offsite-Catalog.2020-04-12_08.00.00_49
6: JobId=26114 Job=Migrate_To_Longterm_Full.2020-04-12_08.00.00_50
7: JobId=26163 Job=melani-surface-Users.2020-04-14_00.06.28_11
8: JobId=26172 Job=melani-surface-Users.2020-04-14_02.33.03_20
9: JobId=26173 Job=melani-surface-Users.2020-04-14_03.52.09_22
10: JobId=26174 Job=melani-surface-Users.2020-04-14_05.11.15_23
11: JobId=26175 Job=melani-surface-Users.2020-04-14_07.11.24_24
12: JobId=26184 Job=melani-surface-Users.2020-04-14_09.11.05_43
13: JobId=26188 Job=mills-feldman-Photos.2020-04-14_10.00.00_47
14: JobId=26190 Job=melani-surface-Users.2020-04-14_11.51.08_52
I just want to cancel all the jobs called melani-surface-Users
Again if I change it to
*cancel job=melani-surface-Users all
It prompts to confirm cancel of _all_ queued jobs not just those with that name.
Thanks
Brock Palen
1 (989) 277-6075
bro...@mlds-networks.com
www.mlds-networks.com
Websites, Linux, Hosting, Joomla, Consulting
Erich Eckner
Apr 14, 2020, 2:00:36 PM4/14/20
to Brock Palen, bareos-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi,
On Tue, 14 Apr 2020, Brock Palen wrote:
> I common have a case where schedule jobs get pilled on top of each other
> for a number of reasons.
>
> I cannot use Allow Duplicate Jobs = no because that cancels consolidate
> jobs for those clients.
Does the consolidate job have the same name?
"A duplicate job in the sense we use it here means a second or subsequent
job with the same name starts."
https://docs.bareos.org/_images/duplicate-real.svg
>
> Anyway
>
> help cancel
> Arguments:
> storage=<storage-name> |
> jobid=<jobid> |
> job=<job-name> |
> ujobid=<unique-jobid> |
> state=<job_state> |
> all yes
>
> Leads me to think I can do
>
> cancel job=<jobname>
>
> This instead prompts me like I ran cancel with with no arguments.
> Appending all actually selects all queued jobs not just jobs with that
> name.
anyway, this has bugged me, too - though, I only have a handfull of
clients, so it was not that pressing for me :-)
> --
> You received this message because you are subscribed to the Google Groups "bareos-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bareos-users...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/bareos-users/44B9099B-0B19-4C98-9B02-CE606569F6AE%40mlds-networks.com.
>
regards,
Erich
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl6V+jAACgkQCu7JB1Xa
e1pMqg//TffFg3XYEokJ7C/vzwTv4efoUUZZx68xhTsDah/qpHTA53svd14HzTJU
60uyqeo/3Csx2CsR+qWhcNXbsBKkFK5FLIs7SWfqhAc31y5PmaOj/nOK9mkU72O0
2U/q6toxHWAMv8zROxb3bKqB+LigeNBR9uQ6KZKlwvPAvbn22ipTR1/ikkGgWP54
CDOcmHOXDGnaewwkO2OtDQThFjWq3entx5Jqfbc31MqxrkVyoZ/b+N7TjID1sxy+
KKnYenNocWJs5gszNAwzmzPQL1fmVt8IMxE7/d7o5YvRjdct9gD7JLfkqsyYLL9l
Fq+PEXE/yoY06pAxh6Ug+PJUzcZXTL+yp1ciOF1nV7ZOEWxFyY8+HSJ1j25LyYzy
HCGqELOm1bBV1fS9Zv9aJht4kXzLnkKMat8hLCRoKIp3Slyybs6/oLPi/D5VNJH3
9u8yo5mcbL4k0V3WAXC+wksXtPgWf4B94mB1hQILQ5SftRFlIrFGaCh3k5gBnLCs
sCgTV+NPyC1CnJZTWbN18xm7M/Zx1EXHA+yInKt2oJiu0pUcuczftMGh01v8aMoa
mZa6kxSYEZc1gcBku6t8hjMEaruY+ZAkaaLvz+TU8YRNxgHmDqxwu7M3GRWaYL1m
9xQGemq/I40NREzVvOB/YDnNFFUrVdrxVdLLGN35hQFgtscRqWI=
=DHs5
-----END PGP SIGNATURE-----
Hash: SHA256
Hi,
On Tue, 14 Apr 2020, Brock Palen wrote:
> I common have a case where schedule jobs get pilled on top of each other
> for a number of reasons.
>
> I cannot use Allow Duplicate Jobs = no because that cancels consolidate
> jobs for those clients.
"A duplicate job in the sense we use it here means a second or subsequent
job with the same name starts."
https://docs.bareos.org/_images/duplicate-real.svg
>
> Anyway
>
> help cancel
> Arguments:
> storage=<storage-name> |
> jobid=<jobid> |
> job=<job-name> |
> ujobid=<unique-jobid> |
> state=<job_state> |
> all yes
>
> Leads me to think I can do
>
> cancel job=<jobname>
>
> This instead prompts me like I ran cancel with with no arguments.
> Appending all actually selects all queued jobs not just jobs with that
> name.
clients, so it was not that pressing for me :-)
> You received this message because you are subscribed to the Google Groups "bareos-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bareos-users...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/bareos-users/44B9099B-0B19-4C98-9B02-CE606569F6AE%40mlds-networks.com.
>
regards,
Erich
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl6V+jAACgkQCu7JB1Xa
e1pMqg//TffFg3XYEokJ7C/vzwTv4efoUUZZx68xhTsDah/qpHTA53svd14HzTJU
60uyqeo/3Csx2CsR+qWhcNXbsBKkFK5FLIs7SWfqhAc31y5PmaOj/nOK9mkU72O0
2U/q6toxHWAMv8zROxb3bKqB+LigeNBR9uQ6KZKlwvPAvbn22ipTR1/ikkGgWP54
CDOcmHOXDGnaewwkO2OtDQThFjWq3entx5Jqfbc31MqxrkVyoZ/b+N7TjID1sxy+
KKnYenNocWJs5gszNAwzmzPQL1fmVt8IMxE7/d7o5YvRjdct9gD7JLfkqsyYLL9l
Fq+PEXE/yoY06pAxh6Ug+PJUzcZXTL+yp1ciOF1nV7ZOEWxFyY8+HSJ1j25LyYzy
HCGqELOm1bBV1fS9Zv9aJht4kXzLnkKMat8hLCRoKIp3Slyybs6/oLPi/D5VNJH3
9u8yo5mcbL4k0V3WAXC+wksXtPgWf4B94mB1hQILQ5SftRFlIrFGaCh3k5gBnLCs
sCgTV+NPyC1CnJZTWbN18xm7M/Zx1EXHA+yInKt2oJiu0pUcuczftMGh01v8aMoa
mZa6kxSYEZc1gcBku6t8hjMEaruY+ZAkaaLvz+TU8YRNxgHmDqxwu7M3GRWaYL1m
9xQGemq/I40NREzVvOB/YDnNFFUrVdrxVdLLGN35hQFgtscRqWI=
=DHs5
-----END PGP SIGNATURE-----
Brock Palen
Apr 14, 2020, 3:16:02 PM4/14/20
to Erich Eckner, bareos-users
> On Apr 14, 2020, at 2:00 PM, Erich Eckner <bar...@eckner.net> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi,
>
> On Tue, 14 Apr 2020, Brock Palen wrote:
>
>> I common have a case where schedule jobs get pilled on top of each other for a number of reasons.
>>
>> I cannot use Allow Duplicate Jobs = no because that cancels consolidate jobs for those clients.
>
> Does the consolidate job have the same name?
>
> "A duplicate job in the sense we use it here means a second or subsequent job with the same name starts."
>
> https://docs.bareos.org/_images/duplicate-real.svg
https://bugs.bareos.org/view.php?id=792
I’ll test again if it still doesn’t work I’ll update that bug, but I don’t want to get into a different issue than what brought up here, but yes if this did worked it would resolve my issue.
It would also help a lot with the new wonderful: Run On Incoming Connect Interval = 24h
I have a few clients that have multiple jobs connected to them because of size and backup times. You can get a storm or multiple jobs starting with this setting if the first job is running and the second is queued but still longer than the above interval. Doesn’t cause a lot if issues for me, I get a few extra jobs in my logs that backup nothing because it’s a duplicate of the one that ran a moment earlier.
Reply all
Reply to author
Forward
0 new messages