Re: a few observations in a multi-user setup

[ng0]

You can see the rest of the files here:

https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=tree;f=gnunet;h=83325a99a736b7fc6abbebc0ab9b02f4af53ab6d;hb=HEAD

ng0 transcribed 5.6K bytes:
> 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
> 
> 
> 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.
> 
> gnunet-core executed as my user just sits with empty return there.
> Is this supposed to happen in this setup? dvn says no.
> 
> 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.
> 
> The system-service seems not to log, but I guess that's
> expected when the gnunet-service-arm is detached?
> 
> 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.
>