# service stop & rcorder



## fluca1978 (Dec 14, 2012)

I noticed that service(1) performs a raw exec(1) of the script passed as its first argument using the verb as argument to such script, therefore something like

```
service blah stop
```
results in

```
exec env -i HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin /somewhere/blah stop
```

This is asymmetric with the boot/startup process, that is driven by rcorder(1) and is based on the _REQUIRE/PROVIDE_ annotations. Therefore if I, for instance, do the _stop_ of a daemon in my stack that provides services to other daemons, other daemons are not notified, correct? Is there a reason I cannot see for this behaviour or another tool to use instead of service(1) to handle intra-daemon state changes?


----------



## SirDice (Dec 14, 2012)

fluca1978 said:
			
		

> Therefore if I, for instance, do the _stop_ of a daemon in my stack that provides services to other daemons, other daemons are not notified, correct?


Correct.



> Is there a reason I cannot see for this behaviour or another tool to use instead of service(1) to handle intra-daemon state changes?



I'm not sure if that functionality is there but it does have other nice features. I'm hoping this will someday make it to the base.

sysutils/fsc


----------

