[17864] in Perl-Users-Digest
Perl-Users Digest, Issue: 24 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Jan 9 09:26:05 2001
Date: Tue, 9 Jan 2001 06:25:17 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <979050316-v10-i24@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Tue, 9 Jan 2001 Volume: 10 Number: 24
Today's topics:
perl socket programming questions <wieland@netvertising.ch>
Re: perl socket programming questions (Anno Siegel)
Re: perl socket programming questions (Abigail)
Re: perl socket programming questions (Martien Verbruggen)
Re: Perl with MS Access <mlaw@talk21.comNOSPAM>
pl/sql stored procedure with Table input jheinnic@my-deja.com
pl/sql stored procedure with Table input jheinnic@lycos.com
regular expression for csv <news@#nospam#althepal.com>
Re: send on a socket returns "operation not supported" <geoff-at-farmline-dot-com@127.0.0.1>
Re: send on a socket returns "operation not supported" <geoff-at-farmline-dot-com@127.0.0.1>
Re: send on a socket returns "operation not supported" (Martien Verbruggen)
Re: send on a socket returns "operation not supported" <geoff-at-farmline-dot-com@127.0.0.1>
Re: send on a socket returns "operation not supported" (Martien Verbruggen)
Re: Sending SIGTERM to child process (Anno Siegel)
Re: Sending SIGTERM to child process (Martien Verbruggen)
Re: Shall use a reference instead? <iltzu@sci.invalid>
Re: Stopping users from exploiting Perl 'interpreter' o <cingram-at-pjocs-dot-demon-dot-co-dot-uk>
tcp client/server question... jfn@dassic.com
Re: trying to count words - not working (Martien Verbruggen)
Re: trying to count words - not working <rick.delaney@home.com>
Watched folders <rjames@higgsgroup.co.uk>
Re: What do you call the => operator? <bart.lateur@skynet.be>
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 09 Jan 2001 09:59:22 +0100
From: Nico Wieland <wieland@netvertising.ch>
Subject: perl socket programming questions
Message-Id: <3A5AD2EA.308578D1@netvertising.ch>
hi list
we need some good reference/information about perl socket programming.
and some help from experienced perl network programmers would be
appreciated very much indeed.
we're trying to write a socket that allows us to manipulate web content
dynamically and interactively via flash. also, the clients itself can
communicate with each other. it basically works, but some things are not
clear.... we expect maybe 2000-5000 users at the same time, maybe more.
a) how many clients can connect to a socket at the same time? does it
matter if solaris 7 or linux?
b) to fork or not to fork?
c) is perl a good solution anyway for such a job?
d) how to test? especially under load?
e) security problems? the socket has to run as root, how can we avoid
malicious people taking it over and executing code with uid 0?
any help would be much appreciated.
regards,
Nico
------------------------------
Date: 9 Jan 2001 12:20:38 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: perl socket programming questions
Message-Id: <93evmm$vk$1@mamenchi.zrz.TU-Berlin.DE>
Nico Wieland <wieland@netvertising.ch> wrote in comp.lang.perl.misc:
>hi list
>
>we need some good reference/information about perl socket programming.
>and some help from experienced perl network programmers would be
>appreciated very much indeed.
>
>we're trying to write a socket that allows us to manipulate web content
>dynamically and interactively via flash. also, the clients itself can
>communicate with each other. it basically works, but some things are not
>clear.... we expect maybe 2000-5000 users at the same time, maybe more.
>a) how many clients can connect to a socket at the same time? does it
>matter if solaris 7 or linux?
The socket itself is unlikely to be the bottleneck. You will have
to process each connection, and that will limit the amount of
connections you can serve. The number will depend on the amount
of processing that has to be done and your choice of hardware and
software.
>b) to fork or not to fork?
Fork 5000 processes? Well, I guess there are machines you can do
that on. Normally a combined approach would probably be used for
that kind of load: Fork (probably pre-fork) a reasonable number
of processes, but let each one handle a number of connections
via select().
>c) is perl a good solution anyway for such a job?
Probably not. Perl isn't particularly fast, and it tends to use
much more memory for a given problem than a compiled language.
>d) how to test? especially under load?
That is a very general question. I pass.
>e) security problems? the socket has to run as root, how can we avoid
>malicious people taking it over and executing code with uid 0?
If you run the server as root, you have massive security problems.
Try to isolate the parts that need root privileges and run only those
as root. Otherwise, see reply to d).
Anno
------------------------------
Date: 9 Jan 2001 12:44:24 GMT
From: abigail@foad.org (Abigail)
Subject: Re: perl socket programming questions
Message-Id: <slrn95m1t8.ioc.abigail@tsathoggua.rlyeh.net>
Anno Siegel (anno4000@lublin.zrz.tu-berlin.de) wrote on MMDCLXXXVIII
September MCMXCIII in <URL:news:93evmm$vk$1@mamenchi.zrz.TU-Berlin.DE>:
"" Nico Wieland <wieland@netvertising.ch> wrote in comp.lang.perl.misc:
""
"" >e) security problems? the socket has to run as root, how can we avoid
"" >malicious people taking it over and executing code with uid 0?
""
"" If you run the server as root, you have massive security problems.
Well, if you want to listen to ports with numbers < 1024, you better be
running as root.
"" Try to isolate the parts that need root privileges and run only those
"" as root. Otherwise, see reply to d).
Which is typically done as starting as root, do what you need to do
(bind to port, opening files, etc), and then drop priviledges before
accepting connections.
Abigail
--
perl -e '* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
/ / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /
% % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % %;
BEGIN {% % = ($ _ = " " => print "Just Another Perl Hacker\n")}'
------------------------------
Date: Wed, 10 Jan 2001 00:12:00 +1100
From: mgjv@tradingpost.com.au (Martien Verbruggen)
Subject: Re: perl socket programming questions
Message-Id: <slrn95m3gv.f4u.mgjv@martien.heliotrope.home>
[Non-exisisting group comp.lang.misc removed]
On Tue, 09 Jan 2001 09:59:22 +0100,
Nico Wieland <wieland@netvertising.ch> wrote:
> hi list
Newsgroup. Not list.
> we need some good reference/information about perl socket programming.
> and some help from experienced perl network programmers would be
> appreciated very much indeed.
$ man Socket
$ man IO::Socket
$ man perlipc
> we're trying to write a socket that allows us to manipulate web content
> dynamically and interactively via flash. also, the clients itself can
> communicate with each other. it basically works, but some things are not
> clear.... we expect maybe 2000-5000 users at the same time, maybe more.
I'm sorry, but the above really doesn't make any sense to me. But I
don't think it's important. And saying things like '2000-5000' users at
the same time is almost meaningless. You really need to specify what
that means.
> a) how many clients can connect to a socket at the same time? does it
> matter if solaris 7 or linux?
I doubt very much that you'll ever really have to worry about that. By
the time you do, you probably need to upgrade your hardware to something
massive.
> b) to fork or not to fork?
fork, thread, not much difference. But if you want to handle multiple
connections at once, you'll have to do something like it. of course, you
could consider writing a single-threaded non-forking server that uses a
select loop. In many cases that is actually a good thing.
However, you don't give us any information to go on.
Besides, both of the above questions are much better asked in a unix
porgamming group.
> c) is perl a good solution anyway for such a job?
It could be. Sure. Maybe. Maybe not. Probably. Pick any.
> d) how to test? especially under load?
You write a server. You start it up. You get sufficient hardware to
emulate 2000 -5000 simultaneous users. You write client that emulate
these users 9including netwrok connection speed and lag times). You run
the client, gather the data, and see what it says.
> e) security problems? the socket has to run as root, how can we avoid
> malicious people taking it over and executing code with uid 0?
DOn't run it as root. if you have to bind to a port lower than 1024,
start as root, and setuid to a non-privileged user.
> any help would be much appreciated.
The first thing, and I don't mean this unkindly, you need to do is to
hire someone who knows something about Unix. Hire a programmer,
preferably someone with a history as a senior programmer, and system's
design background. It is pretty clear from your questions that you don't
really know what the issues involved are. You need to get someone
involved who can ask the right questions first. Then you go on to think
about whether or not you should have a forking server, and whether it
needs to run as root. You're not even close to the point where you need
to worry about that.
The second thing, after the software has been designed, is to get
someone in who knows your OS. maybe in your case you need to engage Sun
professional services. They will be able to advice you on system and OS
limitations. Maybe buy Adrian Cockroft's books.
Then, and now you're much further down the road, and you've talked to many
clueful people who've been able to educate you about this, you get the
programmer to write the software, and you buy or lease a load of
hardware to run your tests on (and no, you can't really scale these
things by doing 10% load tests). After the tests you pay someone money
to install the hardware that you need, and you run it.
Now, the only mention of Perl in this whole thing is the question
whether it could be used for this. The answer to that is yes, no and
maybe. The question should not be asked yet. This makes the whole post
really offtopic.
Take my advice, and get some consultant in who can tell you how to
approach this problem before you make any decisions. Most of the above
is common to any largish software project. The question of language
comes just before you start writing the software, and is dependent on
much more than just the vaguaries you provided.
Martien
--
Martien Verbruggen | The problem with sharks is that they
Interactive Media Division | are too large to get to the shallow
Commercial Dynamics Pty. Ltd. | end of the gene pool. -- Scott R.
NSW, Australia | Godin
------------------------------
Date: Tue, 9 Jan 2001 08:41:23 -0000
From: "Matt L." <mlaw@talk21.comNOSPAM>
Subject: Re: Perl with MS Access
Message-Id: <F6A66.25229$nu5.136182@NewsReader>
If you don't need to do anything with relationships or anything more
complicated than reading or inserting a little data here and there, a flat
file database using the DBD CSV module would work OK
Malcolm Dew-Jones <yf110@vtn1.victoria.tc.ca> wrote in message
news:3a59ff95@news.victoria.tc.ca...
> : In article <38C462C3.AA65602E@npv.com>,
> : Ruben Fagundo <ruben@npv.com> writes:
> : > I would like to write an application on a Linux box in Perl that would
> : > open a Microsoft Access Database (.mdb) and reads certain information
> : > from it, much like one opens and reads any file.
> : >
>
> If you're only reading the data, why not ask access to save the database
> in another format, like a flat file or a dbase database ( dbase= Xbase in
> DBD). A visual basic routine on the access could automate the process -
> simply press a button and save a copy for the linux.
>
>
------------------------------
Date: Tue, 09 Jan 2001 09:30:25 GMT
From: jheinnic@my-deja.com
Subject: pl/sql stored procedure with Table input
Message-Id: <93elni$aoc$1@nnrp1.deja.com>
I have an Oracle PL/SQL Stored Procedure that I need to call from a
perl environment using DBI. I've already got several working examples
in my scripts using non-Table data types, but this one eludes me.
Here's the header file for the package in question:
CREATE OR REPLACE PACKAGE coe AS
TYPE TableMessageID
IS TABLE OF coe_history.message_identifier%TYPE
INDEX BY BINARY_INTEGER;
PROCEDURE deleteUidlList(
t IN TableMessageID,
user IN coe_history.username%TYPE,
coe_id IN
coe_history.coe_configuration_id%TYPE
);
END coe;
In my perl code I have the following currently:
$sth->prepare( q{
BEGIN
deleteUidlList( ?, ?, ? );
END; } );
my( $t ) = [ 'foo', 'bar' ];
my( $user ) = 'joe';
my( $coe_id ) = 500;
$sth->execute( $t, $user, $coe_id );
This returns the following, indicating that a mere array reference
is not adequate to bind to a PL/SQL table type:
Can't bind a reference (ARRAY(0x6065d0))
Anyone have any ideas as to what I can do differently or if PL/SQL
table types are even supported as an bind parameter under DBD::Oracle?
I'm told that they can be used in the ProC environment, but I don't have
the luxury of being to change the implementation language I've been
assigned just to satisfy this requirement. If this is not supported by
DBD::Oracle we'll have to re-write some PL/SQL code, which could be
done, but would be rather time consuming.
Desperate for assistance,
John Heinnickel
Sent via Deja.com
http://www.deja.com/
------------------------------
Date: Tue, 09 Jan 2001 09:30:43 GMT
From: jheinnic@lycos.com
Subject: pl/sql stored procedure with Table input
Message-Id: <93elo3$aof$1@nnrp1.deja.com>
I have an Oracle PL/SQL Stored Procedure that I need to call from a
perl environment using DBI. I've already got several working examples
in my scripts using non-Table data types, but this one eludes me.
Here's the header file for the package in question:
CREATE OR REPLACE PACKAGE coe AS
TYPE TableMessageID
IS TABLE OF coe_history.message_identifier%TYPE
INDEX BY BINARY_INTEGER;
PROCEDURE deleteUidlList(
t IN TableMessageID,
user IN coe_history.username%TYPE,
coe_id IN
coe_history.coe_configuration_id%TYPE
);
END coe;
In my perl code I have the following currently:
$sth->prepare( q{
BEGIN
deleteUidlList( ?, ?, ? );
END; } );
my( $t ) = [ 'foo', 'bar' ];
my( $user ) = 'joe';
my( $coe_id ) = 500;
$sth->execute( $t, $user, $coe_id );
This returns the following, indicating that a mere array reference
is not adequate to bind to a PL/SQL table type:
Can't bind a reference (ARRAY(0x6065d0))
Anyone have any ideas as to what I can do differently or if PL/SQL
table types are even supported as an bind parameter under DBD::Oracle?
I'm told that they can be used in the ProC environment, but I don't have
the luxury of being to change the implementation language I've been
assigned just to satisfy this requirement. If this is not supported by
DBD::Oracle we'll have to re-write some PL/SQL code, which could be
done, but would be rather time consuming.
Desperate for assistance,
John Heinnickel
Sent via Deja.com
http://www.deja.com/
------------------------------
Date: Tue, 09 Jan 2001 13:30:21 GMT
From: Alex Hart <news@#nospam#althepal.com>
Subject: regular expression for csv
Message-Id: <NnE66.9441$bR3.1860360@typhoon2.ba-dsg.net>
I know that there are modules out there to do comma separated values,
but how about this regular expresssion for separating values. I am
working with email addresses, so values can be partly in quotes, and
partly outside of quotes.
Can anyone find data that will break this regular expression. I'm
willing to assume that there will be only one set of quotes in the email
("first""name"<first@name.com> is invalid).
$recips is a string with a series of email addresses
@to should be the string broken at the commas
$recips = qq( test@test.com,"Dan"<dan@rob.com>,"Someone
else",Joe<joe@pete.com> );
while ($recips =~ m{([^,\"]*(?:".*?")?[^,]*),?}gx) {
push(@to, $+) if $+;
}
- Alex Hart
------------------------------
Date: Tue, 9 Jan 2001 09:04:54 -0000
From: "Geoff Winkless" <geoff-at-farmline-dot-com@127.0.0.1>
Subject: Re: send on a socket returns "operation not supported" but recv works?
Message-Id: <93ek56$pcc$1@soap.pipex.net>
"Geoff Winkless" <geoff-at-farmline-dot-com@127.0.0.1> wrote in message
news:93ckg4$nop$1@soap.pipex.net...
: Programming using unix sockets, it's my first attempt at building a server
: for perl.
:
: I have a C client which is connect()ing and send()ing data to the socket
: correctly - and the perl script is recv()ing that data fine - however when
: it tries to send back a confirmation that the data is ok it fails with
: "operation not supported".
No-one?
Guess I'll just have to keep banging my head against this tall hard red
thing then.
:)
Geoff
------------------------------
Date: Tue, 9 Jan 2001 09:51:14 -0000
From: "Geoff Winkless" <geoff-at-farmline-dot-com@127.0.0.1>
Subject: Re: send on a socket returns "operation not supported" but recv works?
Message-Id: <93emru$r31$1@soap.pipex.net>
"Geoff Winkless" <geoff-at-farmline-dot-com@127.0.0.1> wrote in message
news:93ek56$pcc$1@soap.pipex.net...
: Guess I'll just have to keep banging my head against this tall hard red
: thing then.
*sigh* Worked it out.
This code:
$ret=send Client, $yval, 1, 0;
is of course incorrect - in perl there's no need to specify the length of
the buffer, so what I was actually doing in this case was doing a sendto to
socket 0, with flags 1.
It should be
$ret=send Client, $yval, 0;
Geoff
------------------------------
Date: Tue, 9 Jan 2001 20:57:00 +1100
From: mgjv@tradingpost.com.au (Martien Verbruggen)
Subject: Re: send on a socket returns "operation not supported" but recv works?
Message-Id: <slrn95lo3c.f4u.mgjv@martien.heliotrope.home>
On Tue, 9 Jan 2001 09:04:54 -0000,
Geoff Winkless <geoff-at-farmline-dot-com@127.0.0.1> wrote:
> "Geoff Winkless" <geoff-at-farmline-dot-com@127.0.0.1> wrote in message
> news:93ckg4$nop$1@soap.pipex.net...
>: Programming using unix sockets, it's my first attempt at building a server
>: for perl.
>:
>: I have a C client which is connect()ing and send()ing data to the socket
>: correctly - and the perl script is recv()ing that data fine - however when
>: it tries to send back a confirmation that the data is ok it fails with
>: "operation not supported".
>
> No-one?
>
> Guess I'll just have to keep banging my head against this tall hard red
> thing then.
I suspect the main reason no-one has yet looked at this is that you
don't provide enough information. You don't tell us which platform this
runs on, whether it runs as a privileged or non-privileged user, and you
don't provide a full program (or set of programs) that people can run to
see what goes on. Furthermore, the code you supply is incomplete, and
uses (at least) two key variables whose value you don't show anywhere.
You also fail to give us any information about the sort of data that you
are sending back and forth.
There's simply too much to guess left for anyone to make any decent
guess about what might go on.
I'm sure that many people here would be perfectly willing to have a look
at it, myself included, if you provided some more information. Maybe you
need to include the C client (or a very minimal version of it) as well.
Most people here who would be able to shine a light on this question
probably have a C compiler.
Martien
--
Martien Verbruggen | Since light travels faster than
Interactive Media Division | sound, isn't that why some people
Commercial Dynamics Pty. Ltd. | appear bright until you hear them
NSW, Australia | speak?
------------------------------
Date: Tue, 9 Jan 2001 11:29:11 -0000
From: "Geoff Winkless" <geoff-at-farmline-dot-com@127.0.0.1>
Subject: Re: send on a socket returns "operation not supported" but recv works?
Message-Id: <93esjj$103$1@soap.pipex.net>
"Martien Verbruggen" <mgjv@tradingpost.com.au> wrote in message
news:slrn95lo3c.f4u.mgjv@martien.heliotrope.home...
: I suspect the main reason no-one has yet looked at this is that you
: don't provide enough information. You don't tell us which platform this
: runs on,
: Furthermore, the code you supply is incomplete, and
: uses (at least) two key variables whose value you don't show anywhere.
: You also fail to give us any information about the sort of data that you
: are sending back and forth.
The thing is that all of the information I missed out was stuff that was
irrelevant - the socket was already working in one direction so it was
pretty obvious that $name wasn't the problem, the type of data was obvious
from the information in the code.
: There's simply too much to guess left for anyone to make any decent
: guess about what might go on.
I'm sorry but I disagree.
Having said that, I wasn't knocking the group for not replying - you're
probably right in that it would have been easier if I'd supplied full code
for both client and server, but I haven't got "simple" code to do that, and
I was really only asking in case it was something obvious that would jump
out at anyone who actually knew what they were doing (and considering the
actual solution, a syntactic error, I was probably right). I didn't intend
for anyone to spend hours on it, because it was always going to be a stupid
mistake on my part.
Geoff
------------------------------
Date: Tue, 9 Jan 2001 23:24:18 +1100
From: mgjv@tradingpost.com.au (Martien Verbruggen)
Subject: Re: send on a socket returns "operation not supported" but recv works?
Message-Id: <slrn95m0ni.f4u.mgjv@martien.heliotrope.home>
[This isn't just directed to you, but is also a general explanation of
why your post was a bad example of a post that is likely to find a
solution on Usenet.]
On Tue, 9 Jan 2001 11:29:11 -0000,
Geoff Winkless <geoff-at-farmline-dot-com@127.0.0.1> wrote:
> "Martien Verbruggen" <mgjv@tradingpost.com.au> wrote in message
> news:slrn95lo3c.f4u.mgjv@martien.heliotrope.home...
>: I suspect the main reason no-one has yet looked at this is that you
>: don't provide enough information. You don't tell us which platform this
>: runs on,
>: Furthermore, the code you supply is incomplete, and
>: uses (at least) two key variables whose value you don't show anywhere.
>: You also fail to give us any information about the sort of data that you
>: are sending back and forth.
>
> The thing is that all of the information I missed out was stuff that was
> irrelevant - the socket was already working in one direction so it was
> pretty obvious that $name wasn't the problem, the type of data was obvious
> from the information in the code.
>
>: There's simply too much to guess left for anyone to make any decent
>: guess about what might go on.
>
> I'm sorry but I disagree.
>
> Having said that, I wasn't knocking the group for not replying - you're
> probably right in that it would have been easier if I'd supplied full code
I wasn't saying you were knocking the group. I was trying to explain why
I believed you didn't actually get a response to an otherwise
interesting looking, and potentially challenging problem. I started
looking at that with that idea in mind. However, read on...
> for both client and server, but I haven't got "simple" code to do that, and
> I was really only asking in case it was something obvious that would jump
> out at anyone who actually knew what they were doing (and considering the
> actual solution, a syntactic error, I was probably right). I didn't intend
> for anyone to spend hours on it, because it was always going to be a stupid
> mistake on my part.
That's disagreeing after finding the solution, and that's easy. The point
isn't that you supplied enough information to find the particular
problem that there was, but that you didn't supply enough information to
interest anyone, or maybe I should just say me, in digging deep enough
to even find out that error.
What happened was that I saw your post the first time around. I read a
few lines, and already started wondering: What is this running on? What
sort of data is going back and forth? What sort of netwrok is there
ebetween the client and server.
I decide to read on, and come to the socket line. I see socket(), and
,my mind start thinking ports, IP addresses, firewalls, packet filters.
When I read a bit further, I see the unlink line, and my eye jumps back
to the socket line. A unix domain socket, I think. Now how much trouble
would it have been to mention that in the intro... I am a bit annoyed. I
get back to the unlink line. What the fsck is $name, I think. Oh well..
next line... Another undeclared and unexplained variable.
And this is where I give up.
My point wasn't entirely that you didn't provide enough context for the
problem to be solved, because looking at it _after the fact_ proves that
it was there. In fact, you provided much too much context. Had you
posted just that one line, we'd all have told you what was wrong. But
that is _after_ the fact.
My main point is that most people here probably feel their time is
better spent on another post, than on one that after a paragraph of text
and a few lines of code already has thrown up so many unanswered
questions.
That is what I meant. and I think you know that.
The onus is not on us to extract meaning from your posts. It is not our
task to wade through reams of code to find a possible type. If we at
least could run the code, many would have been happy to give it at least
a try. But dry-reading code that is partial, like yours is, and that
leaves crucial things, or things that _look_ crucial, unexplained, is
often just too much work for many people here.
It is your job to convince us to read to the end of your post, and to
make it clear what exactly is happening, and to give us as many
parameters of the problem as look relevant at the time. The OS, type of
socket (even though the code showed that), contents of variables, all
belong to that.
I keep saying 'we' but I should really say 'I'. However, the lack of
response and knowing many of the people here, gives me a fairly
confident feeling that I wasn't the only one who did this.
I don't want to nag, but things like these happen too often here. Posts
go unanswered, or get uninformed of incomplete or wrong answers, because
people often don't create the right question with the appropriate amount
of information. People who could, or otherwise would, respond are put
off by this, and stop reading halfway through, pressing the spacebar for
the next article. If a post doesn't look like it can be answered people
won't study it. They'll skim it, and go on, _unless_ it looks
interesting and complete.
Oh well.
Please, note the followups.
Martien
--
Martien Verbruggen |
Interactive Media Division | Failure is not an option. It comes
Commercial Dynamics Pty. Ltd. | bundled with your Microsoft product.
NSW, Australia |
------------------------------
Date: 9 Jan 2001 11:19:01 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Sending SIGTERM to child process
Message-Id: <93es35$o8g$2@mamenchi.zrz.TU-Berlin.DE>
Nick Wilson <nickw@ot.com.au> wrote in comp.lang.perl.misc:
>I currently have a process (call it starter) which creates another process,
>(say called child1), and this child 1 has some signal handlers set up for
>it, ie
>
>sub handler {
>
> # kill all immediate children (gracefully)
> @children = `ps -f`;
> foreach $child (@children) {
> $child =~ m/([0-9]+) +$$./ && kill 15, $1;
> }
>}
>
>$SIG{TERM} = \&handler;
>
>My problem lies in the starter function, when it tries to kill off the child
>after a timeout, the following call doesn't work
>
>kill 15, $pid
Define "doesn't work". What do you expect to happen, what happens
instead? Also, you don't show where $pid gets its value. Are you
sure it contains the pid you want to signal?
From the situation as I (not quite clearly) see it, I'd expect
the kid process to kill all of *it's* children and keep on running
on a TERM signal. If you want the kid to die too, you will have
to do that in the handler.
Anno
------------------------------
Date: Tue, 9 Jan 2001 23:07:38 +1100
From: mgjv@tradingpost.com.au (Martien Verbruggen)
Subject: Re: Sending SIGTERM to child process
Message-Id: <slrn95lvo9.f4u.mgjv@martien.heliotrope.home>
On Tue, 9 Jan 2001 17:36:07 +1100,
Nick Wilson <nickw@ot.com.au> wrote:
> I currently have a process (call it starter) which creates another
> process, (say called child1), and this child 1 has some signal
> handlers set up for it, ie
>
> sub handler {
>
> # kill all immediate children (gracefully)
> @children = `ps -f`;
> foreach $child (@children) {
> $child =~ m/([0-9]+) +$$./ && kill 15, $1;
> }
> }
This is an odd definition of gracefully... If they're immediate
children, you should already have the pids. spawning an external
program to gather pids that you already should have is, IMO, a bit
wasteful. How are you starting your children that you can't get their
pids? system()? backticks? fork (plus maybe exec)? pipe opens? This is
not an idle question, because the answer to that might also shed a
littlebit more light on the rest of this.
Besides that... Do you know you're not supposed to do all that work in
signal handlers? They're unreliable at best, and calling all these
external functions, and doing memory allocation in them is not a good
idea, IMO.
> $SIG{TERM} = \&handler;
>
> My problem lies in the starter function, when it tries to kill off the
> child after a timeout, the following call doesn't work
How does this function look?
> kill 15, $pid
>
> A couple of things, I'm sure that the handler works as I can do a kill
> -15 child_ps_id which works fine. And I'm sure that 15 is set to TERM
> for my setup.
TERM is 15 in most places. In fact, in all places that I know of, but
that's not everything there is. But, you don't have to rely on that. The
POSIX module includes constants for these signals.
$ man POSIX
[snip]
SIGNAL
Constants
SA_NOCLDSTOP SA_NOCLDWAIT SA_NODEFER SA_ONSTACK
SA_RESETHAND SA_RESTART SA_SIGINFO SIGABRT SIGALRM
SIGCHLD SIGCONT SIGFPE SIGHUP SIGILL SIGINT
SIGKILL SIGPIPE SIGQUIT SIGSEGV SIGSTOP SIGTERM
SIGTSTP SIGTTIN SIGTTOU SIGUSR1 SIGUSR2 SIG_BLOCK
SIG_DFL SIG_ERR SIG_IGN SIG_SETMASK SIG_UNBLOCK
[snip]
So all you'd need to do is
use POSIX qw(:signal_h);
# ...
kill SIGTERM, $pid or warn "Couldn't send signal to $pid: $!";
And of course, you can just do:
kill TERM, $pid;
(
Actually, in this particular case I do like the => as a separator:
kill TERM => $pid;
)
> So why doesn't this term signal get trapped ?
Are you sure it doesn't? Could you maybe submit a small example
program, that runs standalone and that displays the problem? That way
we can run it too, and/or point out what to do about it.
Is there any reason that you don't use alarm() and a handler for that in
this process? I fail to see why you have the extra indirection of that
intermediate child in there. Why doesn't that intermediate child do the
timeout itself?
Martien
--
Martien Verbruggen |
Interactive Media Division | Hi, Dave here, what's the root
Commercial Dynamics Pty. Ltd. | password?
NSW, Australia |
------------------------------
Date: 9 Jan 2001 10:11:28 GMT
From: Ilmari Karonen <iltzu@sci.invalid>
Subject: Re: Shall use a reference instead?
Message-Id: <979033100.21695@itz.pp.sci.fi>
In article <Ysv66.22281$7f3.1572832@bgtnsc07-news.ops.worldnet.att.net>, Michael Mayo wrote:
>
>This contradicts the statement on p444 and seems to support your view that it
>is possible (but "almost never" done) to access an object without a reference.
>I have no idea how you would do this, though.
The point is that you can only use it _as an object_ through a
reference, since both bless() and method calls require one.
One can, however, access the object internals directly:
{ package Foobar;
use Data::Dumper;
sub ident {
# Stringifying a reference produces the type and address
# of the thingy it refers to.
print "I am $_[0], accessed via ${\\$_[0]}.\n";
}
sub dump {
print Dumper $_[0];
}
}
my @foo = qw/one two three/; # here we have a nice lexical array
my $foobar = \@foo; # and we take a reference to that array..
bless $foobar, 'Foobar'; # ..and bless the array through the ref
$foobar->ident(); # see, it's an object
$foobar->dump(); # see, its content hasn't changed
push @foo, 'four'; # let's change it! look mom, no refs!
$foobar->ident(); # see, still the same object
$foobar->dump(); # but the content has changed!
my %bar = (left => 'right'); # now let's take another thingy..
bless \%bar, 'Foobar'; # ..and bless it (yes, we can do this)
$foobar = \%bar; # we'll reuse the old reference..
$foobar->ident(); # ..so that it points to the new object..
$foobar->dump(); # ..with a completely new content
${\\%bar}->ident(); # we don't even need an explicit ref
${\\@foo}->ident(); # even @foo is still an object
--
Ilmari Karonen -- http://www.sci.fi/~iltzu/
"Get real! This is a discussion group, not a helpdesk. You post
something, we discuss its implications. If the discussion happens to
answer a question you've asked, that's incidental." -- nobull in clpm
------------------------------
Date: Tue, 9 Jan 2001 13:23:29 -0000
From: "Clyde Ingram" <cingram-at-pjocs-dot-demon-dot-co-dot-uk>
Subject: Re: Stopping users from exploiting Perl 'interpreter' on NT
Message-Id: <979046626.3213.0.nnrp-08.9e98e5bc@news.demon.co.uk>
Jerome O'Neil <jerome@activeindexing.com> wrote in message
news:ctt66.1043$NN3.369700@news.uswest.net...
> "Clyde Ingram" <clyde@NOSPAMgetofftheline.freeserve.co.uk> elucidates:
>
> > Can anyone suggest how to prevent NT users from producing their own
working
> > Perl programs?
>
> Yes. You write policy that says "Thou shalt not ... " and if they do,
> you fire them.
>
> I'm unsure as to why you would hire someone you don't trust in the
> first place, but I guess thats your issue.
Oops, you miss the point: we do not hire people we do not trust, but we have
to secure the system as best we can against unscrupulous employees of our
customer. Clearly we cannot control our customer's employment policy: you
are wrong to guess that's our issue.
IOW, the system "users" are not my colleagues, they work for the company
that buys from my company.
Geddit?
Regards,
Clyde
------------------------------
Date: Tue, 09 Jan 2001 09:50:11 GMT
From: jfn@dassic.com
Subject: tcp client/server question...
Message-Id: <93emsi$bh4$1@nnrp1.deja.com>
Hi!
I'm trying to setup a solution where alot of client scripts send in data
to a central server script (that connects to a database).
I've started out with the examples found at :
http://velocity.activestate.com/docs/ActivePerl/lib/Pod/perlipc.html#soc
kets: client/server communication
...using the client and the multithreaded (forked actually) server.
I have two problems :
One is that the stuff sent from the server script somehow doesn't get
flushed, or doesn't get sent unless I do a system call (like exec
'/usr/bin/sleep 0') in the end.
I have no idea why.
Second problem is that I really want the example scripts to do the
opposite of what they do by default.
I want the client script to send data to the server script, but if I
write something to the socket at the client side, I don't get anything
on the server side if I read & print from STDIN (which is opened as a
TCP connection to the client).
Anyone with some experience they want to share ?
l8r/Jspr
Sent via Deja.com
http://www.deja.com/
------------------------------
Date: Tue, 9 Jan 2001 20:29:20 +1100
From: mgjv@tradingpost.com.au (Martien Verbruggen)
Subject: Re: trying to count words - not working
Message-Id: <slrn95lmfg.f4u.mgjv@martien.heliotrope.home>
On 08 Jan 2001 17:22:03 -0500,
Joe Schaefer <joe+usenet@sunstarsys.com> wrote:
> cberry@cinenet.net (Craig Berry) writes:
>
>> This is my prefered solution in terms of elegance of expression. Others
>> object that it needlessly builds and throws away an intermediate list;
>
> [...]
>
>> $leftcnt = 0; $leftcnt++ while $body =~ m/<left>/g;
>>
>> is good enough.
>
> Where do you see a list? I see m//g in the scalar context
> provided by while().
I think Bart was talking about the code that Ala submitted, and that he
quoted, but you snipped:
$leftcnt = () = $body =~ /<left>/g;
That does build a list, and then discards it.
Martien
--
Martien Verbruggen |
Interactive Media Division | I took an IQ test and the results
Commercial Dynamics Pty. Ltd. | were negative.
NSW, Australia |
------------------------------
Date: Tue, 09 Jan 2001 13:51:15 GMT
From: Rick Delaney <rick.delaney@home.com>
Subject: Re: trying to count words - not working
Message-Id: <3A5B1B26.20202B16@home.com>
Martien Verbruggen wrote:
>
> Joe Schaefer <joe+usenet@sunstarsys.com> wrote:
> > cberry@cinenet.net (Craig Berry) writes:
>
> I think Bart was talking about the code that Ala submitted,
Bart?
--
Rick Delaney
rick.delaney@home.com
------------------------------
Date: Tue, 09 Jan 2001 11:05:59 +0000
From: Rob James <rjames@higgsgroup.co.uk>
Subject: Watched folders
Message-Id: <3A5AF096.7B95C14F@higgsgroup.co.uk>
Is there a Unix equivalent to Win32::ChangeNotify? Thanks.
------------------------------
Date: Tue, 09 Jan 2001 14:02:28 GMT
From: Bart Lateur <bart.lateur@skynet.be>
Subject: Re: What do you call the => operator?
Message-Id: <rg6m5tc4ist7qdpj2s31r43s3l4t9ehtnm@4ax.com>
Jerome O'Neil wrote:
>I think it's real name is Earl.
???
--
Bart.
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
| NOTE: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 24
*************************************
