[launchd-dev] launchd-dev Digest, Vol 25, Issue 7
Nehemiah Dacres
vivacarlie at gmail.com
Fri Jul 31 08:06:12 PDT 2009
why is the perror command only in MySQL this should be in every Linux. is
there a way to toss this into Snow Leopard at the last Minuit? I could have
done it in one line but it wouldn't be polite (as a program or as readable
code)
#include <unistd.h>
#include <stdio.h>
#include <string.h>
int main (int argc, char** argv){
if (argc != 2) printf("usage: %s errnum\n",argv[0]);
else printf("%s\n",strerror(atoi(argv[1])));
return 0;
}
On Thu, Jul 30, 2009 at 9:00 AM,
<launchd-dev-request at lists.macosforge.org>wrote:
> Send launchd-dev mailing list submissions to
> launchd-dev at lists.macosforge.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
> or, via email, send a message with subject or body 'help' to
> launchd-dev-request at lists.macosforge.org
>
> You can reach the person managing the list at
> launchd-dev-owner at lists.macosforge.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of launchd-dev digest..."
>
>
> Today's Topics:
>
> 1. Fwd: Stray process with PGID equal to this dead job (Johannes)
> 2. Re: Stray process with PGID equal to this dead job
> (Damien Sorresso)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 28 Jul 2009 16:07:02 +0200
> From: Johannes <list100 at hoerburger.org>
> To: launchd-dev at lists.macosforge.org
> Subject: [launchd-dev] Fwd: Stray process with PGID equal to this dead
> job
> Message-ID: <CEDB4D6B-CB34-40A0-A4A6-01F243981CFB at hoerburger.org>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> OK, solved it by myself, did it the weird-apple way:
> A launchctl triggered backupfather.pl now creates Launchagents.plist
> for every child process including the calling arguments and triggers
> launchctl load/start for these creations...
>
> a lot of useless filewriting just for backgrounding processes for
> which a normal "&" would be enough as it seems but at least it works...
>
> Greets
> Johannes
>
> Am 27.07.2009 um 20:26 schrieb Johannes:
>
> > Sorry for reopening a thread that was already dealt with, but I ran
> > into a serious problem that I'm not able to workaround in any way.
> >
> > I have a perlscript (let's call it backupfather.pl) that calls a
> > second perlscript (backupchild.pl) 15 times for initiating rsync
> > over ssh backups from 15 different client-hosts.
> >
> > The callerscript knows how to deal with open processes (keep them
> > running for a designated time, kill them if the target host where it
> > fetches the backup from isn't reachable or the backup script is
> > overtime, don't launch the child script for a specific host if one
> > process like that is still running)
> >
> > Additionally it knows how to deal with the child processes of
> > backupchild.pl (rsync and ssh) building up pid and parent pid trees
> > and killing all involved before launching again with the same
> > arguments.
> >
> > So the processmanagement itself is clean.
> >
> > In order to start the backupchild.pl script 15 times I need to
> > background them. They may rund serveral hours so the backupfather.pl
> > has to get free to initiate the finished backups again after an
> > hour, not initiating the still running ones.
> >
> > I've tried several ways to get out of the launchctl processgroup
> > prison the backupfather.pl is running in.
> >
> > setpgrp doesn't work on Mac OS X (that way it would be possible to
> > let it run under the root's processgroups ID).
> >
> > forking and exiting the backupchild.pl didn't help eighter, nore did
> > creating 15 instances for each client backup and launching them as
> > necessary. As soon as it comes to backgrounding I'm stuck in:
> >
> > "Stray process with PGID equal to this dead job: PID _pidnumber_
> > PPID _parentpidnumber_ perl"
> >
> > Any ideas how to get the backupchild.pl processes out of the
> > launchctl prison?
> >
> > Thanx in advance for any help,
> > Johannes
> > PS: If you're wondering why I don't use TimeMachine for Backups:
> > We've used it till AppleFileServer started eating 100% CPU on the
> > Server, rendering the Fileservice for the regular AFP Fileservice
> > Clients unusable, while SSH at the same time had fullspeed and no
> > problems. So splitting backup from fileservice was the deal for
> > making fileservice useable again...
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 28 Jul 2009 08:58:00 -0700
> From: Damien Sorresso <dsorresso at apple.com>
> To: Johannes <list100 at hoerburger.org>
> Cc: launchd-dev at lists.macosforge.org
> Subject: Re: [launchd-dev] Stray process with PGID equal to this dead
> job
> Message-ID: <0D2CAC6A-092D-4D16-A2E7-80AB2AF5FEF8 at apple.com>
> Content-Type: text/plain; charset="us-ascii"; Format="flowed";
> DelSp="yes"
>
> On Jul 27, 2009, at 11:26 AM, Johannes wrote:
> > Sorry for reopening a thread that was already dealt with, but I ran
> > into a serious problem that I'm not able to workaround in any way.
> >
> > I have a perlscript (let's call it backupfather.pl) that calls a
> > second perlscript (backupchild.pl) 15 times for initiating rsync
> > over ssh backups from 15 different client-hosts.
> >
> > The callerscript knows how to deal with open processes (keep them
> > running for a designated time, kill them if the target host where it
> > fetches the backup from isn't reachable or the backup script is
> > overtime, don't launch the child script for a specific host if one
> > process like that is still running)
> >
> > Additionally it knows how to deal with the child processes of
> backupchild.pl
> > (rsync and ssh) building up pid and parent pid trees and killing
> > all involved before launching again with the same arguments.
> >
> > So the processmanagement itself is clean.
>
> Why bother creating your own tree? You already have a process tree
> maintained by the kernel. "Clean" process management is having the
> parent kill and reap its children as necessary and allowing the
> semantics of POSIX parent-child relationships to create a chain of
> responsibility.
>
> So if your job sends SIGTERM to its immediate child, that child will,
> in turn, forward the SIGTERM to its children, wait for them to exit
> and then die accordingly.
>
> > In order to start the backupchild.pl script 15 times I need to
> > background them. They may rund serveral hours so the backupfather.pl
> > has to get free to initiate the finished backups again after an
> > hour, not initiating the still running ones.
> >
> > I've tried several ways to get out of the launchctl processgroup
> > prison the backupfather.pl is running in.
>
> "launchctl process group prison"? I think you mean "POSIX standard
> behavior". Your child processes inherit a PGID equal to that of their
> parent's PID. launchd has nothing to do with this behavior; it's
> enforced by the kernel. launchd complains about this because your
> job's has attempted to daemonize without calling setsid(2), setpgrp
> (2), etc.
>
> > setpgrp doesn't work on Mac OS X (that way it would be possible to
> > let it run under the root's processgroups ID).
>
> Mac OS X conforms to POSIX, so setpgrp(2) does work. What errno does
> it set when you call it? Are you calling it from the child process
> with 0 as the first argument, or from the parent with the child's PID
> as the first argument?
>
> Also, please read setsid(2).
>
> > forking and exiting the backupchild.pl didn't help eighter, nore did
> > creating 15 instances for each client backup and launching them as
> > necessary. As soon as it comes to backgrounding I'm stuck in:
> >
> > "Stray process with PGID equal to this dead job: PID _pidnumber_
> > PPID _parentpidnumber_ perl"
> >
> > Any ideas how to get the backupchild.pl processes out of the
> > launchctl prison?
>
>
> I would recommend making backupchild.pl into a launchd job that your
> main job kicks off by running `launchctl start`. If you need multiple
> instances of the job, you can create them on the fly with `launchctl
> submit`, and launchd will take care of the process management.
> --
> Damien Sorresso
> BSD Engineering
> Apple Inc.
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 2425 bytes
> Desc: not available
> URL: <
> http://lists.macosforge.org/pipermail/launchd-dev/attachments/20090728/d654ef3c/attachment-0001.bin
> >
>
> ------------------------------
>
> _______________________________________________
> launchd-dev mailing list
> launchd-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
>
>
> End of launchd-dev Digest, Vol 25, Issue 7
> ******************************************
>
--
"lalalalala! it's not broken because I can use it"
http://linux.slashdot.org/comments.pl?sid=194281&threshold=1&commentsort=0&mode=thread&cid=15927703
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/launchd-dev/attachments/20090731/f149f8c2/attachment.html>
More information about the launchd-dev
mailing list