[Devel] 1.0.0 crash

[Dan Pascu]

On Monday 30 January 2006 16:45, Bogdan-Andrei Iancu wrote:
> Hi,
>
> regarding the ulimit, I have to agree with Klaus - it's a good thing to
> have since crashes are unexpected - even on production.
>
> about the used user_id and group_id, I thing by default should be none
> - let's not force and let the user to decide if he wants to use such
> options.

The point is I don't want to (nor should I need to) edit 
/etc/init.d/openser to change behavior. The defaults file I proposed 
should solve all these issues nicely and allow one to use whatever 
options he wants without the fear that they will be overwritten on the 
next openser install.

Regarding the autogeneration of core files, that is the decision of the 
system administrator not of the software provider. If anyone wants to run 
with debugging on and core file generation enabled, they should be able 
to do so, in an easy way, but at the same time this shouldn't be forced 
on everyone by default.

There are a few security concerns about this.

1. /tmp is world readable and anyone can get sensitive information out of 
the core file

2. a system may be configured to generate core files with the name 
core.<pid>, and at the same time to protect against loosing service the 
system administrator may choose to restart the crashed openser proxy. If 
this happens and you also have configured openser to run with a fairly 
large amount of memory every crash will leave a huge core file on your 
disk. If you hit a bad bug where crashes happen frequently, you will end 
up filling your hard drive without noticing and may be locked out of the 
system.

3. On some systems /tmp may be a distinct partition, not so large in size 
to be able to hold a few huge core files without filling up, at which 
point the system is again hindered in its proper functioning.

For these considerations, I don't think that enforcing core file 
generation for everyone is a good idea as you can't predict the specific 
conditions that will run openser, or the policy of the system 
administrators running those systems.

On the other hand the defaults file I proposed should solve all these, buy 
allowing one to easily configure debugging and leave it on without the 
need to edit any of the system openser config files after a new install.

>
> regards,
> bogdan
>
> Klaus Darilion wrote:
> > Considering this case:
> > openser was running fine for 2-3 months. Suddenly a crash, we can't
> > fix it as I do not have a core dump. Thus, we have to wait again 2-3
> > months for another crash and the same bug will maybe cause outages at
> > other sites too.
> >
> > regards
> > klaus
> >
> > Dan Pascu wrote:
> >> On Monday 30 January 2006 15:14, Klaus Darilion wrote:
> >>> Bogdan-Andrei Iancu wrote:
> >>>> Klaus Darilion wrote:
> >>>>> Bogdan-Andrei Iancu wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> also be sure to have the permission to generate core. Do "ulimit
> >>>>>> -c unlimited".
> >>>
> >>> Why not having "ulimit -c unlimited" and PARAMS="-P $PIDFILE -u
> >>> openser -g openser -w /tmp" in the default startup script? We would
> >>> get lots more cordump to analyze.
> >>
> >> I think the startup script should come in a form that is suitable
> >> for using the proxy on a production platform, not for debugging. I
> >> personally do not want to edit the startup script everytime I
> >> install the proxy to remove options from it because they are meant
> >> for debugging which I don't need, except on rare occasions when I
> >> can manually add them for the moment until I fix the problem.
> >>
> >> A better idea would be to include some configuration file from the
> >> startup script and in that configuration file we can have various
> >> options defined. something like:
> >>
> >> DEFAULTS=/etc/defaults/openser
> >> if [ -f $DEFAULTS ]; then
> >>  . $DEFAULTS
> >> fi
> >>
> >> then we can have conditionals:
> >>
> >> PARAMS="-P $PIDFILE -m $MEMORY -u $USER -g $GROUP"
> >>
> >> if [ $DEBUG = "yes" ]; then
> >>    ulimit -c unlimited
> >>    PARAMS = "$PARAMS -w /tmp"
> >> fi
> >>
> >> This approach would also help to avoid the need to edit the startup
> >> script to change things like amount of memory, user/group to run as,
> >> ... Instead one would only have to edit the defaults file
> >>
> >> P.S.
> >> For a core file to be truly useful, the program should be compiled
> >> with -O0 (i.e. no optimizations). Else precious information may not
> >> be available to the debugger, so someone willing to get backtraces
> >> from openser crashes has to do a bit more than just set the core
> >> limit size and the directory where to write them.

-- 
Dan