> Thats a lot of tail processes
Ugh, sorry to waste your time.
All the tails were from a run away UI program I'm working on.
Once I killed them, `let` runs just fine as non-root.
Thanks for the free tech support, hope I didn't steal your attention
from something valuable :-D.
On Mon, Mar
Louis DeLosSantos wrote:
> > Definitely not; the lei-daemon is per-user.
>
> Okay, maybe this is the issue to begin with? I installed lei from dnf.
> I'm not sure what launches the daemon, is it launched on first run?
>
> If that is the case, it was probably launched when I restored to `sudo
>
> Actually, only 18 (0..17). The `mem' stuff is mmap-ed and
doesn't count against `ulimit -n` (RLIMIT_NOFILE).
Yup, you are right, did a quick "wc -l" without thinking about it.
> Definitely not; the lei-daemon is per-user.
Okay, maybe this is the issue to begin with? I installed lei from dnf.
cindex --prune is less intrusive w.r.t. handling new
commits, now.
I'm embracing `local' more because this is a Perl codebase;
and I think it makes things more robust against typos.
I probably should've been doing this years ago :x
Eric Wong (4):
cindex: simplify some internal data structures
We need to ensure we don't block indexing for too long while
pruning, since pruning coderepos seems more frequent and
necessary than inbox repos due to the prevalence of force
pushes with branches like `seen' (formerly `pu') in git.git.
This requires us to workaround a current bug[1] in the XS
This makes it easier to pause and restart long-running indexing
jobs which use our event loop.
---
lib/PublicInbox/CodeSearchIdx.pm | 3 ++-
lib/PublicInbox/DS.pm| 5 +++--
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/lib/PublicInbox/CodeSearchIdx.pm
Shard workers may not die soon enough (or get stuck), just let
the parent die earlier since it doesn't need to commit anything.
---
lib/PublicInbox/CodeSearchIdx.pm | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/PublicInbox/CodeSearchIdx.pm b/lib/PublicInbox/CodeSearchIdx.pm
index
We'll rely more on local-ized `our' globals rather than
hashref fields. The former is more resistant to typos
and can be checked at compile-time earlier via `perl -c'.
The {-internal} field is also renamed to {-cidx_internal}
in case to reduce confusion within a large code base.
---
Louis DeLosSantos wrote:
> Above is 54 open sockets. Which seems fine.
Actually, only 18 (0..17). The `mem' stuff is mmap-ed and
doesn't count against `ulimit -n` (RLIMIT_NOFILE).
> Should daemon be running as root, if I intend to only use lei as user?
Definitely not; the lei-daemon is
> What's the output of `ulimit -n` and `lsof -p $(lei daemon-pid)`?
ulimit -n
1024
ps -ef |grep lei-daemon
root 861005 1 0 19:24 ?00:00:00 lei-daemon
/tmp/lei-0/5.seq.sock
louis1025477 1015489 0 22:22 pts/600:00:00 grep --color=auto lei-daemon
~
sudo lsof -p
Btw, I need to finish off a HW downgrade due to increasing
hosting costs. So retry sending any messages if you get bounces
or if your message doesn't show up on
https://public-inbox.org/meta/ after a few minutes.
Louis DeLosSantos wrote:
> Hello,
>
> I'm experimenting with `lei` as a nice search tool for `lore.kernel.org`
>
> Everything works fine with the caveat that it seems to break if I'm not root.
>
> When using `lei` as non-root we get this error:
I've never used lei as root nor has any part of
Hello,
I'm experimenting with `lei` as a nice search tool for `lore.kernel.org`
Everything works fine with the caveat that it seems to break if I'm not root.
When using `lei` as non-root we get this error:
```
E: Linux::Inotify2->new: Too many open files at
Konstantin Ryabitsev wrote:
> On Mon, Mar 27, 2023 at 07:10:49PM +, Eric Wong wrote:
> > > For the bugzilla integration work I'm doing, I need a way to check if
> > > there
> > > were any updates to a thread since the last check. Right now, I'm just
> > > grabbing the full thread, parsing it
On Mon, Mar 27, 2023 at 07:10:49PM +, Eric Wong wrote:
> > For the bugzilla integration work I'm doing, I need a way to check if there
> > were any updates to a thread since the last check. Right now, I'm just
> > grabbing the full thread, parsing it and seeing if there are any new
> >
Konstantin Ryabitsev wrote:
> Hello:
>
> For the bugzilla integration work I'm doing, I need a way to check if there
> were any updates to a thread since the last check. Right now, I'm just
> grabbing the full thread, parsing it and seeing if there are any new
> message-IDs that we don't know
Hello:
For the bugzilla integration work I'm doing, I need a way to check if there
were any updates to a thread since the last check. Right now, I'm just
grabbing the full thread, parsing it and seeing if there are any new
message-IDs that we don't know about, but it's very wasteful. Any way to
17 matches
Mail list logo