Domoticz

Posted: **Sunday 17 January 2021 11:44**

In regular lua scripts I use

os.execute('some-command > /data/some-command.output.json &'

to trigger a lenghty (> a few seconds) collection of data that Domoticz some moments later will pick up. Notice the background processing with &. This works well.

Tried the same technique in dzVents, using a timer-triggered

Code: Select all

dz.utils.osExecute('some-command > /data/output.json 2> /data/error.json &')

This causes Domoticz to leave a defunct process behind for each execution of the collection script.

Code: Select all

# ps -ef | grep fronius | head
root       304 27346  0 04:11 ?        00:00:00 [fetch-fronius-d] <defunct>
root       312 27346  0 Jan16 ?        00:00:00 [fetch-fronius-d] <defunct>
root       317 27346  0 Jan16 ?        00:00:00 [fetch-fronius-d] <defunct>
.. (several 1000-s of processes...)

Same behaviour with plain os.execute in dzVents. I'm running 2020.2 on Linux (x86).

Known problem? Can I call the collection script in some other way to avoid the defunct processes?

Posted: **Sunday 17 January 2021 13:15**

krej wrote: ↑Sunday 17 January 2021 11:44 .. This causes Domoticz to leave a defunct process behind for each execution of the collection script.
Known problem? Can I call the collection script in some other way to avoid the defunct processes?

The os.execute and dz.utils.osExecute calls in dzVents are both the same call to the domoticz Lua engine as the one in classic Lua.

I cannot replicate the issue but maybe because I am on 2020.2 build 12850. I sometimes see 1 defunc process for a minute or so but even when I force the background process to be alive for quite a long time 100 or even 2000 seconds I don't see this behavior.

Do you see this with one specific 'some-command' or can you reproduce this with other lengthy commands (eg sleep 20)?

in dzVents 3.1.0 (domoticz build 12771). executeShellCommand() was introduced offering aSync shell command execution in much more robust and useful way including callback and returning results. If your issue cannot be fixed in an acceptable way while on your build of 2020.2 , you might want to have a look at that.

Posted: **Sunday 17 January 2021 20:23**

Just tried with this simple script

Code: Select all

return {
	on = {
		timer = { 'every minute' },
	},
	execute = function(dz, timer)
	        dz.log('Timer event was triggered by ' .. timer.trigger, dz.LOG_INFO)
	        os.execute('sleep 20 > /data/sleep.stdout 2> /data/sleep.stderr &') 
	end
}

and the defunct processes still appear.

Code: Select all

# ps -ef| grep slee
root      6432 27346  0 19:06 ?        00:00:00 [sleep] <defunct>
root      6792 27346  0 19:07 ?        00:00:00 [sleep] <defunct>
root      7115 27346  0 19:08 ?        00:00:00 [sleep] <defunct>
root      7439 27346  0 19:09 ?        00:00:00 [sleep] <defunct>
root      7817 27346  0 19:10 ?        00:00:00 [sleep] <defunct>

Out of curiosity, I checked signal status for domoticz:

Code: Select all

~$ ./signals 27346
SigPnd: 0000000000000000 0
ShdPnd: 0000000000000000 0
SigBlk: 0000000000000000 0
SigIgn: 0000000001001000 1000000000001000000000000 PIPE XFSZ
SigCgt: 00000001800046ea 110000000000000000100011011101010 INT ILL ABRT BUS FPE USR1 SEGV TERM

Domoticz does not ignore SIGCHLD, which means there has to be a signal handler registered that reacts to dead children.

It may be of interest to know that I'm running Domoticz in a docker container.

Domoticz

utils.osExecute leaves defunct processes

utils.osExecute leaves defunct processes

Re: utils.osExecute leaves defunct processes

Re: utils.osExecute leaves defunct processes