Ipropd behavior when disk full?

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Ipropd behavior when disk full?

Henry B. Hotz
I have a situation where ipropd has been growing to 1GB+ and crashing.  
(Obviously the core files are a bit hard to deal with ;-)

It appears that the reason may be circular because the cause appears to  
be the /var partition filling up.  (which causes another core file that  
a cron job tries/fails to copy to /var. . .)

Anyway, is it plausible that ipropd-slave (0.6.3) could have a problem  
when it can't write to the DB which would make it leak memory or  
otherwise grow explosively?  The process size is stable (and only a few  
MB) up until the last minute or so before it dies.

Is the following process trace consistent with that theory?  (I would  
have thought a disk write more likely than a strdup to be the the straw  
that broke the program, but what do I know?)

For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.4' in  
your .dbxrc
Reading ipropd-slave
core file header read successfully
Reading ld.so.1
Reading libcrypto.so.0.9.7
Reading libdb-3.3.so
Reading libdl.so.1
Reading libresolv.so.2
Reading libnsl.so.1
Reading libsocket.so.1
Reading libc.so.1
Reading libmp.so.2
Reading libc_psr.so.1
Reading nss_files.so.1
program terminated by signal SEGV (no mapping at the fault address)
0xfef344e4: strlen+0x0080:      ld       [%o1], %o2
Current function is copy_general_string
dbx: warning: can't find file  
dbx: warning: see `help finding-files'
(dbx) gdb on
(dbx) bt
   [1] strlen(0x0, 0x12c, 0x21bb0, 0x7efefeff, 0x81010100, 0x16), at  
   [2] strdup(0x12c, 0x7531c, 0x4cc, 0xfefbc000, 0x0, 0x4cc), at  
=>[3] copy_general_string(from = 0x7a874, to = 0xffbff424), line 41 in  
   [4] copy_Realm(from = 0x7a874, to = 0xffbff424), line 67 in  
   [5] copy_Principal(from = 0xc, to = 0xffbff418), line 160 in  
   [6] hdb_principal2key(context = 0x7a868, p = 0x7a868, key =  
0xffbff4a0), line 45 in "common.c"
   [7] _hdb_remove(context = 0x7a868, db = 0x7b3c8, entry = 0xffbff518),  
line 138 in "common.c"
   [8] kadm5_log_replay_delete(context = 0x7b078, ver = 1U, len =  
21195526U, sp = 0x581598), line 344 in "log.c"
   [9] main(argc = 0, argv = 0x4cc), line 191 in "ipropd_slave.c"

This specific core file is 1.7 GB.  I can provide more details as  
relevant, but I don't think I can export the whole file.

TIA for any comments.
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[hidden email], or [hidden email]