[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] rmmproc Not Used for Lots of Messages; refile Copies.
From: |
Jeffrey Honig |
Subject: |
Re: [Nmh-workers] rmmproc Not Used for Lots of Messages; refile Copies. |
Date: |
Sat, 24 Nov 2012 22:25:04 -0500 |
Ralph Corderoy <address@hidden> wrote:
> What-ho Ken!
>
> > > rmm: more than 998 messages for rmmproc exec
> >
> > So ... looks like this has been that way forever. Right now all calls
> > to execve() and friends are limited to MAXARGS arguments (which is
> > currently defined as 1000). Ok, 1 for argv[0], one for the trailing
> > NULL, that's how we end up at 998.
> >
> > As I read it ... the actual limit for execve() isn't the number of
> > arguments, it's the total number of bytes in the argv[] (and
> > environ[]) array. But I think capping the limit at MAXARGS is fine;
> > hasn't caused us any problems yet (well, other than this one).
>
> Traditionally I think there's two limits; the total number of bytes for
> the strings, including their terminating NULs, and the number of
> elements in the array that points to them. The latter may have
> influcenced MH.
>
> POSIX now seems to have just the strings and their NULs with argv's and
> environ's strings in total having to be 2Ki less than ARG_MAX to allow
> the exec'd process room to adjust and exec others. Though xargs(1)
> seems pessimistic.
>
> $ getconf ARG_MAX
> 2097152
> $ yes | xargs -e sh -c 'expr $# \* 2; kill $$'
> 131042
> xargs: sh: terminated by signal 15
> $
>
> > > rmmproc: rmmproc
> >
> > I take it "rmmproc" is your own script?
>
> Indeedy. ~/bin/rmmproc.
>
> > I guess the simplest thing to do would be to keep calling rmmproc over
> > and over until you process all of the arguments. That sound alright
> > to you?
>
> It would do, and I agree it's simple. In my case though I rename 42 to
> ,42,1353773276.939344523 where the timestamp is snapped once at the
> start of the script. This means all those rmm'd in one go have the same
> timestamp, which I find handy. Batching would break that. I'd live
> with it if necessary.
My rmmproc moves all files into +trash and annotates them with a
``Trashed'' header (which includes a date). I clean out my trash folder
after a few days, based on that annotation.
> Feeding rmmproc filenames on stdin is the normal workaround, LF or NUL
> terminated.
Changing the way rmmproc is called would break all out existing scripts.
Thanks!
Jeff
--
Jeffrey C. Honig <address@hidden>
http://www.honig.net/jch
GnuPG ID:14E29E13 <http://www.honig.net/jch/key.shtml>