Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I am fairly new to *nix, and have come across the need to drop multiple processes, that should be run 100% of the time. to background using &.

I use the following line in an init.d script to do this (running as the user user:

su -c 'process arg1 arg2 -w - | process2 arg1 -r - &' user

(where -w writes to and -r reads from STDOUT, STDIN)

Specifically, I know this is not generally acceptable, as the processes aren't well shielded from outside influence.

Is it acceptable to create background jobs for "services?"

Should I instead use a FIFO/named pipe to handle the interprocess communication?

If so, should I still create both processes as background jobs? Is this stable?

For specifics, please refer to this mailing list thread.

Thanks,

Matt

share|improve this question
1  
Just a quick hint, have a look at the various process supervision tools, e.g. daemontools, runit, upstart, systemd -- they all require non-self-daemonizing services. –  sr_ Jul 12 '12 at 19:41
    
Thanks, I will look into that itself. With the above "solution," I relied on the processes own ability to create PID files, then referred to them if -fwith killproc. –  mbrownnyc Jul 12 '12 at 19:45

2 Answers 2

Specifically, I know this is not generally acceptable, as the processes aren't well shielded from outside influence.

Is it acceptable to create background jobs for "services?"

If there's no other way (that is, the service won't fork on its own), then probably yes. Debian's start-stop-daemon has a --background parameter for such cases:

   -b, --background
          Typically used with programs that don't  detach  on  their  own.
          This option will force start-stop-daemon to fork before starting
          the  process,  and  force  it  into  the  background.   WARNING:
          start-stop-daemon  cannot  check  the exit status if the process
          fails to execute for any reason. This is a last resort,  and  is
          only  meant  for  programs  that either make no sense forking on
          their own, or where it's not feasible to add the code  for  them
          to do this themselves.
share|improve this answer
    
Thanks!!!!!!!11 –  mbrownnyc Sep 16 '13 at 20:58

As the first question is already answered, I'll concentrate on the last both.

Some days ago I struggled about a similar problem: I had to start some processes via pipe from /etc/init.d scripts. To solve this, I had a look at RHEL6 (daemon and killproc of /etc/init.d/functions) and Debian (start-stop-daemon). What I learned was, that both did not handle pipes (very well). Even it was somehow possible to start them, there were major problems stopping them. Therefore I wrote a small tool pipexec. This program starts a pipe of programs but behaves like one program. Example: when a SIGTERM is send to pipexec it kills all the children and afterwards itself. Also pid file handling is supported - which gives you an easy live when integrating with RHEL6 daemon and killproc.

Should I instead use a FIFO/named pipe to handle the interprocess communication? If so, should I still create both processes as background jobs? Is this stable?

I also thought about this - but for me this is to complicated and I did not have really good experience when it comes to fifos regarding stability and reliability (maybe this is my problem - but therefore I rarely use them ;-) )

I integrated pipexec with RHEL6 and there are no problems; it just runs.

Kind regards - Andreas

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.