post action

post action

[Alejandro Mery]

Hi, I have a problem with a service [1] which runs fine and handles 
HUP, TERM correctly and sends output to stderr as a good citizen. 
Unfortunately it (re)creates a unix socket with permissions unfit 
for the purpose, so I have to chmod g+w /var/run/thin-*/socket every 
time. cron gives me a granularity of 1 minute which still makes the 
application unreachable for up-to one looooong minute.

The authors don't care because it works fine when daemonizing... and 
"one shall daemonize the daemons"... no comment on that.

Is there an elegant way of solving this issue with runit?

Thanks,
Alejandro Mery

[1] <http://code.macournoyer.com/thin/>

Re: post action

[Charlie Brady]

On Fri, 5 Nov 2010, Alejandro Mery wrote:

> Hi, I have a problem with a service [1] which runs fine and handles HUP, TERM
> correctly and sends output to stderr as a good citizen. Unfortunately it
> (re)creates a unix socket with permissions unfit for the purpose, so I have to
> chmod g+w /var/run/thin-*/socket every time. cron gives me a granularity of 1
> minute which still makes the application unreachable for up-to one looooong
> minute.
> 
> The authors don't care because it works fine when daemonizing... and "one
> shall daemonize the daemons"... no comment on that.
> 
> Is there an elegant way of solving this issue with runit?

I don't think it's runit's problem. It's a problem with thin. Since thin
appears to be a daemon written in ruby, you can just patch it.

If it were a binary only application, that you couldn't patch, you could 
use LD_LIBRARY_PRELOAD to load a shim which captures the chmod call, and 
just ignores it if the path matches your socket.

> Thanks,
> Alejandro Mery
> 
> [1] <http://code.macournoyer.com/thin/>
> 
> 

Re: post action

[Charlie Brady]

Alternatively, your run script could fork. The parent could exec thin. 
The child could wait until thin makes the bad socket, then fix it, then 
exit. This would leave you with a zombie, but a good socket.

Re: post action

[Alejandro Mery]

Hi Charlie,

El 05/11/10 13:11, Charlie Brady escribió:
> On Fri, 5 Nov 2010, Alejandro Mery wrote:
>
>> Hi, I have a problem with a service [1] which runs fine and handles HUP, TERM
>> correctly and sends output to stderr as a good citizen. Unfortunately it
>> (re)creates a unix socket with permissions unfit for the purpose, so I have to
>> chmod g+w /var/run/thin-*/socket every time. cron gives me a granularity of 1
>> minute which still makes the application unreachable for up-to one looooong
>> minute.
>>
>> The authors don't care because it works fine when daemonizing... and "one
>> shall daemonize the daemons"... no comment on that.
>>
>> Is there an elegant way of solving this issue with runit?
> I don't think it's runit's problem. It's a problem with thin. Since thin
> appears to be a daemon written in ruby, you can just patch it.

yes, I agree it's not runit's problem, it's thin's problem. And 
patching leads to maintenance problems. So I was wondering if anyone 
had solved the "problem" of post actions using service/control/<c> 
or similar.

> If it were a binary only application, that you couldn't patch, you could
> use LD_LIBRARY_PRELOAD to load a shim which captures the chmod call, and
> just ignores it if the path matches your socket.

that's not a bad idea

Regards,
Alejandro Mery

Re: post action

[Charlie Brady]

On Fri, 5 Nov 2010, Alejandro Mery wrote:

> > If it were a binary only application, that you couldn't patch, you could
> > use LD_LIBRARY_PRELOAD to load a shim which captures the chmod call, and
> > just ignores it if the path matches your socket.
> 
> that's not a bad idea

I used that method once with an unpatched qmail (before DJB allowed 
distribution of patched versions) to prevent it forwarding to 0.0.0.0. I 
could dig up the code if that would be helpful to you.

Re: post action

[Laurent Bercot]

> Unfortunately it (re)creates a unix socket with permissions unfit 
> for the purpose, so I have to chmod g+w /var/run/thin-*/socket every 
> time. cron gives me a granularity of 1 minute which still makes the 
> application unreachable for up-to one looooong minute.

 If you want to avoid patching software or doing ugly things like
intercepting syscalls (YMMV, but to me it IS ugly :P), depending on
your OS, you could set up an additional service that watches the
socket creation and automatically chmods it to the right permissions.

 Unfortunately, Unix does not offer any portable way to be notified
of FS operations, so the code of that additional service would have to
be OS-specific. For instance, you'd use "inotify" on Linux and "kevent"
on BSD.

 Or you would have to resort to polling - which is exactly what cron does
anyway, except using a specific service would let you have control over
the polling granularity. But I am definitely not going to suggest that.
(What is the lesser evil between polling and intercepting syscalls? now
that's an interesting question of faith. :))

-- 
 Laurent