Re: a few observations in a multi-user setup

[xrs]

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.

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

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

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

> 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

pgpbk4hT1RxLP.pgp
Description: OpenPGP digital signature