gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: a few observations in a multi-user setup


From: ng0
Subject: Re: a few observations in a multi-user setup
Date: Mon, 28 Oct 2019 12:05:47 +0000

So I think this is due to some configuration detail I need
to clear, because the user 'gnunet' does also return
an empty gnunet-core:

su -m gnunet -c 'HOME=/var/chroot/gnunet TMP=/tmp GNUNET_PREFIX=/usr/pkg 
GNUNET_CACHE_HOME=/var/chroot/gnunet/cache gnunet-core'

ng0 transcribed 8.4K bytes:
> Hi,
> 
> xrs transcribed 7.8K bytes:
> > Hi ng0,
> > 
> > On Fri, 25 Oct 2019 08:20:43 +0000
> > ng0 <address@hidden> wrote:
> > 
> > > Hi,
> > > 
> > > last night I managed to understand rc.d in NetBSD to the extent
> > > required to make the services I needed for gnunet work.
> > > 
> > > I have tried to follow the example xrs provided, with a couple
> > > of modifcations which I suggested to xrs as well. The general
> > > idea of it is the same - a system wide service ("gnunet") running as
> > > gnunet and a user service ("gnunetuser") running as my user.
> > > 
> > > https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=blob_plain;f=gnunet/files/gnunet.conf;hb=HEAD
> > > the paths are not total in the package, they are replaced when the
> > > package is built (I'm still working on it).
> > > 
> > > My user's gnunet.conf in ~/.config/gnunet.conf is just:
> > > [arm]
> > > START_SYSTEM_SERVICES = NO
> > > START_USER_SERVICES = YES
> > 
> > Do you have another gnunet.conf for the system services? I only see one
> > under /files.
> 
> Yes, in $prefix/etc/gnunet/gnunet.conf, where the service is reading
> its config from.
> 
> > > 
> > > logs of today from the user-service in .cache/gnunet/:
> > > 
> > > Oct 25 07:38:39-677345 util-service-814 WARNING `bind' failed for
> > > `/tmp/gnunet-ng0-runtime//gnunet-service-arm.sock': address already
> > > in use Oct 25 07:38:39-677516 arm-814 ERROR `bind' failed at
> > > service.c:1805 with error: Address already in use Oct 25
> > > 07:38:39-677532 arm-814 ERROR Could not bind to any of the ports I
> > > was supposed to, refusing to run! Oct 25 07:39:39-706385
> > > util-service-839 WARNING Processing code for message of type 445 did
> > > not call `GNUNET_SERVICE_client_continue' after 1 m Oct 25
> > > 07:40:39-718660 util-service-839 WARNING Processing code for message
> > > of type 445 did not call `GNUNET_SERVICE_client_continue' after 2 m
> > > Oct 25 07:41:39-746191 util-service-839 WARNING Processing code for
> > > message of type 445 did not call `GNUNET_SERVICE_client_continue'
> > > after 3 m Oct 25 07:42:40-259141 util-service-839 WARNING Processing
> > > code for message of type 445 did not call
> > > `GNUNET_SERVICE_client_continue' after 4 m Oct 25 07:43:40-275850
> > > util-service-839 WARNING Processing code for message of type 445 did
> > > not call `GNUNET_SERVICE_client_continue' after 5 m Oct 25
> > > 07:44:40-288157 util-service-839 WARNING Processing code for message
> > > of type 445 did not call `GNUNET_SERVICE_client_continue' after 6 m
> > > Oct 25 07:45:40-320500 util-service-839 WARNING Processing code for
> > > message of type 445 did not call `GNUNET_SERVICE_client_continue'
> > > after 7 m Oct 25 07:46:40-339650 util-service-839 WARNING Processing
> > > code for message of type 445 did not call
> > > `GNUNET_SERVICE_client_continue' after 8 m Oct 25 07:47:40-360266
> > > util-service-839 WARNING Processing code for message of type 445 did
> > > not call `GNUNET_SERVICE_client_continue' after 9 m Oct 25
> > > 07:48:40-379021 util-service-839 WARNING Processing code for message
> > > of type 445 did not call `GNUNET_SERVICE_client_continue' after 10 m
> > > Oct 25 07:49:40-411906 util-service-839 WARNING Processing code for
> > > message of type 445 did not call `GNUNET_SERVICE_client_continue'
> > > after 11 m Oct 25 07:50:40-443950 util-service-839 WARNING Processing
> > > code for message of type 445 did not call
> > > `GNUNET_SERVICE_client_continue' after 12 m Oct 25 07:51:40-455128
> > > util-service-839 WARNING Processing code for message of type 445 did
> > > not call `GNUNET_SERVICE_client_continue' after 13 m Oct 25
> > > 07:52:40-497166 util-service-839 WARNING Processing code for message
> > > of type 445 did not call `GNUNET_SERVICE_client_continue' after 14 m
> > > Oct 25 07:53:40-542582 util-service-839 WARNING Processing code for
> > > message of type 445 did not call `GNUNET_SERVICE_client_continue'
> > > after 15 m Oct 25 07:54:40-584438 util-service-839 WARNING Processing
> > > code for message of type 445 did not call
> > > `GNUNET_SERVICE_client_continue' after 16 m Oct 25 07:55:40-626322
> > > util-service-839 WARNING Processing code for message of type 445 did
> > > not call `GNUNET_SERVICE_client_continue' after 17 m Oct 25
> > > 07:56:40-658224 util-service-839 WARNING Processing code for message
> > > of type 445 did not call `GNUNET_SERVICE_client_continue' after 18 m
> > > Oct 25 07:57:40-700152 util-service-839 WARNING Processing code for
> > > message of type 445 did not call `GNUNET_SERVICE_client_continue'
> > > after 19 m Oct 25 07:58:40-732097 util-service-839 WARNING Processing
> > > code for message of type 445 did not call
> > > `GNUNET_SERVICE_client_continue' after 20 m Oct 25 07:59:40-774070
> > > util-service-839 WARNING Processing code for message of type 445 did
> > > not call `GNUNET_SERVICE_client_continue' after 21 m Oct 25
> > > 08:00:40-802679 util-service-839 WARNING Processing code for message
> > > of type 445 did not call `GNUNET_SERVICE_client_continue' after 22 m
> > > Oct 25 08:01:40-844687 util-service-839 WARNING Processing code for
> > > message of type 445 did not call `GNUNET_SERVICE_client_continue'
> > > after 23 m Oct 25 08:02:40-886598 util-service-839 WARNING Processing
> > > code for message of type 445 did not call
> > > `GNUNET_SERVICE_client_continue' after 24 m Oct 25 08:03:40-898997
> > > util-service-839 WARNING Processing code for message of type 445 did
> > > not call `GNUNET_SERVICE_client_continue' after 25 m
> > > 
> > > 
> > > the startup sequence is: gnunet -> gnunetuser, so I don't
> > > understand why the address should be in use already.
> > 
> > Did you always check, that no "orphan" processes are running? That was
> > sometimes a problem for me. 
> 
> I'm not sure how I should arrive at orphan processes when this
> is after boot, prior to login. Does this make sense?
>  
> > > gnunet-core executed as my user just sits with empty return there.
> > > Is this supposed to happen in this setup? dvn says no.
> > 
> > If there an internet connection gnunet-core should return a list of
> > peers.
> > 
> > > gnunet-arm -I as my user shows that services are running:
> > > 
> > > Running services:
> > > namestore (gnunet-service-namestore)
> > > zonemaster (gnunet-service-zonemaster)
> > > zonemaster-monitor (gnunet-service-zonemaster-monitor)
> > > 
> > > 
> > > While I do seem to have known peers in the $home of the
> > > system-service user, a gnunet-search so far returns
> > > nothing, but I'll give it some more time.
> > 
> > I guess, no gnunet-core result, no gnunet-search.
> 
> Hm, okay.
>  
> > > The system-service seems not to log, but I guess that's
> > > expected when the gnunet-service-arm is detached?
> > 
> > AFAIK by default it should, depending on the log level and the configure
> > flag logging. Have you looked at $GNUNETHOME/.cache/gnunet/*.log? 
> 
> Yes, it does not exist, and in the location for logs nothing
> is written.
>  
> > > The user-service behaves odd enough for rc.d to report
> > > "gnunetuser is not running" while the service is started
> > > and running - how can we improve that so that service
> > > managers can pick up the status?
> > > on the other hand my service could still be hacky enough
> > > to return 1 on status for whatever reason I missed yesterday.
> > 
> > Depending on how you use rc.d it will track the services or not. It is
> > using an internal state, thus you might have started the services with
> > rc but released them not on purpose (e.g. because of an error). In this
> > case kill all, "restart" services under rc again and try to fix the
> > tracking.
> 
>  
> > I hope this helps a bit,
> > xrs
> 
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]