Eric Wong writes:
> In case users see "lei-daemon" in ps(1) or syslog and wonder.
Thanks, this is very helpful/informative.
> diff --git a/Documentation/lei-daemon.pod b/Documentation/lei-daemon.pod
[...]
> +=head2 SOCK_SEQPACKET
> +
> +SOCK_SEQPACKET sockets are used for both communicating
Eric Wong wrote:
> If you have extra space somewhere to:
>
> a) copy the old extindex somewhere and do extindex --reindex on it
> b) just reindex in place (it /should/ work...)
> c) start a new extindex from scratch...
I might have to try c) myself. Though it might be time/batch-related;
Konstantin Ryabitsev wrote:
> On Fri, Oct 01, 2021 at 10:25:09PM +, Eric Wong wrote:
> > export HOME=/tmp/trash # fresh lei/store instance
> > M=87czop5j33@tynnyri.adurom.net
> > lei import https://yhbt.net/lore/all/$M/t.mbox.gz
> > lei q z:0.. | wc -l # should have all (11) msgs
On Fri, Oct 01, 2021 at 10:25:09PM +, Eric Wong wrote:
> export HOME=/tmp/trash # fresh lei/store instance
> M=87czop5j33@tynnyri.adurom.net
> lei import https://yhbt.net/lore/all/$M/t.mbox.gz
> lei q z:0.. | wc -l # should have all (11) msgs
> lei q m:$M -t | wc -l # should have
Eric Wong wrote:
> Can you confirm the above gives all 11 msgs for you?
erm, that's 10 msgs, I forget the JSON output always ends with a
"null" line
--
unsubscribe: one-click, see List-Unsubscribe header
archive: https://public-inbox.org/meta/
OK, so I'm also trying this on a CentOS 7.x VM, and
the lei part works as expected, so it seems specific to
extindex and not a problem with package differences in CentOS.
export HOME=/tmp/trash # fresh lei/store instance
M=87czop5j33@tynnyri.adurom.net
lei import
When indexing a single inbox, do not attempt reindexing code
paths without a full config, otherwise ordering comparisons
won't work.
---
lib/PublicInbox/ExtSearchIdx.pm | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/PublicInbox/ExtSearchIdx.pm b/lib/PublicInbox/ExtSearchIdx.pm
index
On Fri, Oct 01, 2021 at 08:54:42PM +, Eric Wong wrote:
> Oops, inspect doesn't work well w/o initialization (it should).
> Running "lei init" first should workaround it, for now.
Yes, that fixes the problem, but it still doesn't return much:
{
"mid" :
Konstantin Ryabitsev wrote:
> On Fri, Oct 01, 2021 at 08:41:31PM +, Eric Wong wrote:
> > Curious, what is the output of:
> >
> >lei inspect --dir /path/to/all mid:87czop5j33@tynnyri.adurom.net
> >
> > for you?
>
> Not much. :)
>
> lei inspect --dir /srv/public-inbox/extindex
On Fri, Oct 01, 2021 at 08:41:31PM +, Eric Wong wrote:
> Curious, what is the output of:
>
>lei inspect --dir /path/to/all mid:87czop5j33@tynnyri.adurom.net
>
> for you?
Not much. :)
lei inspect --dir /srv/public-inbox/extindex
mid:87czop5j33@tynnyri.adurom.net
Konstantin Ryabitsev wrote:
> On Fri, Oct 01, 2021 at 07:58:11PM +, Eric Wong wrote:
> > Are you running "public-inbox-extindex --all"?
> > Or relying on "public-inbox-index -E ..."? (which is automatic
> > for /all/?).
> public-inbox-extindex --all
>
> I believe this is what you
On Fri, Oct 01, 2021 at 09:05:27AM -0400, Konstantin Ryabitsev wrote:
> I was told about the following problem today:
>
> The following thread:
> https://lore.kernel.org/regressions/87czop5j33@tynnyri.adurom.net/
>
> Doesn't appear to show up in /all/:
>
On Fri, Oct 01, 2021 at 07:58:11PM +, Eric Wong wrote:
> Are you running "public-inbox-extindex --all"?
> Or relying on "public-inbox-index -E ..."? (which is automatic
> for /all/?).
After each repository update, we run:
public-inbox-index --no-update-extindex
And at the end of each
Konstantin Ryabitsev wrote:
> Hello:
>
> I was told about the following problem today:
>
> The following thread:
> https://lore.kernel.org/regressions/87czop5j33@tynnyri.adurom.net/
>
> Doesn't appear to show up in /all/:
> https://lore.kernel.org/all/87czop5j33@tynnyri.adurom.net/
>
In case users see "lei-daemon" in ps(1) or syslog and wonder.
---
Documentation/lei-daemon.pod | 61 ++
Documentation/lei.pod | 9 -
Documentation/lei_design_notes.txt | 2 +-
MANIFEST | 1 +
Makefile.PL
I'm thinking we can drop support for Linux <2.6.27 soonish and
just use EPOLL_CLOEXEC. Perl without signalfd (or
EVFILT_SIGNAL) is miserable, actually.
---
lib/PublicInbox/DS.pm | 46 ++-
1 file changed, 19 insertions(+), 27 deletions(-)
diff --git
Having git processes outlive DB handles is likely to hurt
from a fragmentation perspective if the DB handle needs to
be recreated immediately due to a git->cat_async callback.
So only unref DB handles when we're sure there's no live
git users left, otherwise check the inodes.
We'll also avoid
Since signalfd is often combined with our event loop, give it a
convenient API and reduce the code duplication required to use it.
EventLoop is replaced with ::event_loop to allow consistent
parameter passing and avoid needlessly passing the package name
on stack.
We also avoid exporting
It was probably incorrect to use from max_git_epoch, and it's
small enough to inline into do_cleanup. We'll also eliminate
the unnecessary deletion of {-altid_map} while we're in the
area, since we no longer cache/memoize that.
Fixes: 7e5cea05f061e757 ("inbox: rewrite cleanup to be more
Currently we don't use OpenSSL from child processes of parents
which use OpenSSL, but we may in the future. So ensure OpenSSL
initializes its PRNG after these forks to avoid one security
pitfall down the line.
---
lib/PublicInbox/IPC.pm | 2 ++
1 file changed, 2 insertions(+)
diff --git
5/9 has been a long-time coming, a few other small things, too.
The diff stat for lib/ alone shows a nice reduction
Eric Wong (9):
doc: lei-security: some more updates
listener: switch to level-triggered epoll
daemon: make SO_ACCEPTFILTER a shared variable
ipc: run Net::SSLeay::randomize
Constant subroutines use more memory and there's no need to
optimize it for inlining since it's only used at startup.
---
lib/PublicInbox/Daemon.pm | 6 +++---
t/httpd-corner.t | 4 ++--
t/httpd-https.t | 6 --
t/httpd.t | 6 --
t/imapd-tls.t
On second thought, the ->requeue + accept retry code path isn't
worth the userspace complexity and overhead. Level-triggered
epoll has always annoyed me since it takes an inefficient code
path in the kernel; but taking our less-efficient code path in
Perl seems even worse. We also need to take
Virtual users will probably be used for read-write IMAP/JMAP
support. The potential for various kernel/hardware bugs and
attacks also needs to be highlighted.
---
Documentation/lei-security.pod | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/lei-security.pod
24 matches
Mail list logo
