View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004542 | secushare | social | public | 2016-05-30 07:49 | 2019-02-12 09:13 |
| Reporter | lynX | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | confirmed | Resolution | open | ||
| Summary | 0004542: pubsub (gnunet-social) does not work with separated system/user configs | ||||
| Description | Update: This bug describes how gnunet-social is unable to relay packets to its lower layers which are running on another uid as intentional with the SYSTEM_ONLY + USER_ONLY style of configuration. ---- I wrote the "psycit" script to ensure gnunet is running in a sane configuration and suitable egos have been generated. It prototypes the kind of jobs that a secushare application would also have to automate. Then I ran it on one userid to host a chatroom. It would fetch the previously generated ego and ask gnunet-social to produce a chatroom. computer] ./psycit -C => gnunet-social -e 0A9RPQ1VDZB3M67XEBP9MVF6ZHKA4TP3YS99FMVG9JF4TQ3C9SXG --follow --host-enter --welcome May 29 17:30:56-912320 gnunet-social-26050 WARNING Ego: 0A9RPQ1VDZB3M67XEBP9MVF6ZHKA4TP3YS99FMVG9JF4TQ3C9SXG vonlynX May 29 17:30:56-912862 gnunet-social-26050 WARNING Ego: X33YY4YG62PQVN6918TX812ZT4EJYZAGEJDJ6STNTS2Z3HEX8WVG lynX May 29 17:30:56-913011 gnunet-social-26050 WARNING Ego: KXM3ER7Z8J50AKFNHJ31APRKVKYPSPPA37D4SN0G7A381N4EVYE0 user May 29 17:30:56-913174 gnunet-social-26050 WARNING Host: HXWCGDE3WBFNBE0FMFNVGMQGB3480698AHQ5Z2EEZEV6BFJ1KES0 May 29 17:30:56-913328 gnunet-social-26050 WARNING Host: GGSE8Y2RVDWM9G2W02FHJKTXC8K3MDY8Z25V81EAXNWNE9329B10 Interestingly, gnunet-social lists also previously generated egos although we explicitly didn't want to use those, then it outputs a new (GGSE) and an old chatroom keydress (HXWC). After that it waits for events ("--follow"). Next I switch to a different userid on the same machine and pass it the keydress of the newly generated place. As you can see it quietly pulls out its own ego from gnunet-identity, then requests a --guest-enter with TVV5 being the locally running node. computer ~% psycit -p GGSE8Y2RVDWM9G2W02FHJKTXC8K3MDY8Z25V81EAXNWNE9329B10 -S => gnunet-social --guest-enter --follow -e H85F4CKSGWF41HCFNR97E9HH6CM24P46CTS64MQQ33Z0QXMCA2K0 -p GGSE8Y2RVDWM9G2W02FHJKTXC8K3MDY8Z25V81EAXNWNE9329B10 -i TVV54YYR29KRDKM30ZC3014JXHDGPVT7KFQGA44CEV2YQSEVFDAG May 29 17:34:29-818344 gnunet-social-26127 WARNING Ego: H85F4CKSGWF41HCFNR97E9HH6CM24P46CTS64MQQ33Z0QXMCA2K0 egal May 29 17:34:29-818975 gnunet-social-26127 WARNING Guest: HXWCGDE3WBFNBE0FMFNVGMQGB3480698AHQ5Z2EEZEV6BFJ1KES0 The debug warnings show HXWC which probably got there by a previous test. Next up, nothing happens. Typing anything into stdin of any of the two processes has no effect. Submitting a --guest-talk has no visible effects, either: computer ~% psycit -p GGSE8Y2RVDWM9G2W02FHJKTXC8K3MDY8Z25V81EAXNWNE9329B10 -P => gnunet-social --guest-talk -m _notice_testing_psycit -d 'check check' -e H85F4CKSGWF41HCFNR97E9HH6CM24P46CTS64MQQ33Z0QXMCA2K0 -p GGSE8Y2RVDWM9G2W02FHJKTXC8K3MDY8Z25V81EAXNWNE9329B10 -i TVV54YYR29KRDKM30ZC3014JXHDGPVT7KFQGA44CEV2YQSEVFDAG May 29 17:34:29-818344 gnunet-social-26127 WARNING Ego: H85F4CKSGWF41HCFNR97E9HH6CM24P46CTS64MQQ33Z0QXMCA2K0 egal May 29 17:34:29-818975 gnunet-social-26127 WARNING Guest: HXWCGDE3WBFNBE0FMFNVGMQGB3480698AHQ5Z2EEZEV6BFJ1KES0 Hitting ^C to terminate the experiment produces the following assertion failure in both instances of gnunet-social: ^CMay 29 17:35:35-519194 gnunet-social-26050 ERROR Assertion failed at scheduler.c:978. child died with signal 6, without coredump ^CMay 29 17:35:39-519965 gnunet-social-26127 ERROR Assertion failed at scheduler.c:978. child died with signal 6, without coredump | ||||
| Tags | No tags attached. | ||||
| Attached Files | psycit (4,150 bytes)
#!/usr/bin/perl
#
# use Net::PSYC;
sub debug() { 1 }
use Getopt::Std;
getopt('pime');
# pick the name of an ego from the environment
# FIXME: assuming nickname has no whitespace
my $nick = $opt_e
|| $ENV{'PSYCNICK'}
|| $ENV{'NICK'} # this one should work with any chat system
|| $ENV{'IRCNICK'}
|| $ENV{'USER'}
|| 'user';
my $peerid = $opt_i
|| $ENV{'GNUNET_PEERID'}
# peerid of the gnunet node runnning on cheet
|| 'TVV54YYR29KRDKM30ZC3014JXHDGPVT7KFQGA44CEV2YQSEVFDAG';
my $place = $opt_p
|| $ENV{'PSYCPLACE'}
# pubkey of a place created on cheet
|| 'RG3RY7FTTT6128V1HGZQCQ89Q5APTHSP2JD9WKGH4T2N7KQZFVQG';
my $method = $opt_m || '_notice_testing_psycit';
# first, let's check if we are being run by the correct user
my $cf = "$ENV{HOME}/.config/gnunet.conf";
die "This user has no $cf that I can read" unless open(C, $cf);
my $ok = 0;
while(<C>) {
# i'll check for [arm] some other day... FIXME
$ok++ if /^\s*USER_ONLY\s*=\s*YES\s*$/i;
}
close C;
die "Your $cf is not configured to run user services" unless $ok;
# now, let's see if the services are up
my $cmd = 'gnunet-arm --info |';
die "$cmd failed: $!" unless open(C, $cmd);
$ok = 0;
while(<C>) {
$ok++ if /^(gns|social|identity) /;
}
close C;
die "Not all of GNS, social and identity services are running" if $ok != 3;
unless ($ego = fetchEgo($nick)) {
die "Could not create ego for $nick: $!"
unless sys('gnunet-identity', '--create', $nick);
die "Could not fetch ego for $nick after creation: $!"
unless $ego = fetchEgo($nick);
die "Could not assign $nick's ego as default for social: $!"
# FIXME: --set instead of --service doesnt look intuitive
unless sys('gnunet-identity', '--ego', $nick, '-s', 'social');
}
if ($opt_C) {
# FIXME: gnunet-social should not need different commands here,
# checking for presence of -p parameter should be enough.
&sys( "gnunet-social -e $ego --follow ".( $opt_p? "--host-reconnect -p $opt_p"
: "--host-enter --welcome" ));
} elsif ($opt_S) {
# FIXME: why do we have differing API calls for entering and
# reconnecting a place?
&sys( "gnunet-social --guest-enter --follow -e $ego -p $place -i $peerid" );
} elsif ($opt_P) {
my $d = '';
if ($#ARGV > 0) {
$d = join(' ', @ARGV);
} else {
$d .= $_ while <STDIN>;
}
$d =~ tr/[\r\n]/ /;
chomp $d;
# FIXME: API must be able to know by itself if a place is local or remote
# therefore the distinction of guest-talk and host-announce must go
&sys( "gnunet-social --guest-talk -m $method -d '$d' -e $ego -p $place -i $peerid" );
} else {
print <<X;
Hello, $nick! (aka $ego)
Usage: $0 <command> [-c] [-p <place>] [-i <peerid>]
[-m <method>] [-e <ego>] [ <body> ]
Commands are:
-C create or reconnect to a locally hosted pubsub channel
(will not terminate as messages are expected)
-S enter or reconnect to a remotely hosted pubsub channel
(will not terminate as messages are expected)
-P publish to a channel
-h show this help
Parameters are:
-p use this place where necessary
-i use this GNUnet PeerID where necessary
-e use this ego where necessary
<body> for publishing, can also be passed via stdin.
Options are:
-c continue in case of errors
-m <method> use a different method when publishing
X
# -L leave a channel
# -s show some status
}
exit;
sub sys {
print "=> ", join(' ', @_), "\n" if debug;
if (system(@_)) {
if ($? == -1) {
print "failed to execute: $!\n";
} elsif ($? & 127) {
printf "child died with signal %d, %s coredump\n",
($? & 127), ($? & 128) ? 'with' : 'without';
} else {
printf "child exited with value %d\n", $? >> 8;
}
exit $? unless $opt_c;
return 0;
}
return 1;
}
sub fetchEgo {
my $n = shift;
# FIXME: there should be some UX consistency between gnunet tools
# regarding --list, --info or --display
# FIXME: gnunet-identity should offer a way to resolve exactly one
# ego nickname
my $e = undef, $cmd = 'gnunet-identity --display |';
local(*C);
die "$cmd failed: $!" unless open(C, $cmd);
while(<C>) {
# print;
$e = $1 if /^$n - (\w+)$/i; # may i ignore case?
}
close C;
return $e;
}
| ||||
|
|
the list you get at the beginning is the current status, it shows the current egos and entered places, same as --status (or no args) --host-enter creates a new place, the address of which you can find on a line like this: Host entered: <pubkey> Then you can use that pubkey from other clients. You were using one of the old place pubkeys instead of the one you just created, that's why it didn't work. |
|
|
Well, then I guess the problem is that such a line "Host entered: <pubkey>" never appeared. What could be the cause for that? |
|
|
make sure all of these services are running: - social - psyc - psycstore - multicast - cadet |
|
|
Oh wow, we've been running these tools for about a year now, and now we find out we should have started the services manually? That's amazing! How does one start such a service manually? Shouldn't they all AUTOSTART given such a statement is in each of their config files? Can you post a gnunet.conf or your complete set-up by which it works for you? Can you add code to all tools that detects when services are missing so users do not stay in the dark? Or even better, shouldn't all involved services be autostarted on demand? |
|
|
they all have AUTOSTART = YES by default, but the question was: are all of these actually running on your system? |
|
|
Well, I thought my answer made it clear that they are not. I just discovered that I can start them manually using 'gnunet-arm -i <service>'. That surprised me since last time I tried it didn't work. Okay, now I have all the services running. I run the same script as usual: computer] ./psycit -C => gnunet-social -e 0A9RPQ1VDZB3M67XEBP9MVF6ZHKA4TP3YS99FMVG9JF4TQ3C9SXG --follow --host-enter --welcome May 30 18:34:03-050696 gnunet-social-30564 WARNING Ego: 0A9RPQ1VDZB3M67XEBP9MVF6ZHKA4TP3YS99FMVG9JF4TQ3C9SXG vonlynX May 30 18:34:03-051415 gnunet-social-30564 WARNING Ego: X33YY4YG62PQVN6918TX812ZT4EJYZAGEJDJ6STNTS2Z3HEX8WVG lynX May 30 18:34:03-051731 gnunet-social-30564 WARNING Ego: KXM3ER7Z8J50AKFNHJ31APRKVKYPSPPA37D4SN0G7A381N4EVYE0 user May 30 18:34:03-051976 gnunet-social-30564 WARNING Host: SQVPFMVCB3G1W5ACWPNV1XJGVYKXTMWWPMHYJA7VY73K5J9X7VF0 May 30 18:34:03-052296 gnunet-social-30564 WARNING Host: GGSE8Y2RVDWM9G2W02FHJKTXC8K3MDY8Z25V81EAXNWNE9329B10 May 30 18:34:03-052542 gnunet-social-30564 WARNING Host: JTWFK8BPAYK4NFV2F58WS0KSG7Y5FDF04HN8SB0J2TB5ZCTCH150 May 30 18:34:03-052740 gnunet-social-30564 WARNING Host: HXWCGDE3WBFNBE0FMFNVGMQGB3480698AHQ5Z2EEZEV6BFJ1KES0 May 30 18:34:03-052924 gnunet-social-30564 WARNING Host: Z9EXJC8ET45JYN8834AB4E5QQJARYRHY544N6KSA43GF4737YN60 It lists all the dead horses of the past, but still does not produce a "Host entered" message for the new place. |
|
|
then checking the logs of services would help to figure out the problem enable logging for all services: [arm] GLOBAL_POSTFIX = -l $GNUNET_CACHE_HOME/{}-%F.%T-[].log then increase log level for specific services: [multicast] #AUTOSTART = NO OPTIONS = -L DEBUG -l /home/gnunet/.cache/gnunet/multicast-%F.%T-[].log [psycstore] #AUTOSTART = NO OPTIONS = -L DEBUG -l /home/gnunet/.cache/gnunet/social-%F.%T-[].log [psyc] #AUTOSTART = NO OPTIONS = -L DEBUG -l /home/gnunet/.cache/gnunet/social-%F.%T-[].log [social] #AUTOSTART = NO OPTIONS = -L DEBUG -l /home/gnunet/.cache/gnunet/social-%F.%T-[].log (apparently $GNUNET_CACHE_HOME only works for GLOBAL_POSTFIX) |
|
|
Also, for development work you can do the following. First set AUTOSTART = NO in for each of these services, then run each of the below commands in a separate terminal: (gnunet-logread & gnunet-logread-ipc are in utils/) Start IPC monitor: rm -f /tmp/gnunet-logread-ipc.sock; gnunet-logread-ipc | gnunet-logread Then start each of the services: gnunet-service-multicast -L DEBUG |& tee multicast-$(date +%F.%T).log | gnunet-logread -L WARNING -i /tmp/gnunet-logread-ipc.sock -n multicast gnunet-service-psycstore -L DEBUG |& tee psycstore-$(date +%F.%T).log | gnunet-logread -L WARNING -i /tmp/gnunet-logread-ipc.sock -n psycstore gnunet-service-psyc -L DEBUG |& tee psyc-$(date +%F.%T).log | gnunet-logread -L WARNING -i /tmp/gnunet-logread-ipc.sock -n psyc gnunet-service-social -L DEBUG |& tee social-$(date +%F.%T).log | gnunet-logread -L WARNING -i /tmp/gnunet-logread-ipc.sock -n social |
|
|
just checked, the services start with socket activation, i.e. when you run the gnunet-social client, the social service is started, which then causes all the rest to start when the services connect to each other setting FORCESTART = YES skips socket activation and starts the service when you start arm make sure all of these are running after starting gnunet-social, then you can check the logs if there's any ERROR in there.. or just post them here |
|
|
fixed the config in comment 10785 |
|
|
I removed some old egos with -D but apparently they were still checked into some places. Other than that, no progress: computer] ./psycit -C => gnunet-social -e 0A9RPQ1VDZB3M67XEBP9MVF6ZHKA4TP3YS99FMVG9JF4TQ3C9SXG --follow --host-enter --welcome May 30 20:25:22-168339 gnunet-social-10255 WARNING Ego: 0A9RPQ1VDZB3M67XEBP9MVF6ZHKA4TP3YS99FMVG9JF4TQ3C9SXG vonlynX May 30 20:25:22-169220 gnunet-social-10255 WARNING Host: SQVPFMVCB3G1W5ACWPNV1XJGVYKXTMWWPMHYJA7VY73K5J9X7VF0 May 30 20:25:22-169497 gnunet-social-10255 ERROR Failure to obtain ego. Is identity service running? May 30 20:25:22-169635 gnunet-social-10255 ERROR Assertion failed at social_api.c:962. May 30 20:25:22-169832 gnunet-social-10255 WARNING Host: JTWFK8BPAYK4NFV2F58WS0KSG7Y5FDF04HN8SB0J2TB5ZCTCH150 May 30 20:25:22-170099 gnunet-social-10255 ERROR Failure to obtain ego. Is identity service running? May 30 20:25:22-170263 gnunet-social-10255 ERROR Assertion failed at social_api.c:962. May 30 20:25:22-170457 gnunet-social-10255 WARNING Host: Z9EXJC8ET45JYN8834AB4E5QQJARYRHY544N6KSA43GF4737YN60 May 30 20:25:22-170660 gnunet-social-10255 WARNING Host: VHWGYFWXAYFXVVP0A3NMCXT7XB0RTPMP11NMJXRNFYZE1HW6RXKG With the new configuration two empty debug logs were created: .cache/gnunet/gns-2016-05-30.log .cache/gnunet/namestore-2016-05-30.log A more recent run made some debug output show up in the main gnunet.log. Here's the tail of grep social- gnunet.log: [skipped some adding to hashmap stuff] May 30 20:45:35-755177 social-10706 DEBUG 0xb93d5cc8 Sending ego notification to client: vonlynX May 30 20:45:35-771309 social-10706 DEBUG 0xb93d5cc8 Sending end of ego list notification to client May 30 20:45:35-771432 social-10706 DEBUG 0xb93d5cc8 Sending place notification of type 841 to client. May 30 20:45:35-771516 social-10706 DEBUG 0xb93d5cc8 Sending place notification of type 841 to client. May 30 20:45:35-771598 social-10706 DEBUG 0xb93d5cc8 Sending place notification of type 841 to client. May 30 20:45:35-771680 social-10706 DEBUG 0xb93d5cc8 Sending place notification of type 841 to client. May 30 20:45:35-771762 social-10706 DEBUG 0xb93d5cc8 Sending place notification of type 841 to client. May 30 20:45:35-771844 social-10706 DEBUG 0xb93d5cc8 Sending place notification of type 841 to client. May 30 20:45:35-771926 social-10706 DEBUG 0xb93d5cc8 Sending place notification of type 841 to client. May 30 20:45:35-772008 social-10706 DEBUG 0xb93d5cc8 Sending place notification of type 841 to client. May 30 20:45:35-772090 social-10706 DEBUG 0xb93d5cc8 Sending end of place list notification to client May 30 20:45:35-772199 social-10706 DEBUG 0xb93d0870 Application cli connected. May 30 20:45:35-848574 social-10706 DEBUG Adding app place to hashmap: May 30 20:45:35-848687 social-10706 DEBUG app_id = cli May 30 20:45:35-848820 social-10706 DEBUG ego_place_pub_hash = GA38JNFC May 30 20:45:35-848866 social-10706 DEBUG Adding place to hashmap: May 30 20:45:35-848940 social-10706 DEBUG ego_place_pub_hash = GA38JNFC May 30 20:45:35-849636 social-10706 WARNING 0xb93d76d0 Client connected as host to place M27K8JS4. May 30 20:45:49-422860 social-10706 DEBUG 0xb93d76d0 Client (host) disconnected from place M27K8JS4 So it did do something, but the callback didn't call back. |
|
|
After use of these gnunet-social commands, gnunet-arm -e hangs. Checking gnunet-arm -I shows that only "social" is still running. Since interrupting it with ^C it has gone into a non cooperative state. kill -9 gnunet helps. A simple kill is not enough. Here's what grep -v util- log shows: May 31 13:12:03-049334 social-13445 DEBUG 0xb8784530 Sending place notification of type 841 to client. May 31 13:12:03-049451 social-13445 DEBUG 0xb8784530 Sending place notification of type 841 to client. May 31 13:12:03-049535 social-13445 DEBUG 0xb8784530 Sending place notification of type 841 to client. May 31 13:12:03-049616 social-13445 DEBUG 0xb8784530 Sending end of place list notification to client May 31 13:12:03-049698 social-13445 DEBUG 0xb8788a48 Application cli connected. May 31 13:12:03-059293 social-13445 DEBUG Adding app place to hashmap: May 31 13:12:03-059330 social-13445 DEBUG app_id = cli May 31 13:12:03-059487 social-13445 DEBUG ego_place_pub_hash = 3THHXVFP May 31 13:12:03-059529 social-13445 DEBUG Adding place to hashmap: May 31 13:12:03-059602 social-13445 DEBUG ego_place_pub_hash = 3THHXVFP May 31 13:12:03-060044 social-13445 DEBUG 0xb878a4a0 Client connected as guest to place QT5MNDW3. May 31 13:14:53-707761 identity-13400 DEBUG Received START message from client May 31 13:21:46-264807 social-13445 DEBUG 0xb878a4a0 Client (guest) disconnected from place QT5MNDW3 May 31 13:26:34-362512 identity-13400 DEBUG Received START message from client May 31 13:28:35-958429 identity-13400 DEBUG Received START message from client May 31 13:38:11-466917 gns-13398 DEBUG Shutting down! May 31 13:38:11-467576 namestore-api-13398 DEBUG Cleaning up May 31 13:38:11-467760 namecache-api-13398 DEBUG Cleaning up May 31 13:38:11-470984 social-13445 DEBUG 0xb8787c40 Cleaning up place M27K8JS4 May 31 13:38:11-471293 social-13445 DEBUG 0xb8786668 Cleaning up place YJGS3YR7 May 31 13:38:11-471473 social-13445 DEBUG 0xb8788320 Cleaning up place 2PN8ENE4 May 31 13:38:11-471628 social-13445 DEBUG 0xb87857e0 Cleaning up place 1A5HP836 May 31 13:38:11-471785 social-13445 DEBUG 0xb87850b8 Cleaning up place 7BTKARX4 May 31 13:38:11-471947 social-13445 DEBUG 0xb8784a20 Cleaning up place BG6MP3BS May 31 13:38:11-472402 social-13445 DEBUG 0xb8785ee8 Cleaning up place NVFCYP4N May 31 13:38:11-472561 social-13445 DEBUG 0xb8786d38 Cleaning up place VRV0FFYN May 31 13:38:11-472683 social-13445 DEBUG 0xb8787440 Cleaning up place KW0T3JCY May 31 13:38:11-472804 social-13445 DEBUG 0xb878a4a0 Cleaning up place QT5MNDW3 May 31 13:38:11-472952 core-api-13445 DEBUG Disconnecting from CORE service May 31 13:38:11-489555 namestore-api-13445 DEBUG Cleaning up Here's what the gnunet system log says: May 31 11:49:19-746772 psycstore-sqlite-12929 DEBUG Prepared `DELETE FROM state WHERE channel_id = (SELECT id FROM channels WHERE pub_key = ?) AND (value_current IS NULL OR length(value_current) = 0) AND (value_signed IS NULL OR length(value_signed) = 0);' / 0xb8bebbe0: 0 May 31 11:49:19-747149 psycstore-sqlite-12929 DEBUG Prepared `UPDATE state SET value_signed = value_current WHERE channel_id = (SELECT id FROM channels WHERE pub_key = ?);' / 0xb8bf5988: 0 May 31 11:49:19-747415 psycstore-sqlite-12929 DEBUG Prepared `DELETE FROM state WHERE channel_id = (SELECT id FROM channels WHERE pub_key = ?);' / 0xb8bf5a78: 0 May 31 11:49:19-747620 psycstore-sqlite-12929 DEBUG Prepared `INSERT INTO state_sync (channel_id, name, value) VALUES ((SELECT id FROM channels WHERE pub_key = ?), ?, ?);' / 0xb8bf5b68: 0 May 31 11:49:19-747903 psycstore-sqlite-12929 DEBUG Prepared `INSERT INTO state (channel_id, name, value_current, value_signed) SELECT channel_id, name, value, value FROM state_sync WHERE channel_id = (SELECT id FROM channels WHERE pub_key = ?);' / 0xb8bf4fe8: 0 May 31 11:49:19-748146 psycstore-sqlite-12929 DEBUG Prepared `DELETE FROM state_sync WHERE channel_id = (SELECT id FROM channels WHERE pub_key = ?);' / 0xb8bf52f0: 0 May 31 11:49:19-748409 psycstore-sqlite-12929 DEBUG Prepared `SELECT value_current FROM state WHERE channel_id = (SELECT id FROM channels WHERE pub_key = ?) AND name = ?;' / 0xb8bf9cd0: 0 May 31 11:49:19-749815 psycstore-sqlite-12929 DEBUG Prepared `SELECT name, value_current FROM state WHERE channel_id = (SELECT id FROM channels WHERE pub_key = ?) AND (name = ? OR substr(name, 1, ?) = ? || '_');' / 0xb8bf8968: 0 May 31 11:49:19-750213 psycstore-sqlite-12929 DEBUG Prepared `SELECT name, value_signed FROM state WHERE channel_id = (SELECT id FROM channels WHERE pub_key = ?) AND value_signed IS NOT NULL;' / 0xb8bfafc8: 0 May 31 11:49:19-750327 psycstore-sqlite-12929 INFO SQLite database running May 31 11:49:39-720146 core-api-12931 DEBUG Processing message of type 67 and size 40 from core service May 31 11:49:39-720209 core-api-12931 DEBUG Received notification about connection from `QT80'. |
|
|
check the IPC logs, it should look something like this for --host-enter where does it get stuck? client -> core CORE_INIT (8) core -> client CORE_INIT_REPLY (40) client -> social SOCIAL_APP_CONNECT (8) social -> client SOCIAL_APP_EGO (45) client WARNING: Ego: Y2MJ2S6X4YJY1RNXYYSQYZ0GD38H2A50JSM5KVJREQZMEJ86KKSG Host One social -> client SOCIAL_APP_EGO_END (4) social -> client SOCIAL_APP_PLACE (70) client WARNING: Host: 7C9DFT92S46EDMPGQ2BQ3XMHX02QRHK3HJNSQZFB57F2V8YAN2Z0 social -> client SOCIAL_APP_PLACE (70) client WARNING: Guest: 35HMQHF1FJHBWNA9NPTTRW5GNZWJG0WM6QDDS4B1N0G5PDZ526P0 social -> client SOCIAL_APP_PLACE_END (4) client -> social SOCIAL_HOST_ENTER (108) social -> psyc PSYC_MASTER_START (40) psyc -> psycstore PSYCSTORE_COUNTERS_GET (48) psycstore -> psyc PSYCSTORE_RESULT_COUNTERS (48) psyc -> social PSYC_MASTER_START_ACK (16) social -> client SOCIAL_HOST_ENTER_ACK (48) client WARNING: Host entered: RVZKZ9E17C5M1A8J880FXW6W77V2T607K0473YWT1W2C240TEV70, max_message_id: 0 psyc -> multicast MULTICAST_ORIGIN_START (48) |
|
|
Your set-up requires me to open far too many windows ;) Here's the set-up I am using: user: gnunet-logread -f system: gnunet-service-arm |& gnunet-logread -x util- -n main user: gnunet-service-arm |& gnunet-logread -x util- -n main user: psycit Output as follows: ] gnunet-logread -f May 31 19:39:30-616562 main -> core CORE_INIT (8) May 31 19:39:31-311736 core -> main CORE_INIT_REPLY (40) May 31 19:39:31-325635 main -> cadet CADET_LOCAL_CONNECT (8) May 31 19:39:32-583039 core -> main CORE_NOTIFY_CONNECT (40) system arm: <shows various things about core, transport, cadet etc> user arm: May 31 20:14:50-987834 gns-16358 DEBUG Received 0 records for label `(null)' via namestore monitor May 31 20:15:31-267992 gns-16358 DEBUG Received 0 records for label `(null)' via namestore monitor May 31 20:15:32-185269 identity-api-16358 DEBUG Connecting to identity service. May 31 20:16:11-515757 gns-16358 DEBUG Received 0 records for label `(null)' via namestore monitor May 31 20:16:12-397646 identity-api-16358 DEBUG Scheduling task to reconnect to identity service in 15 m. May 31 20:16:51-765743 gns-16358 DEBUG Received 0 records for label `(null)' via namestore monitor May 31 20:17:32-046055 gns-16358 DEBUG Received 0 records for label `(null)' via namestore monitor psycit: Not all of GNS, social and identity services are listening at ./psycit line 63. (= gnunet-arm is unable to talk to the gnunet-service-arm running on the same uid) gnunet-identity -d hangs, too. So apparently my way of starting the arm service manually is incorrect. But how? |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-05-30 07:49 | lynX | New Issue | |
| 2016-05-30 07:49 | lynX | Status | new => assigned |
| 2016-05-30 07:49 | lynX | Assigned To | => tg |
| 2016-05-30 07:49 | lynX | File Added: psycit | |
| 2016-05-30 15:40 | tg | Note Added: 0010779 | |
| 2016-05-30 16:50 | lynX | Note Added: 0010780 | |
| 2016-05-30 17:10 | tg | Note Added: 0010781 | |
| 2016-05-30 18:25 | tg | Note Edited: 0010781 | |
| 2016-05-30 18:27 | lynX | Note Added: 0010782 | |
| 2016-05-30 18:34 | tg | Note Added: 0010783 | |
| 2016-05-30 18:43 | lynX | Note Added: 0010784 | |
| 2016-05-30 18:52 | tg | Note Added: 0010785 | |
| 2016-05-30 19:07 | tg | Note Edited: 0010785 | |
| 2016-05-30 19:07 | tg | Note Edited: 0010785 | |
| 2016-05-30 19:10 | tg | Note Edited: 0010785 | |
| 2016-05-30 19:37 | tg | Note Added: 0010788 | |
| 2016-05-30 19:40 | tg | Note Added: 0010789 | |
| 2016-05-30 19:41 | tg | Note Edited: 0010788 | |
| 2016-05-30 19:45 | tg | Note Edited: 0010785 | |
| 2016-05-30 19:46 | tg | Note Added: 0010790 | |
| 2016-05-30 19:46 | tg | Note Edited: 0010790 | |
| 2016-05-30 19:49 | tg | Note Edited: 0010789 | |
| 2016-05-30 21:05 | lynX | Note Added: 0010791 | |
| 2016-05-30 21:26 | tg | Note Edited: 0010788 | |
| 2016-05-31 13:53 | lynX | Note Added: 0010810 | |
| 2016-05-31 19:29 | tg | Note Added: 0010821 | |
| 2016-05-31 19:32 | tg | Note Edited: 0010821 | |
| 2016-05-31 20:27 | lynX | Note Added: 0010822 | |
| 2016-06-09 14:21 | lynX | Summary | How is the pubsub (gnunet-social) API/CLI supposed to work? => pubsub (gnunet-social) does not work with separated system/user configs |
| 2016-06-09 14:21 | lynX | Description Updated | |
| 2018-06-07 01:14 | Christian Grothoff | Assigned To | tg => |
| 2018-06-07 01:14 | Christian Grothoff | Status | assigned => confirmed |
| 2018-06-07 01:14 | Christian Grothoff | Target Version | Git master => |
| 2019-02-12 09:12 | Christian Grothoff | Project | GNUnet => secushare |
| 2019-02-12 09:12 | Christian Grothoff | Category | social service => General |
| 2019-02-12 09:13 | Christian Grothoff | Category | General => social |
