Bug 10887 - lvs going into defunct
lvs going into defunct
Status: CLOSED DUPLICATE of bug 11226
Product: Red Hat Linux
Classification: Retired
Component: piranha (Show other bugs)
6.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-04-17 23:57 EDT by 5string
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-05-04 17:03:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
this is the core dump produced when I start Piranha (136.04 KB, application/octet-stream)
2000-04-18 00:00 EDT, 5string
no flags Details

  None (edit)
Description Red Hat Bugzilla 2000-04-17 23:57:36 EDT
Hello,

When I start piranha using this config file it goes into defunct mode, and
I get a core dump.

Here is my config. How can I email the core dump? Piranha in my opinion is
not stable at all. It works when it feels like it. I can stop pulse start
it up again and all my virtual services get killed. I sometimes have to
reboot the machine to refresh all the buffers....

The Config:

primary = 172.10.20.30
service = lvs
rsh_command = rsh
backup = 0.0.0.0
heartbeat = 1
heartbeat_port = 539
keepalive = 6
deadtime = 18
network = nat
nat_router = 192.168.1.254 eth1:0
virtual vs1 {
     active = 1
     address = 172.10.20.254 eth0:1
     port = 443
     persistent = 1800
     load_monitor = ruptime
     scheduler = wlc
     protocol = tcp
     persistent = 1800
     timeout = 60
     reentry = 5
     server rs1 {
         address = 192.168.1.10
         active = 1
         weight = 100
     }
}
virtual vs2 {
     active = 1
     address = 172.10.20.254 eth0:1
     port = 25
     load_monitor = ruptime
     scheduler = wlc
     protocol = tcp
     timeout = 6
     reentry = 15
     server rs1 {
         address = 192.168.1.12
         active = 1
         weight = 100
     }
}
virtual vs3 {
     active = 1
     address = 172.10.20.254 eth0:1
     port = 80
     send = "GET / HTTP/1.0\r\n\r\n"
     expect = "HTTP"
     load_monitor = ruptime
     scheduler = wlc
     protocol = tcp
     timeout = 6
     reentry = 15
     server rs1 {
         address = 192.168.1.10
         active = 1
         weight = 100
     }
     server rs2 {
         address = 192.168.1.25
         active = 1
         weight = 100
     }
}



Thanks, Cono
Comment 1 Red Hat Bugzilla 2000-04-18 00:00:59 EDT
Created attachment 205 [details]
this is the core dump produced when I start Piranha
Comment 2 Red Hat Bugzilla 2000-04-18 11:04:59 EDT
My attempts to read your core dump file appear to fail. Did you
indicate "binary file" when you attached it?

I have not seen anything like extreme behaviors you describe. I
can tell you that Piranha LVS has existed since 6.0., and has
gone through a lot of testing.

There is no config file syntax checking in piranha, so it is easy
to produce a config file that will result in a core dump if you
edit the file manually instead of using the GUI interface (this
is why Red Hat will not support config files unless they are
created by the GUI). If one of the nanny processes or the lvs
process core dumnped, you'd see a defunc'd process.

I may be wrong, but it doesn't look like your config file was
created by the GUI. You have set the backup IP address to
0.0.0.0, but have no (required) parameter "backup_active = 0".
However I don't see anything else obviously wrong with the file.

Try the following:

1. Run the web GUI, have it load your config file, and go through
   each screen and touch each field to ensure that it gets written
   out correctly, then save the file.

2. Before starting piranha, check that ip_forwarding and defrag are
   set correctly by makeing sure that /proc/sys/net/ipv4/ip_forward
   and ip_always_defrag have "1" in them. If they don't, it means that
   your system startup is not setting these files correctly. Do a
   "echo >/proc/sys/... 1" to each file before starting piranha.

   Also make sure ipchains has been set correctly.

3. Look at /var/log/messages to see WHY a program might exit if it
   did not core dump.

4. If the problem appears to be piranha declaring your functioning
   services as disfunctional, try removing the "send" and "expect"
   strings and  see if that affects the problem.

5. Use ipvsadm to display the status of your real servers while
   piranha is running.

If you are still having problems, we would need to know more.
For example; WHICH program is core dumping. What do your ipchains
entries look like? Can you telnet from the NAT router to your
real server's service port (443 in your case)? If telnet cannot
reach it, then piranha won't be able to either.
Comment 3 Red Hat Bugzilla 2000-04-19 07:00:59 EDT
This bug can cause segfault here is a quick fix.

--- lvs.c.old	Wed Apr 19 03:54:56 2000
+++ lvs.c	Wed Apr 19 03:59:31 2000
@@ -504,7 +504,7 @@

     if (vserver->persistent > 0 ) {
         *arg++ = (char *) "-p";
-        (void) sprintf(*arg++, "%d", vserver->persistent);
+        (void) asprintf(arg++, "%d", vserver->persistent);

         if (vserver->pmask.s_addr) {
             pmask = inet_ntoa(vserver->pmask);
Comment 4 Red Hat Bugzilla 2000-04-19 11:11:59 EDT
Re: mcm@mixadlive.com

This may not be a bug, and may not have anything to do with this specific
bugzilla report. The asprintf function is not a a function that can be used by
piranha, and is not documented in linux. Red Hat cannot recommend this patch at
this time. I am exchanging email with the user, and if the situation changes I
will log the results here.
Comment 5 Red Hat Bugzilla 2000-04-19 11:53:59 EDT
More followup...

After an email exchange, mcm is sending me a config file that can cause a
segfault in his indicated code area. When I receive and test this, I'll post an
update and/or patch. asprintf() is a GNU extention provided in glibc and not
well documented. It can be used if a dependancy on glibc is acceptable. Piranha
has no such dependancy currently.
Comment 6 Red Hat Bugzilla 2000-04-20 11:58:59 EDT
I have followed your advice and used the GUI only to create the lvs.cf file.
Piranha seems to be working fine now except for a few messages I get every hour.
For some reason I'm getting timeouts every so often on all of my real servers.
I also recieved a lvs1 pumpd[268] renewed lease for interface eth0. From the
rotuer, I tried to telnet to the ports like you suggested, I get a connect but
nothing happens after that.

Cono.
Comment 7 Red Hat Bugzilla 2000-04-25 10:43:59 EDT
>Piranha seems to be working fine now except for a few messages I get
>every hour. For some reason I'm getting timeouts every so often on
> all of my real servers.

If you suspect this is a performance issue, you can increase the value
of your virtual service "timeout =" value (be sure to also increase the
reentry timer to a multiple of the timeout value).

>I also recieved a lvs1 pumpd[268] renewed lease for interface eth0.

Hummm.  Sounds like your timeout may be network related rather than
piranha itself.

>I tried to telnet to the ports like you suggested, I get a connect
>but nothing happens after that.

telnetting to port 443 should just connect like you describe.
telnetting to port 25 should display a banner and then appear dead.
Comment 8 Red Hat Bugzilla 2000-04-27 14:27:59 EDT
Note: Even though the original problem was resolved, this bugzilla entry is
remaining open until I examine the vulnerability reported by mcm.
Comment 9 Red Hat Bugzilla 2000-05-04 17:03:59 EDT
*** This bug has been marked as a duplicate of 11226 ***

Note You need to log in before you can comment on or make changes to this bug.