# How can spawning subprocesses affect buffering?

**URL:** <https://www.ruby-forum.com/t/how-can-spawning-subprocesses-affect-buffering/194279>\
**Category:** Ruby\
**Created:** [September 1, 2010, 11:43pm UTC](https://www.ruby-forum.com/t/how-can-spawning-subprocesses-affect-buffering/194279 "2010-09-01T23:43:23Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Marcin\_L](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/df788c/32.png) [@Marcin\_L](https://www.ruby-forum.com/u/Marcin_L)\
**Post date:** [September 1, 2010, 11:43pm UTC](https://www.ruby-forum.com/t/how-can-spawning-subprocesses-affect-buffering/194279/1 "2010-09-01T23:43:23Z")

</div>

Hi,

I am writing a system, where there are a few small, slave ruby scripts  
doing something, spawned by master one.

I encountered propably a bug, and I don’t know, how to solve it, so  
please give me some help…

Please consider following script:

#!/usr/bin/ruby  
require ‘glib2’  
require ‘dbus’

bus = DBus::SessionBus.instance  
bus.glibize  
service = bus.request\_service(“dummy.test”)

class DummyDBUS \< DBus::Object  
dbus\_interface “dummy.Test” do  
dbus\_method :Shutdown do  
$mainloop.quit  
end

dbus\_method :Spawn do  
system("/bin/sh -c ‘while [1]; do echo . \>\> /tmp/dot; sleep 1;  
done &’")  
end  
end  
end

$mainloop = GLib::MainLoop.new

dbus\_object = DummyDBUS.new “Application”  
service.export dbus\_object

$mainloop.run

The idea is that I spawn a some subprocesses after receiving a command  
via DBus. Later they communicate via DBus after slave subprocesses had  
performed their tasks.

Unfortunately, Shutdown() command does not work if you previously  
spawn any subprocesses using Spawn() command. It kills the master  
process, but DBus does not release service name until it

I’ve check that it does not matter if they are spawned like

system("/bin/sh -c ‘while [1]; do echo . \>\> /tmp/dot; sleep 1; done  
&’")

or

exec(“while [1]; do echo . \>\> /tmp/dot; sleep 1; done &”) if  
fork.nil?

or any other way to daemonize subprocess (I’ve tried also  
Daemons.daemonize).

So the first test case is:

1. Spawn master script mentioned above.
2. Call Shutdown() method via DBus.
3. Works perfectly - master process is killed and removed from DBus’  
service list.

Second test case is:

1. Spawn master script mentioned above.
2. Call Spawn() method via DBus.
3. Check, for sure, if subprocess works (tailf /tmp/dot) and if it’s  
separated from master process (e.g. pstree)
4. Call Shutdown() method via DBus.
5. Bug! Master process gets killed (mainloop is stopped) but service  
name is not released in DBus until subprocess is killed.

Why?

It seems that some DBus messages are waiting until subprocess is  
killed - it’s easy to see with dbus-monitor. But how it’s possible  
that spawning a subprocess causes buffering those data? Is it a ruby  
internal bug? Maybe ruby-dbus bug? dbus itself?

PS. I’ve checked that also without calling bus.glibize, with normal  
loop - the same effect.  
PS2. I use ubuntu 10.04, ruby 1.8.7 (2010-01-10 patchlevel 249),  
libdbus-ruby 0.4.0, libglib2-ruby1.8 0.19.3-1ubuntu3

I appreciate any help or directions,

I also found that master application behavior is different when you  
run it via strace but I am not so proficient to interpret that data…

thank you in advance,

---

<div class="post-metadata">

**Author:** ![Marcin\_L](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/df788c/32.png) [@Marcin\_L](https://www.ruby-forum.com/u/Marcin_L)\
**Post date:** [September 3, 2010, 12:32pm UTC](https://www.ruby-forum.com/t/how-can-spawning-subprocesses-affect-buffering/194279/2 "2010-09-03T12:32:46Z")

</div>

That was a bug in ruby-dbus, resolution is here

> <https://github.com/mvidner/ruby-dbus/commit/0260202477d255f827e92bfe18895c5a111c991b>
>
> Otherwise if a service grabs a name, spawns a daemon, and quits,
> the name will n…ot be released because the daemon uselessly inherited
> the socket connecting the service to the bus.
> 
> https://lists.luon.net/pipermail/ruby-dbus-devel/2010-September/000348.html

m.