bad processes :((

bad processes :((

Post by Victor Rotano » Wed, 02 Aug 1995 04:00:00



Hello, All!

Does anyone know what to do with processes that frequently do the following:
if (fork()) exit(0); ? How to kill such processes?

Bye!
<vitjok>

--- GoldED 2.51.B1208 Registered to Victor Rotanov
 * Origin: ViCt0r'Z BBS, RiGA, LATViA (2:5100/58)

 
 
 

bad processes :((

Post by Phil Edwar » Thu, 03 Aug 1995 04:00:00




+ Does anyone know what to do with processes that frequently do the following:
+ if (fork()) exit(0); ? How to kill such processes?

The parent process dies, then the child process continues.  What's the
difficulty?  This isn't "bad" as much as it is "completely useless".
The child takes the place of its parent, and picks up where the
parent left off.  Other than a change in PIDs, not much has changed.

The problem arises when something like that is constructed inside or
around a loop, such as "while (1) fork();" (which I don't recommend
you try for fun and giggles).

Maybe I'm misunderstanding your question?

--

http://www.cs.wright.edu/people/students/pedwards/
The gods do not protect fools.  Fools are protected by more capable fools.
                                                              -Larry Niven

 
 
 

bad processes :((

Post by Martin Behla » Fri, 04 Aug 1995 04:00:00


   The parent process dies, then the child process continues.  What's the
   difficulty?  This isn't "bad" as much as it is "completely useless".
   The child takes the place of its parent, and picks up where the
   parent left off.  Other than a change in PIDs, not much has changed.

The "if fork() exit(0)" is not completely useless, since the newly
created process is detached from the controlling terminal. This is
normally used in daemon-processes. This way, you don't have to start
them in the background with "a.out&". They also ignore breaks from
stdin (detached), so have to kill them via "kill <pid>".

Martin

 
 
 

bad processes :((

Post by Phil Edwar » Sat, 05 Aug 1995 04:00:00




+ The "if fork() exit(0)" is not completely useless, since the newly
+ created process is detached from the controlling terminal. This is
+ normally used in daemon-processes. This way, you don't have to start
+ them in the background with "a.out&". They also ignore breaks from
+ stdin (detached), so have to kill them via "kill <pid>".

Ah, I guess that would do it.  The way I learned to detach from the
controlling terminal is with something like:

fd = open("/dev/tty", O_RDWR);
if (fd) {
  ioctl(fd, TIOCNOTTY, (char*)0);
  cloase(fd);

Quote:}

but I suppose either would work in a pinch.

Luck++;
Phil

--

http://www.cs.wright.edu/people/students/pedwards/
The gods do not protect fools.  Fools are protected by more capable fools.
                                                              -Larry Niven

 
 
 

1. Talk refused to talk:(:(:(:(

Hello there people:)...
  I had linux kernel 1.2.8 installed in my system. I have a SLIP/PPP
connection using either dip (for SLIP) or pppd/chat (for PPP).
  Now, Most of my network stuff are working fine without any problem at all
except talk. Talk works fine for local chatting. No problem at all. The
problem is when ever I call out to other machine (using the SLIP/PPP line),
nothing has ever happen. It got as far as Checking invitation stuff. Never
more.
  Just out of curiosity I ran netstate to check the udp connection whenever
I have talk running. Running locally (talk that is) I got output as follow:

Active Internet connections
Proto Recv-Q Send-Q Local Address          Foreign Address        (State)
User
udp        0      0 lucifer.newpaltz.:1328 *:*                    

Which I presumed opened by talk (only one here because the other side hadn't
responded to the call yet).  I also get the same thing whenever I call
someone outside my system to talk. Of course, it never got to the other
system (I was waiting on the other system using telnet for the talk request,
never got there. And I had made sure that mesg was y).

Now when I call *IN* from other system (telnet to another system and run
talk over there to my system), I have (on my system) output as follow:

Active Internet connections
Proto Recv-Q Send-Q Local Address          Foreign Address        (State)
User

And also from netstat -a, I could find talk/ntalk were still listening.
Seems to me the call from outside didn't get through.

Now, since I haven't done anything to configure talk specifically, is there
anything I have to do to make this connection possible. Since I can't talk
to outside nor can I receive talk request from other hosts, I'm under the
assumption that my talk program somehow is not configured properly.

Any configuration file I have to check?
man, faq, howto, etc to refer to this kind of error?
May be replace my talk/ntalk/talkd/ntalkd with something else and where to
find it/them?
Does it depend on something in the kernel that I have to enable during the
compile time?
Wrong version altogether with the kernel?
Is it possible that talk needs long time to make the connection? (None of my
other stuff that I know of behave like this).
May be my inetd is broken?
If so, how do I check for it?
And where to find the latest version of it?

And while I'm at it, what's the latest version of talk?
Where to find it?
Is there a better chatting program that's backward compatible with talk?
Meaning that the program has more features than talk but at the same time
can be used to communicate with other regular talk program whenever the
program is not available on the other host.

--
Send comment and reply to:



2. need to add network driver to installation driver diskette

3. my trashed hard drive. :( :( :(

4. ld problem compiling mozilla

5. bad news :(

6. problem: Gateway2000+EtherPower

7. bad superblock :(

8. Integrating HP Workstations in a Sun 4.1.x NIS Domain

9. Bad inode table... :(

10. Apache 1.3.4 + FreeBSD 3 + DSO = bad :(

11. Duplicate bad blocks pbm:(

12. Bad XF86_SVGA server :( shame on you Linux :)

13. I did a bad thing... :(