Re: [usp.ruby]
- From:
- Eric Wong
- Date:
- 2012-09-05 @ 02:50
Evgeni Dzhelyov <evgeni.dzhelyov@gmail.com> wrote:
> Eric,
>
> I have some topics that I'm researching and they may seem like a good
> fit for the list. I'm listing them below:
>
> 1. The Unix expectation / recommendation for writing console binaries.
> Like passing switch parameters, availability of help message and man
> pages, return codes.
It's not Ruby-specific nor system programming, but the conventions
of common, existing command-line tools are a good place to start.
For most command-line interfaces, users should/need not care what
language was used to implement the tool. So the conventions for
existing CLIs implemented in C, Perl, sh, Python, etc... should all
apply to applications written in Ruby.
Eric S. Raymond's The Art Of Unix Programming
(http://www.catb.org/esr/writings/taoup/html/) is also an excellent
read on Unix tool design/philosopy.
> 2. What are the requirements for implementing a reliable, complete
> deamon program.
The same requirements for implementing _any_ reliable program :)
The main thing a daemon needs is detaching from the controlling
terminal. As mentioned before, Process.daemon in Ruby 1.9 does
this for you (and I shall explain what it does in a later post,
but it's really not that interesting).
And some "daemons" are only spawned (and run as undetached children)
by an existing daemon process. (I expect some of the books mentioned
earlier in this thread cover this, but I've not read any of them).
> Recently I had to create a long running processe and found that
> there are different use cases that should be handled for long running
> processes without human intervention - like logging, keep track of
> state, so you can restart from a point, etc.
For all of these things, you need to enforce consistency in writing to
the filesystem. For logging, the Logger class mostly takes care of that
for you (or you can use the Syslog ext as a wrapper for syslog(3)).
If you're maintaining state across restarts/crashes/reboots, then making
writes atomic, consistent, and durable is required (basically the same
rules for implementing a robust database). Of course, you can also
just _use_ a robust database for maintaining state :)
(I thought I covered some of this, but apparently not, or not on
this list :x)
> I had to also figure out if a running daemon is working or not
> (being stuck). Examples of how to allow such introspection would be
> nice.
Using a tracing tool (e.g. strace on Linux, truss/ktrace/ktruss on
others) is often the most reliable way.
Re: [usp.ruby]
- From:
- Evgeni Dzhelyov
- Date:
- 2012-09-05 @ 07:45
Eric, thank you for the detailed explanation.
Thanks for the book recommendation and the library I will check them out.
Re: [usp.ruby]
- From:
- Kenneth Kalmer
- Date:
- 2012-09-01 @ 13:29
On Sat, Sep 1, 2012 at 7:09 AM, Evgeni Dzhelyov
<evgeni.dzhelyov@gmail.com> wrote:
> 2. What are the requirements for implementing a reliable, complete
> deamon program.
>
> Recently I had to create a long running processe and found that
> there are different use cases that should be handled for long running
> processes without human intervention - like logging, keep track of
> state, so you can restart from a point, etc.
> I had to also figure out if a running daemon is working or not
> (being stuck). Examples of how to allow such introspection would be
> nice.
Hi Evgeni
have you had a look at daemon-kit
(http://github.com/kennethkalmer/daemon-kit) yet for building daemon
processes with Ruby?
Admittedly it has been neglected a bit, but it is still fully
functional. I've aimed to help solve a lot of your questions with
daemon-kit, allowing you as developer to focus on your application and
not the semantics of handling exceptions, logging, killed threads,
etc... Even in the event of a daemon process crashing, we attempt to
write out a 'backtrace' file with all the exceptions in memory so you
can inspect what the real cause was for your failing code.
Cheers
--
Kenneth Kalmer
kenneth.kalmer@gmail.com
http://opensourcery.co.za
@kennethkalmer
Re: [usp.ruby] daemon-kit
- From:
- Steffen Uhlig
- Date:
- 2012-09-01 @ 15:52
Hi Kenneth,
Would daemon-kit also be applicable for running a DRb server? I am
trying to understand how much of the daemon handling is already in
DRb, how to launch it using OS startup scripts, etc.
Any hints welcome.
Regards
Steffen
--
Gruß
Steffen
On 01.09.2012, at 15:31, Kenneth Kalmer <kenneth.kalmer@gmail.com> wrote:
> On Sat, Sep 1, 2012 at 7:09 AM, Evgeni Dzhelyov
> <evgeni.dzhelyov@gmail.com> wrote:
>
>> 2. What are the requirements for implementing a reliable, complete
>> deamon program.
>>
>> Recently I had to create a long running processe and found that
>> there are different use cases that should be handled for long running
>> processes without human intervention - like logging, keep track of
>> state, so you can restart from a point, etc.
>> I had to also figure out if a running daemon is working or not
>> (being stuck). Examples of how to allow such introspection would be
>> nice.
>
> Hi Evgeni
>
> have you had a look at daemon-kit
> (http://github.com/kennethkalmer/daemon-kit) yet for building daemon
> processes with Ruby?
>
> Admittedly it has been neglected a bit, but it is still fully
> functional. I've aimed to help solve a lot of your questions with
> daemon-kit, allowing you as developer to focus on your application and
> not the semantics of handling exceptions, logging, killed threads,
> etc... Even in the event of a daemon process crashing, we attempt to
> write out a 'backtrace' file with all the exceptions in memory so you
> can inspect what the real cause was for your failing code.
>
> Cheers
>
>
> --
> Kenneth Kalmer
> kenneth.kalmer@gmail.com
> http://opensourcery.co.za
> @kennethkalmer
Re: [usp.ruby] daemon-kit
- From:
- Kenneth Kalmer
- Date:
- 2012-09-02 @ 22:27
On Sat, Sep 1, 2012 at 5:52 PM, Steffen Uhlig <steffen@familie-uhlig.net> wrote:
> Hi Kenneth,
>
> Would daemon-kit also be applicable for running a DRb server? I am
> trying to understand how much of the daemon handling is already in
> DRb, how to launch it using OS startup scripts, etc.
>
> Any hints welcome.
Hi Steffen
It will be perfect for that. Ruby (by implication DRb too) only
provides Process::daemon (1.9+) and then a lot of rope to hang
yourself with. I'm generalising very badly here, but where the Ruby
docs refer to a server (eg TCPServer or DRb::DRbServer) it means more
a instance that waits for a client to connect and then interact with.
None of this involves advanced, logging, monitoring (god/monit),
signal handling, etc...
daemon-kit was created to fill that gap.
In your case, you'd generate a daemon and setup the DRb server
component in libexec/ (of the generated daemon), and once you're happy
that everything works, you can use another generator to generate some
stub god/monit config files that you can deploy to your servers to
ensure the daemon gets launched on startup, and stays up.
Please let me know where I can help clarify this 30,000ft view.
Ciao!
--
Kenneth Kalmer
kenneth.kalmer@gmail.com
http://opensourcery.co.za
@kennethkalmer
Re: [usp.ruby]
- From:
- macarthy
- Date:
- 2012-09-01 @ 05:40
2 book recommendations for you:
Unix processes:
http://workingwithunixprocesses.com/ (available at pragprog.com too)
http://www.amazon.com/gp/product/0201433079/ref=as_li_ss_tl?ie=UTF8&tag=chamaxwoo-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0201433079
And for :
> 1. The Unix expectation / recommendation for writing console binaries.
> Like passing switch parameters, availability of help message and man
> pages, return codes.
Build awesome command line applications in ruby
http://pragprog.com/book/dccar/build-awesome-command-line-applications-in-ruby
As for
> 2. What are the requirements for implementing a reliable, complete
> deamon program.
Look at the source of bluepill, god etc. Also Jesses book (unix
process book above) has some chapters at the end on that topic.
Justin Mac Carthy
On 1 September 2012 12:09, Evgeni Dzhelyov <evgeni.dzhelyov@gmail.com> wrote:
> Eric,
>
> I have some topics that I'm researching and they may seem like a good
> fit for the list. I'm listing them below:
>
>
>
> Recently I had to create a long running processe and found that
> there are different use cases that should be handled for long running
> processes without human intervention - like logging, keep track of
> state, so you can restart from a point, etc.
> I had to also figure out if a running daemon is working or not
> (being stuck). Examples of how to allow such introspection would be
> nice.
>
> Cheers,
> Evgeni