Basics – Jobkill goes interactive

 Basics, NetWorker  2 Responses »
Aug 152011
 

In a previous post, I described how one could use jobquery and jobkill to terminate running scheduled clones in situations where NMC doesn’t allow the clone to be stopped from within the GUI. However, jobquery isn’t necessarily the most intuitive of interfaces if you’re not using it all the time.

I was pleasantly surprised when I was preparing some documentation to note that jobkill, as of 7.6 SP2, has become interactive if there are multiple jobs running, which reduces the need to run jobquery if you’re wanting to just stop one scheduled operation.

In 7.6 SP2, if you run jobkill without any arguments, and there are jobs running, you’ll run into an interactive session such as the following.

# jobkill
                      job id: 3104018;
                        name: tara-5;
                        type: savegroup job;
                     command: ;
           NW Client name/id: ;
                  start time: 1312763880;
------------------------------------------------------
                      job id: 3104025;
                        name: /d/01;
                        type: save job;tara.pmdg.lab
                     command: \
save -s tara.pmdg.lab -g nox-5 -LL -f - -m tara.pmdg.lab -t 1312026303 \
-l 5 -q -W 78 -N /d/01 /d/01;
           NW Client name/id: tara.pmdg.lab;
                  start time: 1312763880;
------------------------------------------------------
                      job id: 3104026;
                        name: /;
                        type: save job;
                     command: \
save -s tara.pmdg.lab -g nox-5 -LL -f - -m tara.pmdg.lab -t 1312026306 \
-l 5 -q -W 78 -N / /;
           NW Client name/id: tara.pmdg.lab;
                  start time: 1312763880;
------------------------------------------------------
Specify jobid to kill ('q' to quit, 'r' to refresh): 3104018
Terminating job 3104018
Specify jobid to kill ('q' to quit, 'r' to refresh): q

So there you go – jobkill is interactive, helpful and now saves the hassle of running jobquery first.

 Posted by at 07:13  Tagged with: , , ,

Killing scheduled cloning operations

 Basics, NetWorker  6 Responses »
Mar 172011
 

In a previous blog post, I discussed how much I liked the scheduled cloning operations introduced in NetWorker 7.6 SP1. Since then, I’ve had several people comment on it saying that while they’re able to manually start scheduled cloning operations, they’re not able to stop scheduled cloning operations in NMC – regardless of whether they were manually or automatically started.

Now I thought I’d been able to manually stop a scheduled cloning operation via NMC during beta testing, but I may have confused myself with something else, and when I noticed the same issue, it led me to think – can I stop this some other way, maybe from the command line? (For what it’s worth, the inability to stop a scheduled clone from NMC is a known issue, and there’s an EMC request running for it.)

It turns out without NMC, the command line is how you stop a scheduled cloning operation. It actually turned out to be fairly simple in the end. To do so, you use jobquery and jobkill.

First, use jobquery to identify the scheduled clone job you want:

# jobquery
jobquery> show name:; job id:; job state:
jobquery> print type: clone job; job state: SESSION ACTIVE:
                      job id: 64002;
                   job state: SESSION ACTIVE;
                        name: clone.linux clones;

Once you’ve got that job ID, all you have to do is quit jobquery, and run:

# jobkill -j jobID

In this case – it would be:

# jobkill -j 64002
Terminating job 64002

That’s it – that’s how you stop a scheduled clone job.

 Posted by at 06:25  Tagged with: , , , ,

Jobquery finally gets the duct tape removed

 Architecture, Databases, NetWorker, Scripting  No Responses »
Jan 082010
 

Some time ago, I posted that EMC had added a jobquery utility to allow probing of the NetWorker jobs database (the one created/maintained by nsrjobd). Unfortunately, at the time, jobquery had been somewhat muzzled – you could give it commands, and it would spit output back to you, but it would never give you any indication that it was waiting for you. No prompting, no nothing. It made working with jobquery somewhat of a hassle.

Thankfully though, as of NetWorker 7.6, the duct tape has been fully removed and jobquery will happily give you that meta-information:

[root@nox ~]# jobquery


NetWorker jobs query utility.


Use the "help" command for help.


jobquery> help


Legal commands are:


          print [query] (set current query)


           show [attrlist]


          types


            all


           quit


           help [command]


              . [query]


              ? [command]


Where:


        query ::= attrlist


        attrlist ::= attribute [; attribute]*


        attribute ::= name [: [value [, value]* ]


jobquery> types


     Known types: job indication, save job, probe job,


                  savegroup job, session info, index save job,


                  savefs job, bootstrap save job, utility job,


                  active job db;

Now sure, in previous versions you could type commands in and get output, but not having the prompt to tell you when jobquery was waiting, or when it was working, or when (as I originally thought) it was hanging on startup, is a fairly critical part in having a useful user interface.

Having a responsive user interface makes jobquery a little nicer to work with. For instance, let’s look at the “save job” type and run a backup. There’s a lot of fields in the “save job” resource type, so I’m going to limit it as follows:

jobquery> show command:; group name:; host:; job state:; level:
jobquery> print type: save job
                     command: \
"save -s nox.anywebdb.com -g \"Staging Servers\" -LL -f - -m nox\
 -t 1262601936 -l incr -q -W 78 -N /d/nsr/01 /d/nsr/01";
                  group name: Staging Servers;
                        host: nox;
                   job state: COMPLETED;
                       level: incr;
…

Then, once the backup starts, if I run (and abbreviate the output, remembering it shows all jobs in the database!), I can see:

                     command: \
savepnpc -s nox.anywebdb.com -g archon -LL -f - -m archon -t 1262818820 -l in\
cr -q -W 78 -N / /;
                  group name: archon;
                        host: archon;
                   job state: ACTIVE;
                       level: incr;

However, the “ACTIVE” state simply means that the job is actively queued, not that it’s actually sending data. If you want to only see jobs that are actively backing up rather than just simply active, you’d look for a job state of “SESSION ACTIVE”:

jobquery> print type: save job; job state: SESSION ACTIVE
                     command: \
savepnpc -s nox.anywebdb.com -g archon -LL -f - -m archon -t 1262818820 -l in\
cr -q -W 78 -N / /;
                  group name: archon;
                        host: archon;
                   job state: SESSION ACTIVE;
                       level: incr;

                     command: \
savepnpc -s nox.anywebdb.com -g archon -LL -f - -m archon -t 1262818814 -l in\
cr -q -W 78 -N /Volumes/Yu /Volumes/Yu;
                  group name: archon;
                        host: archon;
                   job state: SESSION ACTIVE;
                       level: incr;
What does this mean? For a start, it provides a way of checking (outside of NMC) which jobs are currently queued to run, and which jobs are actually running. As is always the case, the better you can monitor regardless of circumstance, the more likely you are to be able to understand your server state. Now that jobquery however at least tells us when it’s waiting for input, I’m looking forward to properly exploring what it can do. I previously said that I anticipated it being a useful tool. Now I know it’s going to be a useful tool, and will do some further digging/testing and do a future posting on using it further to track activities.
 Posted by at 14:25  Tagged with:

Getting jobquery to talk to you

 NetWorker  1 Response »
Feb 192009
 

I’ve been using nsradmin for the last 12 years. So when I read about a new utility, ‘jobquery’ in NetWorker 7.5, that’s designed to work in a similar way to nsradmin but query the jobs database instead of the media database, I was looking forward to giving it a go. (This was in no small part to lingering disappointment over how nsrjobsd has been practically a black box since it was introduced.)

So I was rather … disappointed when I ran jobquery for the first time and it appeared to hang.

Running, say:

# jobquery

Appeared to hang.

Running, say:

# jobquery -s server

Also appeared to hang.

Running, say:

# jobquery -s server print

Didn’t return a thing.

So I thought maybe this is a tool that was let out of the barn a little too soon, and even went to the point of logging a question case with EMC about it. After all, it appeared to not really work at all.

It turns out I’d not anticipated that there might have been a simpler problem with jobquery, that being … less than desirable interface design. Let’s be blunt: if you write an interactive “shell” style query interface, it should tell the user when it’s waiting for input.

The problem with the initial invocation attempts was a simple one – it wasn’t hanging, but instead, it was waiting for input without telling me it was waiting for input. Consequently, I’m currently asking EMC to file a bug about this. I know the difference between RFEs and bugs – an RFE is a request for enhancement, or to change something that’s there by design, but a bug is a problem with the actual implementation. Now, someone might argue that maybe this should be filed as an RFE if it was originally designed to not show any prompt, but my take on it is that any interface that doesn’t differentiate between “waiting for input” and “processing/stuck” is, in actuality, a buggy design.

Oh, and jobquery just doesn’t like being told what to do in relation to queries on the command line, even though the man page says it will accept it.

If you’ve been trying to use jobquery and not getting much satisfaction, try it again without waiting for a prompt. Once I got past the lack of prompt, I was quite excited by the promise of jobquery – in fact, I’m hoping that a future release will actually implement the ability to even stop jobs – e.g., kill off a single saveset, or even say, pause a clone/stage operation.

No doubt jobquery needs some improvements, but it wasn’t quite the aborted attempt I’d been initially worried about, and you should give it a go – you’ll be pleasantly surprised.

 Posted by at 19:25  Tagged with: ,
© 2012 The NetWorker Blog Suffusion theme by Sayontan Sinha