« October 2009 »
SunMonTueWedThuFriSat
    
1
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
24
25
26
27
28
29
30
31
       
Today
XML

Neat blogs

Navigation

Editing

Powered by Roller Weblogger.

statcounter.com

clustrmaps.com

Locations of visitors to this page

technorati.com

20091023 Friday October 23, 2009
Using the 7000 BUI to document script generation

I'm old skool enough that I prefer a CLI versus a GUI for administration tasks. I've got that disclaimer there because I happen to like web browsers, GIMP, and even WireShark at times.

Given a choice between being able to ssh (or even telnet) in to a box versus going to a web based interface, I'll almost always chose the ASCII interface. The exceptions would be when I don't have a manual and need to do something fast. If I'm not in a hurry, I'm willing to learn by trial and error.

I've been running some tests on a 7410 and I need to be able to restart NFS. I've been using the BUI because I really find it intuitive. For example, I needed to bring up another interface on a backend network and it was very simple to go to Configuration -> Network and just click my way through it. I also liked that my routing tables were set up correctly. I had just fought that in a similar situation on a v20z running Fedora 11.

I like being able to click on the Device and getting the relevant datalinks and interfaces. I like the apply changes implementation. I like it checks for uncommited transactions if I try to leave the current entry.

But what I really like is a very understated correlation between the BUI and CLI - the BUI documents scripting actions you can do in the CLI. Likewise, if you understand the CLI commands, you can quickly navigate to a BUI counterpart.

So my goal was to be able to restart NFS from the CLI. Rather than picking up a manual, I looked at where I was at in the BUI, which was Configuration -> Services. And to restart it, I selected the circular arrows to the left of the NFS Data Service.

This was 99% of the equivalent command:

washdc:> configuration services nfs 
abort    commit   done     get      script   show     
assert   disable  enable   help     set      

I was looking for a "restart" option and I realized that the button must be a combination of "disable" and "enable". Sure enough, this:

washdc:> configuration services nfs disable
washdc:> configuration services nfs enable

was functionally equivalent.

I find that every time I interact with either the BUI or CLI, I find something else to remind me of the tight integration and also to appreciate them both being designed at the same time.


Originally posted on Kool Aid Served Daily
Copyright (C) 2009, Kool Aid Served Daily

20091002 Friday October 02, 2009
args[ ] may not be referenced because probe description matches an unstable set of probes

I need to be able to see if a mount request generated an error in the mountd daemon. I have a custom kernel that has changed the mount() function call to return the error code. So, now I'm using a very simple DTrace script to catch the error codes:

#!/usr/sbin/dtrace -s

pid$1::mount:return
{
        printf("rc = %d", args[1]);
}

pid$1::audit_mountd_mount:return
{
        printf("rc = %d", args[1]);
}

The issue is what happens when I try to run it:

[root@pnfs-4-11 ~]> ./mountd_res.d `pgrep -x mountd`
dtrace: failed to compile script ./mountd_res.d: line 18: args[ ] may not be referenced because probe description pid100824::mount:return matches an unstable set of probes

What I think this means is that I've got multiple declarations of mount() and they all do not return something. Okay, I can narrow down the probe to just the one I want:

[root@pnfs-4-11 ~]> dtrace -l -f mount
   ID   PROVIDER            MODULE                          FUNCTION NAME
 2378 lx-syscall                                               mount entry
 2379 lx-syscall                                               mount return
13708        fbt           genunix                             mount entry
13709        fbt           genunix                             mount return
31190    syscall                                               mount entry
31191    syscall                                               mount return
65944  pid100824            mountd                             mount entry
65945  pid100824         libc.so.1                             mount entry
65946  pid100824            mountd                             mount return
65947  pid100824         libc.so.1                             mount return

And if I adjust my script:

pid$1:mountd:mount:return
{
        printf("rc = %d", args[1]);
}

We see I've fixed this issue!

[root@pnfs-4-11 ~]> ./mountd_res.d `pgrep -x mountd`
dtrace: failed to compile script ./mountd_res.d: line 18: index 1 is out of range for pid100824:mountd:mount:return args[ ]

Okay, I got my syntax wrong for the return code:

pid$1:mountd:mount:return
{
        printf("rc = %d", arg1);
}

And now I see the correct output:

[root@pnfs-4-11 ~]> ./mountd_res.d `pgrep -x mountd`
dtrace: script './mountd_res.d' matched 2 probes
CPU     ID                    FUNCTION:NAME
  0  65946                     mount:return rc = 0
  0  65240        audit_mountd_mount:return rc = 1
  0  65946                     mount:return rc = 0
  0  65240        audit_mountd_mount:return rc = 1


Originally posted on Kool Aid Served Daily
Copyright (C) 2009, Kool Aid Served Daily