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
}
}
sleep(1);
}
launch(@ARGV);
=================================================================
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
command:
./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.
Thanks,
SteveT
Steve Litt * http://www.troubleshooters.com/
Troubleshooting Training * Human Performance
Reply to: