Declined SERVICEMONITOR suggestions

[vefatica]

I wanted to monitor the starting and stopping of a service. SERVICEMONITOR would be a lot easier to use if it ...

1. could watch for more than one condition (notably, STARTED or STOPPED), and

2. would only execute its <command> when the status changed (to a watched-for status). There doesn't seem to be much point in its executing the command several times a second.

v:\> servicemonitor WaaSMedicSvc stopped 5 `echo %_time %_servicename %_servicestate`

v:\> 11:37:16 WaaSMedicSvc 1
11:37:16 WaaSMedicSvc 1
11:37:16 WaaSMedicSvc 1
11:37:16 WaaSMedicSvc 1
11:37:16 WaaSMedicSvc 1

I wrote service_monitor.btm (using @WMI) which gives me what I want.

WaaSMedicSvc Started: 21:48:20  Stopped: 21:49:20
WaaSMedicSvc Started: 21:54:23  Stopped: 21:55:24
WaaSMedicSvc Started: 21:58:23  Stopped: 21:59:24
WaaSMedicSvc Started: 22:23:56  Stopped: 22:24:57
WaaSMedicSvc Started: 22:28:17  Stopped: 22:29:18
WaaSMedicSvc Started: 22:34:21  Stopped: 22:35:22
WaaSMedicSvc Started: 22:38:21  Stopped: 22:39:22
WaaSMedicSvc Started: 23:38:22  Stopped: 23:39:22

To do that using SERVICEMONITOR I would have to write a BTM with a polling loop that alternated between servicemonitor WaaSMedicSvc started 1 and servicemonitor WaaSMedicSvc stopped 1 and only reported when _servicestate changed. That would have been cumbersome.

 

[rconn]

Unclear to me why you would want to alternate SERVICEMONITOR - you can have multiple SERVICEMONITOR commands running at a time.

 

[rconn]

I wanted to monitor the starting and stopping of a service. SERVICEMONITOR would be a lot easier to use if it ...

2. would only execute its <command> when the status changed (to a watched-for status). There doesn't seem to be much point in its executing the command several times a second.

WAD - SERVICEMONITOR "stopped" is looking to see if the service is stopped. It is not attempting to determine first that the service was running when you started SERVICEMONITOR and only then look to see if it's been stopped at some later time. This would be a major breaking change.

 

[vefatica]

Unclear to me why you would want to alternate SERVICEMONITOR - you can have multiple SERVICEMONITOR commands running at a time.

Yeah, but if I don't specify repititions = 1, one of the SERVICEMONITORs will trigger its command about 30 times a second!

 

[rconn]

Yeah, but if I don't specify repititions = 1, one of the SERVICEMONITORs will trigger its command about 30 times a second!

SERVICEMONITOR (like most of the other monitoring functions) is looking for a matching state, not a change in the state. You're using the wrong tool for the job.

 

[vefatica]

Can you give an example of a job for which SERVICEMONITOR would be the right tool?

 

[rconn]

When you know the current state and are looking for a change.

You're trying to use SERVICEMONITOR when you don't know if the service is started or stopped. You apparently want to change SERVICEMONITOR to tri-state; that is a (seriously) breaking change.

 

[vefatica]

I can easily find out it's current state, @WMI for example. But that's not the point.

When you know the current state and are looking for a change.

Do you mean ... poll forever until the new state arrives and then have the <command> close the SERVICEMONITOR?

 

[rconn]

No, I meant something like querying @SERVICE to get the state and then starting SERVICEMONITOR with the appropriate arguments.

 

[vefatica]

No, I meant something like querying @SERVICE to get the state and then starting SERVICEMONITOR with the appropriate arguments.

And then what? If you didn't specify 1 repetition, and don't terminate the SERVICEMONITOR or change the service's state in its command, it'll keep triggering the command. It's the continual triggering that I don't find useful.

 

[rconn]

SERVICEMONITOR is not intended for what you're trying to do, and given that you're the only one that wants this, it isn't going to be changed (and break everyone else) to do it.

You would be better served by some combination of @SERVICE (in a loop) or writing a plugin.