Developers of Sympa

[Guillaume Rousse <address@concealed>]

Le 08/08/2013 06:03, IKEDA Soji a écrit :
> On Tue, 06 Aug 2013 16:36:01 +0200
> Guillaume Rousse <address@concealed> wrote:
>
> > Le 05/08/2013 15:52, IKEDA Soji a écrit :
> > > > Bascally, those PID files or STDERR files are both temporary files of
> > > > the same class: they normally exist only during the lifetime of a single
> > > > process, and should be removed during normal process termination. If
> > > > they are left behind, that's because a crash occured, and they should be
> > > > removed on next process startup. So I think it makes sense to host both
> > > > kind of files on /var/run/sympa, and to use a single build-time
> > > > configuration directive for it. It could use a better name than PIDDIR,
> > > > however, such as RUNDIR for instance.
> > >
> > > It's in sense that PID files will be removed when the daemons
> > > stopeed normally.
> > As does the stderr ones, according to my own understanding of their purpose.
> >
> > So, what's about my proposal ?
> > - use File::Temp for all create-and-forget files
>
> File::Temp seems to cleanup files even in case of abnormal
> termination (e.g. runtime error by a typo in method names).
> On PID files and STDERR outputs, no traces of crash can't be
> left.
PID files and STDERR files are not create-and-forget files, as they have 
to be recoverable. And File::Temp does not mandatorily delete file, it 
depends of UNLIK parameter at instanciation time, see various example in 
Sympa::Tools::SMIME.

> However, this module will be useful for other kind of temporary
> files discussed below.
>
> > - deprecated tmpdir configuration variable
> > - rename --piddir configure switch to --rundir
> > - use RUNDIR for both pid and stderr files
>
> The mountpoint for PID files does not always intend files with
> gradual increase or large mass.  I suppose these two would be
> defined separately.
I have no clue about how much content goes in those STDERR files, as we 
primarily use syslog for error logging, and how much useful they are. I 
guess we may use pid files directly for crash detection.

Otherwise, that's a good point, even if there is no explicit restriction 
on this issue in the FHS.

> There is the other use of tmpdir which may be rather primary use:
> Saving messages to feed them to external utilities (MHOnArc,
> antivirus, openssl, ...).  Though generic temporary partition such
> as /var/tmp may be used, a dedicated place for sensitive data may
> be desirable.
>
> So, I suppose tmpdir parameter is useful and it would be distinct
> from PIDDIR.
Provided they are consistently defined: tmpdir is a runtime 
configuration directive, PIDDIR is a configure-time one.

Also, File::Temp uses the environment to identify a suitable write 
directory, meaning than you can still force TMPDIR=/var/tmp before 
running sympa if you really want control over this location.

OK, if that's not enough for you, here is an alternate plan:
- add --tmpdir configure switch (and ensuing TMPDIR constant)
- deprecate tmpdir configuration variable
- ensure all calls to File::Temp->new() use this value
- figure out if we really need to save daemons STDERR output

--
Guillaume Rousse
INRIA, Direction des systèmes d'information
Domaine de Voluceau
Rocquencourt - BP 105
78153 Le Chesnay
Tel: 01 39 63 58 31

Attachment: smime.p7s
Description: Signature cryptographique S/MIME