[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: I'm not a huge fan of systemd



Steve Litt wrote:
> I don't understand the question because I don't know what a session is,
> so there's the Perl code. I have these things in Ruby and Lua too, and
> I think also in C.

Looks okay to me.  But I do have a comment or two.

> #!/usr/bin/perl -w
> use strict;
> 
> use POSIX qw(setsid);
> 
> sub launch(@) {

I actually don't like perl prototypes.  (shrug)  Each to their own.

>     my(@args) = @_;
>     unless (fork) {
>         setsid;             # set child process to new session
>         unless (fork) {     # Create a grandchild

All good.  I like short circuit evaluation to avoid indention
however.  In the above the indentation keeps needing to go to the
right.  But it could stay to the left.

  if (fork()) {
    exit(0);
  }

I don't like the one line backwards syntax but others do.

  exit(0) if fork();

Again it is all a matter of style.

>             close STDIN;    # close std files
>             close STDOUT;
>             close STDERR;

Instead of closing 0, 1, 2 descriptors I like to redirect them to and
from /dev/null.  If they are closed and something decides to read from
them then it will get an error.  If it is /dev/null then there is no
error but all redirected from a tty so that it does not reacquire a
controlling terminal.

  open(STDIN,"+</dev/null");
  open(STDOUT,"+>/dev/null");
  open(STDERR,"+>&STDOUT");

It is just style but something to think about.

>             exec @args;     # exec the x program
>         }
>     }
>     sleep(1);

There shouldn't be a need for the first parent to sleep there.

You should consider putting in a chdir("/") or perhaps $HOME if it is
for personal use.  That way if you launch a daemon from a mount point
that it does not keep the mount point busy.

  chdir("/");

You might consider closing any open file descriptor 3 or above that is
also open to a tty.  That prevents any open file descriptor open to a
tty to prevent it from reacquiring it as a controlling terminal.
(Some programs that run sub-shells open additional descriptors and
forget to close them.  Current emacs 24 has a bug like that in its
inferior shell.  This can be seen by running any of the lvm commands
from within an emacs shell.  It will check for this and complain.)

The only issue is knowing how many descripts to check?  At one itme it
was hard limited to 20.  Then hard limited to 60.  Then newer kernels
like Hurd doesn't have an upward limit!  So I just pick 60 out of
being pragmatic.

  $openmax ||= 60;
  for (my $i = 3; $i < $openmax; ++i) {
      if (-t $i) {
          POSIX::close($i);
      }
  }

Again just something to think about.

> The preceding is called ufork.pl, and its purpose is to keep the
> exec'ed command contained in its arguments running long after the
> program that called ufork.pl (umenu.pl) has terminated itself, because
> the normal use case of umenu.pl is to run a program and immediately
> terminate itself.

It creates a full daemon process.  It disassociates from the
controlling terminal and ensures that it won't reacquire a new
controlling terminal.  Since it becomes a full daemon it is not going
to be receiving any SIGHUP to any foreground process group.  Avoids
any need for nohup.

Bob

Attachment: signature.asc
Description: Digital signature


Reply to: