Developers of Sympa

[IKEDA Soji <address@concealed>]

Guillaume, sorry for delayed response.

On Mon, 19 Aug 2013 16:42:06 +0200
Guillaume Rousse <address@concealed> wrote:

> 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.

I understand.

> > 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

I won't take objection to deprecating tmpdir dynamic configuration
(I don't prefer to rely on environment variable: command line or
configuration settings seems better).

> - ensure all calls to File::Temp->new() use this value

I'll support it.

> - figure out if we really need to save daemons STDERR output

I suppose this is easy and steady method: Whatever processes
output, even when processes are out of control, they will be
caught anyway.


Regards,

-- Soji

-- 
株式会社 コンバージョン  セキュリティ&OSSソリューション部   池田荘児
〒231-0004　神奈川県横浜市中区元浜町3-21-2 ヘリオス関内ビル7F
e-mail address@concealed  TEL 045-640-3550
http://www.conversion.co.jp/