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

Re: I'm not a huge fan of systemd

On Wed, 09 Jul 2014 11:41:37 +0100
Martin Read <zen75502@zen.co.uk> wrote:

> On 09/07/14 05:07, Steve Litt wrote:
> [regarding double fork]
> > In other words, it's going to bust my program, right?
> Maybe. Do the programs you launch need to outlive your session? If
> so, your launcher program's design will run into problems in a
> systemd world.
> If not, you should be fine.

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.

#!/usr/bin/perl -w
use strict;

use POSIX qw(setsid);

sub launch(@) {
    my(@args) = @_;
    unless (fork) {
        setsid;             # set child process to new session
        unless (fork) {     # Create a grandchild
            close STDIN;    # close std files
            close STDOUT;
            close STDERR;
            exec @args;     # exec the x program


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.

So, for instance, to run Gnumeric, umenu.pl would issue the following

./ufork.pl gnumeric

And then umenu.pl would terminate, but gnumeric would keep on running.
I just did it, and here's its output from ps ajxf:

    1 13303 13302 13302 ?           -1 S     1000   0:00 gnumeric

The parent process is 1, not whatever umenu.pl was.

I really hope systemd doesn't break that, because unless *everything*
is systemd, I'd need two versions of my program.



Steve Litt                *  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance

Reply to: