# tshark -T fields -e nfs.fsid4.major -e nfs.fsid4.minor port 2049

Errors and omissions excepted. All mistakes my own. If you don’t know what I’m talking about or why this would be useful to know then this post will not be very interesting.

knfsd

With UUID fsid

You have an export like this:

    /export -rw,fsid=01234567-89ab-cdef-dead-beefcafebabe 192.168.0.0/24

The fsid is found by considering the UUID as two unsigned 64-bit hexadecimal integers. In the example above they would be 0x123456789abcdef and 0xdeadbeefcafebabe. The major number is therefore 81985529216486895 and the minor number is 16045690984503098046.

With numeric fsid

You have an export like this:

    /export -rw,fsid=1234 192.168.0.0/24

The fsid is found by setting the major number to the number specified and zeroing the minor number. In the example above the major number is 1234 and the minor number is 0.

The rule holds for the pseudo-root filesystem with fsid=0 – alternatively specified as fsid=root.

With no explicit fsid

If your export doesn’t specify fsid the kernel will look for the exported filesystem UUID and apply the same logic above.

For example on my test machine I exported the root filesystem.

    # xfs_admin -l /dev/dm-0
    UUID = e2f1c059-e6c2-403d-9c80-ab7a9f86b91f

So the major number is 16353063214315094077 and the minor number is 11277202010086488351.

Ganesha

With Filesystem_Id

No prizes for guessing what the Filesystem_Id parameter does.

    EXPORT {
      Filesystem_Id = 1234.5678;
      ...
    }

In the example above the major number is 1234 and the minor number is 5678.

Yes, you can make the fsid for an export the same as given by knfsd.

      Filesystem_Id = 81985529216486895.16045690984503098046;

With no explicit Filesystem_Id

The documentation states that the fsid defaults to 666.666 if Filesystem_Id is not explicitly configured. In my testing that statement didn’t appear to hold true. Since my goal was to figure out how to set the fsid to be consistent – so I could fail over the IP providing NFS service – I didn’t delve too deeply into this case.

Surely getting an application to redirect its output would be easy. In fact I discovered:

• You have to explicitly pass the filehandles to CreateProcess().

• You have to explicitly tell CreateProcess() that the filehandles are inheritable when launching a child process.

• You have to explicitly tell CreateFile() that the filehandles are inheritable when opening them in the first place.

• Opening a file with FILE_APPEND_DATA semantics is not sufficient to append to a file. You have to explicitly seek to the end of the file.

• You can’t open two filehandles to the same path or there will be a race and one of them will lose data. You need to call DuplicateHandle() if both targets are the same. Determining that the user asked for both targets to be the same is an exercise for the reader. Vista offers GetFinalPathNameByHandle() but I couldn’t use that in NSSM because NSSM needs to work on older Windows versions.

• Trying to open a file with FILE_APPEND_DATA | FILE_WRITE_DATA and OPEN_ALWAYS will not result in opening a file for appending if it already exists or creating a new file if it didn’t. You have to try to open it for append and, if that fails with ERROR_FILE_NOT_FOUND, try again as a new file. Otherwise the file will be truncated.

On the plus side, the use of CreateFile() behind the scenes makes it entirely possible that you will be able to do clever stuff like open named pipes and connect IPC for different services together, or take input from a serial port.

Although reading to and writing from plain files is working and, as mentioned above, other I/O should in theory work just as well, the release won’t be coming just yet. I will also be including some rudimentary CPU affinity handling based on a contribution from Robert Middleton. I may even make good on my longstanding threat to remove the readable standard C stuff like declaring variables as unsigned long and replace them with ugly Win32-isms such as DWORD. I hate to do it but like it or not NSSM is a Windows application and probably should follow Windows coding conventions.

But not, under any circumstances, Hungarian notation.

Explaining the difference between what I was doing and what I’m now doing would probably take almost as long as describing everything from scratch and would certainly be confusing let’s go back to the very beginning.

The situation was that my ISP imposed a strict download quota between the hours of 0900 and 1800 on weekdays. I wanted to make sure that I didn’t inadvertently eat into that quota by configuring traffic management policies on the router.

Since the peak period is based on time of day I first configured the local timezone correctly.

    clock timezone GMT 0
    clock summer-time BST recurring last Sun Mar 1:00 last sun Oct 2:00

Then I created a time range to represent peak time.

    time-range peak
     periodic weekdays 9:00 to 17:59

The time range is used inside IP and IPv6 access lists which would match any connection at peak time.

    ip access-list extended peak
     permit ip any any time-range peak

    ipv6 access-list peak6
     permit ipv6 any any time-range peak

We next need a class-map which will categorise any traffic which matches the peak or peak6 access lists. Thus it must be a match-any class-map.

    class-map match-any peak
     match access-group name peak
     match access-group name peak6

Rather than just apply a blanket restriction I wanted to allow different types of traffic to have different speeds. For example I decided that HTTP traffic should be allowed to attain 1Mbps in peak time. Outside peak time I wasn’t applying any throttling at all.

Now we need a class-map to recognise HTTP. That’s achieved with a combination of the router’s own protocol recognition and some custom access lists which match non-standard but commonly-used ports.

    ip access-list extended http-alt
     permit tcp any eq 8080 any
     permit tcp any eq 8443 any

    ipv6 access-list http-alt6
     permit tcp any eq 8080 any
     permit tcp any eq 8443 any

    class-map match-any http
     match protocol http
     match protocol secure-http
     match access-group name http-alt
     match access-group name http-alt6

In order to apply the 1Mbps restriction we need a policy-map. The peak class-map is used to limit the effects of the policy to traffic in peak time.

    policy-map 1Mbps
     class peak
        police rate 1024000
          conform-action transmit
          exceed-action drop
          violate-action drop

The penultimate step is to create a policy, to be applied on the dialer interface, which will match traffic using the class-maps defined earlier and apply the appropriate restriction policies. Any traffic not categorised by a class-map is handled by the class-default rule.

    policy-map from_internet
     class http
      service-policy 1Mbps
     class class-default
      service-policy 512kbps

Finally the from_internet policy is applied to the dialer interface so as to take effect.

    interface Dialer 0
     service-policy input from_internet

By configuring policing this way I am able to see stats for all the traffic classes I define without needing to set up a separate Netflow server.

    # show policy-map interface Dialer 0 input class http
     Dialer0

      Service-policy input: from_internet

        Class-map: http (match-any)
          7880183 packets, 9841690612 bytes
          5 minute offered rate 7000 bps

To keep this post simple I only described one speed for one traffic class. In reality I created several more time-ranges and policy-maps, and nested service policies to allow variable restrictions at different times of day. When my ISP tightened the download quota for evenings and weekends I was able to apply a tiered strategy whereby peak time traffic was severely restricted, nighttime traffic was unrestricted and remaining times were mildly restricted. Then after a month I switched to an uncapped ISP but that's another story.

    time-range off-peak
     periodic daily 2:00 to 5:59

    ip access-list extended off-peak
     permit ip any any time-range off-peak

    ipv6 access-list off-peak6
     permit ipv6 any any time-range off-peak

    class-map match-any off-peak
     match access-group name off-peak
     match access-group name off-peak6

    policy-map 256kbps
     class class-default
        police rate 256000
          conform-action transmit
          exceed-action drop
          violate-action drop

    policy-map unlimited
     class class-default

    policy-map low
     class peak
      service-policy 256kbps
     class off-peak
      service-policy unlimited
     class class-default
      service-policy 512kbps

    policy-map from_internet
     class p2p
      service-policy low
     class http
      service-policy medium

The first step is to configure libvirtd to accept connections secured with GSSAPI. That means it needs to listen on a TCP port, which it won’t do by default. On my Fedora system that was rectified by editing /etc/sysconfig/libvirtd and uncommenting the line:

    LIBVIRTD_ARGS="--listen"

This ensures the –listen flag is passed to libvirtd, enabling TCP connections. That in itself, however, is not enough. For security the default configuration disables unencrypted connections and enables only TLS-encrypted access. Since we’ll be using Kerberos we don’t need TLS. You can leave it on if you have a certificate set up but since I didn’t I turned it off; with no certificate and TLS configured the service won’t start. The file to edit is /etc/libvirt/libvirtd.conf:

    listen_tls = 0
    listen_tcp = 1

libvirtd uses SASL for GSSAPI so we need the appropriate libraries; on Fedora that means the cyrus-sasl-gssapi RPM. Still in libvirtd.conf we need to configure SASL for unencrypted connections:

    auth_tcp = "sasl"

Then we need to set up a whitelist of users who are allowed to connect. Wildcards are allowed so you could just use ["*"] if you wanted anyone with valid Kerberos credentials to get access to the hypervisor. That probably isn’t a good idea.

Note that the comments in libvirtd.conf suggest that you need to use full user principal names in the list. That’s only true for users who are not in the default realm configured in /etc/krb5.conf. Indeed a UPN containing the default realm name will not work.

    sasl_allowed_username_list = ["admin", "trusted@ANOTHER.REALM"]

The example above allows admin from the default realm and trusted from the ANOTHER.REALM realm. No one else can connect.

Next we need to tell libvirtd that GSSAPI is a valid security mechanism by editing /etc/sasl2/libvirt.conf. The default configuration allows DIGEST-MD5 so we need to comment out lines referencing that and uncomment the right one:

    mech_list: gssapi

Finally – for libvirtd itself – we need to create a keytab for libvirt/<fqdn>@<REALM> and install it as /etc/libvirt/krb5.tab. It need only be accessible to root.

With all that done – and libvirtd restarted – a user with Kerberos credentials matching one of the users allowed above should be able to connect to the hypervisor.

    virsh -c qemu+tcp://hostname/system

You can also connect using virt-manager by adding a new connection.

• Connect to remote host
• Method: TCP
• Username: blank
• Hostname: as appropriate

At which point you will find that we’re only half done. VNC needs to be Kerberized separately.

The process is similar. First we need to enable SASL and make sure we are listening, since by default VNC only listens on the loopback interface. This is done in /etc/libvirt/qemu.conf:

    vnc_listen = "[::]"
    vnc_sasl = 1

Since this post was originally made, newer versions of libvirtd changed the syntax of the listen address to :: (no square brackets). If you only need IPv4 networking you can use 0.0.0.0 and of course you can specify a particular address if you prefer.

As with libvirtd, we don’t need TLS with Kerberos.

    vnc_tls = 0

We also need to configure /etc/sasl2/qemu.conf in the same way as libvirt.conf:

    mech_list: gssapi

And finally we need a keytab installed as /etc/qemu/krb5.tab and readable by the qemu user. Despite conflicting reports in the documentation I found, the service principal name needs to be vnc/<fqdn>@<REALM>.

Newly-started guests will now have their consoles accessible from the Kerberized virt-manager connection.

Note that qemu supports ACLs restricting access to named users but at time of writing libvirt doesn’t know how to configure them. If security is a concern you may prefer to use SSH tunnelling instead. You can use Kerberos and not need to type a password…

The error message displayed to the user: Status call to SDU daemon failed

The error hidden in the Snapdrive trace log: Fatal error: Assertion detected in production code: ../sbl/StorageOperation.cpp:182: Test ‘osAssistants.size() == 1′ failed

The actual problem: /etc/redhat-release contains the string CentOS not Red Hat.

As an example I was downloading a file via HTTP during peak time yesterday. The transfer was proceeding at 32kBps or so which is to be expected. Then all of a sudden it dropped out. From time to time I had been seeing similar things. When Steam decides to download patches for games it will report wildly fluctuating download rates. This is to be expected if your traffic management consists of dropping inbound packets but if anything can make things more civilised then I’m happy to hear about it.

I removed my rate-limiting options from the Dialer0 interface and instead added police rules (with the exact same bandwidth specifications) to my peak service policy, which now looks like this:

    policy-map peak
      description Set bandwidth at peak time.
     class peak-default
        police 64000 12000 24000 conform-action transmit  exceed-action drop  violate-action drop
     class peak-lowest
        police 32000 6000 12000 conform-action transmit  exceed-action drop  violate-action drop
     class peak-low
        police 128000 24000 48000 conform-action transmit  exceed-action drop  violate-action drop
     class peak-medium
        police 512000 96000 192000 conform-action transmit  exceed-action drop  violate-action drop
     class peak-high
        police 1024000 192000 384000 conform-action transmit  exceed-action drop  violate-action drop

It seemed to work. Traffic was still limited to the desired bandwidth but the file which I consistently failed to download properly was successfully retrieved

I can see some statistics on the rate limiting.

    # sh int d0 rate-limit
     Dialer0 
      Input
        matches: dscp 1
          params:  64000 bps, 12000 limit, 24000 extended limit
          conformed 58600 packets, 4220034 bytes; action: transmit
          exceeded 0 packets, 0 bytes; action: drop
          last packet: 64ms ago, current burst: 0 bytes
          last cleared 02:04:55 ago, conformed 4000 bps, exceeded 0 bps
        matches: dscp 2
          params:  32000 bps, 6000 limit, 12000 extended limit
          conformed 10541 packets, 12268452 bytes; action: transmit
          exceeded 12986 packets, 18191623 bytes; action: drop
          last packet: 36ms ago, current burst: 10018 bytes
          last cleared 1d22h ago, conformed 0 bps, exceeded 0 bps
        matches: dscp 3
          params:  128000 bps, 24000 limit, 48000 extended limit
          conformed 71436 packets, 7030498 bytes; action: transmit
          exceeded 81 packets, 77046 bytes; action: drop
          last packet: 24ms ago, current burst: 0 bytes
          last cleared 1d22h ago, conformed 0 bps, exceeded 0 bps
        matches: dscp 4
          params:  256000 bps, 48000 limit, 96000 extended limit
          conformed 1021747 packets, 109363738 bytes; action: transmit
          exceeded 4012 packets, 3572353 bytes; action: drop
          last packet: 20ms ago, current burst: 0 bytes
          last cleared 1d22h ago, conformed 5000 bps, exceeded 0 bps
        matches: dscp 5
          params:  1024000 bps, 192000 limit, 384000 extended limit
          conformed 407623 packets, 249878838 bytes; action: transmit
          exceeded 13419 packets, 13016776 bytes; action: drop
          last packet: 4789ms ago, current burst: 0 bytes
          last cleared 1d22h ago, conformed 11000 bps, exceeded 0 bps

Unfortunately it isn’t apparent which types of traffic are ending up with each classification.

    # sh policy-map int d0
     Dialer0 
    
      Service-policy input: peak
    
        Class-map: peak-lowest (match-all)
          24951 packets, 32543191 bytes
          5 minute offered rate 86000 bps, drop rate 0 bps
          Match: access-group name peak
          Match: class-map match-any lowest
            Match: class-map match-any p2p
              0 packets, 0 bytes
              5 minute rate 0 bps
              Match: protocol bittorrent
                0 packets, 0 bytes
                5 minute rate 0 bps
              Match: protocol edonkey
                0 packets, 0 bytes
                5 minute rate 0 bps
              Match: protocol gnutella
                0 packets, 0 bytes
                5 minute rate 0 bps
              Match: protocol kazaa2
                0 packets, 0 bytes
                5 minute rate 0 bps
              Match: protocol winmx
                0 packets, 0 bytes
                5 minute rate 0 bps
            Match: class-map match-any rsync
              0 packets, 0 bytes
              5 minute rate 0 bps
              Match: access-group name rsync
                0 packets, 0 bytes
                5 minute rate 0 bps
          QoS Set
            dscp 2
              Packets marked 24948
        ...

So traffic is being marked as lowest priority but I can’t see whether it’s peer-to-peer or rsync.

This is because the class contains subclasses. The solution is to set up a separate policy map on the LAN interface to classify traffic sent out of the router to the internal network. So let’s set up a policy map with the individual classes I’m interested in.

    policy-map classify
     class p2p
     class rsync

My LAN interface happens to be Vlan1 so the policy should be applied on that interface’s output, going to clients. There’s no rate limiting on the interface so all we’re doing is gathering statistics.

    interface Vlan1
     service-policy output classify

Now we can see that it’s rsync which is currently active.

    # sh policy-map int vlan1
     Vlan1 
    
      Service-policy output: classify
    
        Class-map: p2p (match-any)
          56 packets, 5525 bytes
          5 minute offered rate 0 bps
          Match: protocol bittorrent
            0 packets, 0 bytes
            5 minute rate 0 bps
          Match: protocol edonkey
            0 packets, 0 bytes
            5 minute rate 0 bps
          Match: protocol gnutella
            0 packets, 0 bytes
            5 minute rate 0 bps
          Match: protocol kazaa2
            0 packets, 0 bytes
            5 minute rate 0 bps
          Match: protocol winmx
            0 packets, 0 bytes
            5 minute rate 0 bps
    
        Class-map: rsync (match-any)
          181 packets, 274034 bytes
          5 minute offered rate 12000 bps
          Match: access-group name rsync
            0 packets, 0 bytes
            5 minute rate 0 bps

Afterwards the temporary policy map can be removed.

    no policy-map classify

Or it could be kept around for further analysis, adding and removing classes as appropriate.

As I have a Cisco 877 router I should be able to throttle downloads during peak times and save myself money compared to the plan I’ve been using.

Note that the ISP doesn’t charge for excessive upload so my work was focussed 100% on download throttling.

The first thing to do was set up a time-range so the router knows what peak time is. Well actually the zeroth thing to do was configure my timezone correctly.

    clock timezone GMT 0
    clock summer-time BST recurring last Sun Mar 1:00 last sun Oct 2:00

Now I could define the time range.

    time-range peak
     periodic weekdays 9:00 to 17:59

Just for fun I set up an off-peak time range.

    time-range off-peak
     periodic weekdays 0:00 to 8:59
     periodic weekdays 18:00 to 23:59
     periodic weekend 0:00 to 23:59

The sh time-range command verifies that these are set up.

    # sh time-range
    time-range entry: off-peak (active)
       periodic weekdays 0:00 to 8:59
       periodic weekdays 18:00 to 23:59
       periodic weekend 0:00 to 23:59
    time-range entry: peak (inactive)
       periodic weekdays 9:00 to 17:59

The off-peak range shows as active which is correct because it’s Sunday at time of writing.

Next I created an access list which would match any connection at peak time.

    ip access-list extended peak
     permit ip any any time-range peak

At this point I could have just set things up so downloads were throttled at peak times but that would have been inelegant and I wanted more control. For instance Rebecca will be at home working during the day and she wants to be able to download her mail and make calls to China with Skype. So for want of a better idea I decided to set up five usage categories:

1. Default Anything I forget about and don’t fit into one of the subsequent categories. Limited to 64kbps.

2. Lowest: Stuff that has no business running during the day, like Bittorrent. Limited to 32kbps.

3. Low: Stuff like Steam automatic downloads and SSH. Limited to 128kbps.

4. Medium: Stuff which could well run during the day and which shouldn’t be horrendously slow but which I don’t want spiralling out of control. Skype and HTTP for example. Limited to 256kbps.

5. High: For things that gotta do what they gotta do. Mail, DNS etc. Limited to 1Mbps.

Now I set up a class-map for each protocol I was interested in. The Cisco 877 has some protocol information builtin such as for Skype:

    class-map match-any skype
     match protocol skype

Others can be defined manually with access lists.

    ip access-list extended steam
     permit tcp any range 27014 27050 any

    class-map match-any steam
     match access-group name steam

Further class maps allow grouping of protocols according to the classification defined earlier. Here’s medium. lowest, low and high are similar. These are match-any classes which match any of the listed protocols.

    class-map match-any medium
     match class-map http
     match class-map skype

A final set of class maps match only at peak time. These are match-all classes so both criteria – it’s peak time and it’s a particular protocol class – must match. Here’s peak-medium.

    class-map match-all peak-medium
     match access-group name peak
     match class-map medium

One more class, peak-default acts as the catchall.

    class-map match-all peak-default
     match access-group name peak
     match not class-map lowest
     match not class-map low
     match not class-map medium
     match not class-map high

With those classes defined we can now set up a policy-map which assigns a DSCP tag to traffic matching particular classes.

    policy-map peak
     class peak-default
      set dscp 1
     class peak-lowest
      set dscp 2
     class peak-low
      set dscp 3
     class peak-medium
      set dscp 4
     class peak-high
      set dscp 5

To convert these policies into actual rate limiting we set rate-limit rules matching the defined DSCP values on the ADSL interface, which for me is Dialer0.

rate-limit expects three numbers: a target bitrate, a normal burst rate and a maximum burst rate. Cisco recommend setting the normal parameter as 1.5/8 x the target and the maximum as twice the normal. So for the 128kbps profile (DSCP 3) the numbers are 128000 24000 48000. If in doubt just multiply the target rate by 0.1875 for the second number and then double it…

    interface Dialer0
     rate-limit input dscp 1 64000 12000 24000 conform-action transmit exceed-action drop
     rate-limit input dscp 2 32000 6000 12000 conform-action transmit exceed-action drop
     rate-limit input dscp 3 128000 24000 48000 conform-action transmit exceed-action drop
     rate-limit input dscp 4 256000 48000 96000 conform-action transmit exceed-action drop
     rate-limit input dscp 5 1024000 192000 384000 conform-action transmit exceed-action drop

Actually there is one more thing. As it stands the configuration won’t have any effect. We have to apply the service policy to the interface for the magic to happen.

    interface Dialer0
     service-policy input peak

Initial testing suggests that this works. A Steam download at peak time claims to run at 7kBps and at 800kBps at off-peak. Temporarily adding a line to the peak time range allows easy testing when the actual time is off-peak.

I’m sure I’ll need to tweak the download rates and/or move protocol definitions around as real life usage patterns become apparent but the underlying concepts work well enough.

In fact my home directory is only as small as it is because I moved a wodge of files to a separate storage area. The Documents directory, in which my Mac wants to save … pretty much anything … is actually a symlink to /files/iain/Documents which is automounted from somewhere else. And since my documents are the kind of things which I like to have available all over the place, that same directory is also shared by Samba and my Windows roaming profile knows to go there when I try to open (My) Documents. Some other directories are similarly shared across operating systems, including Desktop, Pictures and Movies.

I’d been thinking for a while that it might be better to move these well-known file stores into their own separate ZFS filesystems on my fileserver. Things came to a head this very evening when I downloaded Steam for Mac only to have it refuse to install because Library/Application Support/Steam wasn’t on a case-insensitive filesystem. It occurred to me that if Library were its own filesystem as I’d been considering, I could make it case-insensitive and trim the size of my home directory by a considerable margin. Although I wouldn’t advocate actually doing it in so crude a way, I believe that a home directory should be small enough that if you were given a UNIX account on a new system you should be able to get yourself up to speed by quickly transferring your entire home area from another environment. A home directory should be for dotfiles, SSH keys and the like. Everything else (real documents) should go Somewhere Else.

Since I use the automounter for everything I figured this would be pretty simple. As it turns out it actually is. The syntax works with Mac, Solaris and Linux as is documented to a greater or lesser extent in each system’s AutoFS manpages. The only potential stumbling block was getting it to work with LDAP but ended up being just as simple as you might hope.

The syntax to have the automounter mount a subdirectory of a configured mount is as follows, in auto.home for instance:

    * / files:/export/home/& /Library files:/export/library/&

So for all x /home/x will be mounted from fileserver:/export/home/x and /home/x/Library will be mounted from fileserver:/export/library/x.

On Linux I found I didn’t need the initial / by itself but both Mac and Solaris didn’t work without it. Another gotcha was that the Library directory had to actually exist in the original directory for it to be mounted from the specified location. In other words it wasn’t sufficient to export /export/home/iain and /export/library/iain from my file server. I also needed to create /export/home/iain/Library for it to be mounted.

In LDAP speak my auto.home became:

    dn: cn=/,ou=auto.home,ou=mounts,dc=iain,dc=cx
    objectClass: automount
    cn: /
    automountInformation: -fstype=nfs,tcp,rw,intr / files:/export/home/&
     /Library files:/export/library/&

To automount more subdirectories it suffices to add more bits to the automount entry.

    dn: cn=/,ou=auto.home,ou=mounts,dc=iain,dc=cx
    objectClass: automount
    cn: /
    automountInformation: -fstype=nfs,tcp,rw,intr / files:/export/home/&
     /Library files:/export/library/& /Documents files:/export/documents/&

And by redirecting my Windows shell folders to point to these filesystems in their CIFS form I can share them between operating systems.

The new release will fix some bugs and add a new feature which may be of benefit to some users who were trying to use NSSM in a way contrary to its original design. I’m posting here to respond to some criticism of NSSM I’ve read on the internet and to talk a bit about how it’s evolved. A more objective discussion about how the tool works is more appropriate for its homepage, hence my choice of a blog post for this theme.

It’s been a source of pride to me that NSSM has carried on trucking for several years now without any updates. When you see a project which hasn’t had a release in years and years you can either look at it as an abandoned project or a stable one. It’s nice to know that people are still downloading it and finding it useful so long after it was originally written.

This brings me to the criticism I mentioned. I read a piece whose author described what he saw as a "disadvantage" of NSSM, namely its behaviour when the monitored application exits. The author thought that it was a waste of time and symptomatic of a Not-Invented-Here attitude to detect application failure and restart it. He argued that the existing ability of Windows to take service recovery action should be used instead.

This got me thinking. I’m not averse to criticism and I do try not to reinvent wheels so I considered the point carefully. The conclusion I drew was that it’s been so long since NSSM was originally written that people may have forgotten the problem it was designed to solve. That’s not necessarily a bad thing, as it implies that the problem may have gone away. Join me, then, as we walk down memory lane and meet srvany…

Freelancer and srvany

Back in 2003 I was playing Freelancer, an enjoyable space trading/combat game where you flew around fighting off pirates, running trade routes through the galaxy, making money and upgrading your ship. You could play multiplayer over the internet and there was a dedicated server which enabled you to disconnect and reconnect to find your character and ship intact. It only lacked a truly persistent world with thousands of players, rather than five or six to be an awesome MMO. Indeed even now when any space MMO is released nowadays I find myself lamenting how much cooler it would be if the developers had just taken Freelancer and made it bigger instead of building their own game from scratch.

But I digress.

Freelancer was a lot of fun and had a lot going for it. What it didn’t have going for it was its dedicated server stability. That thing would crash and burn and it wasn’t pretty. People wanted to run it as an NT service so their friends could connect to the game without someone having to connect to the server machine and start it up. In those days if you wanted to run a service more or less your only choice was srvany.

All about services

srvany is a tool provided by Microsoft which allows you to take any application and run it as a service. It may be instructive to talk about services. They have a special API and must behave it specific ways. You can’t just whack in any old application and say "you’re a service" – you need to implement particular routines in the source code for your program. srvany does the service manager interaction for you. It implements the necessary functionality to run as a service itself and launches your application in a separate process. So whilst Freelancer doesn’t know how to be a service, srvany does, and it knows how to run Freelancer.

The bad news

The problem with srvany is that it is somewhat unsophisticated. Yes, it knows how to be a service. Yes, it knows how to run your application. But that’s about it. It doesn’t know what to do if your application crashes and, as I already mentioned, Freelancer would indeed crash.

srvany would start up, register itself with the service manager, launch Freelancer and go to sleep. Then Freelancer would crash and srvany would stay asleep. As far as Windows was concerned, everything was fine. srvany was still running which means everything’s good. Except that everything wasn’t good because the thing you actually wanted to run wasn’t running at all.

The evolution of NSSM

This is where NSSM comes in. It’s an abstraction of a tool I wrote called flmonitor which was designed to run Freelancer as a service by doing exactly what srvany did except that if Freelancer died it would start it up again. Remove the hardcoded execution path of Freelancer and throw in a simple GUI to allow the user to choose which program to monitor and you have NSSM, a clean-room reimplementation of srvany which didn’t fall in a heap if the program you servicified happened to crash.

All these years later the criticism is made that it isn’t NSSM’s job to go around restarting services; that should be left to Windows itself. I take the point. In an ideal world NSSM wouldn’t have to restart things. Unless you remember how it was back in 2003, however, you may not realise that saying "Windows will restart my service when it fails" doesn’t help you much if Windows thinks your service hasn’t failed. Not to mention that service recovery actions, though they are not a new thing and were available back then, still need to be manually configured. NSSM solved a real problem and as a nice side effect gave you some useful functionality that you’d otherwise have to go out of your way to get.

Nonetheless the point stands and NSSM 2.3 features the ability to configure what NSSM does when the monitored program exits.

So as not to give an unwanted surprise to people who are used to its original functionality, NSSM’s default behaviour will still be to restart a failed application just like it always did. It can be configured, however, to do one of two other things. First of all it can ignore the failure and carry on running. In this sense it will act exactly like srvany. Useful for nostalgics or for people who want to run a service once at startup. Indeed I’ve received a handful of emails over the years from people trying to use NSSM to run a batch job when their machine boots up, only to find that after the batch script runs NSSM will run it again, spamming the system with batch jobs and eating CPU. If you really want to do this with NSSM you now can.

The other option is for NSSM to tell the service manager that it is stopping when the monitored application exits. This means that you can then configure the service recovery options in Windows and have the operating system restart your service or run a custom script which you could never reliably get to work with srvany.

As an added bonus NSSM will let you configure different actions depending on the exit code of the application it runs. You could do stuff like exit if the job ran successfully or restart it if it failed, for example.

Bug fixes

Finally there are some bug fixes. I’ve fixed a longstanding complaint whereby NSSM’s messages to the event log were prefixed by a blurb from Windows about missing a messages file. Anyone who’s tried to use FormatMessage() and ReportEvent() to interact with the event log knows what a monumental hassle it is to do so correctly. Anyone who hasn’t can take my word for it. In any case I got round to doing The Right Thing and NSSM’s log messages are now less cluttered and more elegant.

Lastly an issue reported to me on these very pages by Joel Reingold has been fixed. Running applications with really really long command lines now works properly.