View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005371||GNUnet||GNS||public||2018-06-28 12:33||2019-02-28 11:17|
|Product Version||SVN HEAD|
|Target Version||0.11.0||Fixed in Version||0.11.0|
|Summary||0005371: Linux boot process shows error message from GNS integration (and may freeze system)|
|Description||When GNS is activated in nsswitch.conf, it gets executed very early|
during the boot process of openrc/gentoo. Presumably that will also
be the case for other OS. The following message appears:
"Failed to expand `$HOME': environment variable `HOME' not set"
which is in our util/strings.c::GNUNET_STRINGS_filename_expand().
In my case the system froze after this message and I had to
ask a friend to make me a recovery USB stick to clean it up,
but that could have been because of having used an older copy
of nsswitch.conf which didn't include "myhostname".
|Additional Information||I presume the strategy should be to have GNS bail out when the|
system hasn't finished booting.
|Tags||No tags attached.|
I've modified the UNIXPATH logic to complain "harder" if the UNIXPATH given includes $HOME and $HOME-expansion fails.
I've modified identity_api_lookup.c to fail hard(er) if the connection to the identity service (first thing gnunet-gns does) fails for sure.
I did *not* (yet) add a timeout as that seems dangerous (would impose time limits even if GNUnet is up).
It would be great to have the full line of the error message above, including in particular which _process_ reports the issue about $HOME.
I did not reproduce the issue (or verify the fix), would be great if lynX would do this.
lynX, which runlevel is your gnunet service started at?
The default in my Gentoo is to have /etc/init.d/gnunet at Runlevel "default".
However as I told you this weekend, the service is acting like Schroedinger's service, it is always reporting "crashed" although it is "alive and running".
# overwritten by GNUnet.. you may want to merge instead
passwd: compat files
shadow: compat files
group: compat files
hosts: files gns [NOTFOUND=return] dns myhostname
networks: files dns
services: db files
protocols: db files
rpc: db files
ethers: db files
I was not able to severely damage the boot sequence under OpenRC 0.38.3
||lynX any update on this? Did you try it after Grothoff made the changes as stated in the above comment 0005371:0013317 ?|
||ng0, I'd suggest filing a separate issue for your service bug[s], so we can track it more clearly.|
||lynX, your feedback would be highly desired...|
||Closing as presumably fixed, unable to reproduce, reporter not responsive.|
|2018-06-28 12:33||lynX||New Issue|
|2018-06-30 00:48||Christian Grothoff||Assigned To||=> Christian Grothoff|
|2018-06-30 00:48||Christian Grothoff||Status||new => assigned|
|2018-06-30 00:48||Christian Grothoff||Priority||none => urgent|
|2018-06-30 00:48||Christian Grothoff||Severity||text => block|
|2018-07-01 19:43||Christian Grothoff||Note Added: 0013120|
|2018-07-01 19:43||Christian Grothoff||Assigned To||Christian Grothoff => lynX|
|2018-07-01 19:43||Christian Grothoff||Status||assigned => feedback|
|2018-11-04 15:45||ng0||Note Added: 0013317|
|2019-01-28 04:06||dvn||Project||GNUnet => doodle|
|2019-01-28 04:06||dvn||Category||GNS => General|
|2019-01-28 19:37||Christian Grothoff||Project||doodle => GNUnet|
|2019-01-28 19:46||Christian Grothoff||Category||General => GNS|
|2019-01-28 22:48||dvn||Note Added: 0013506|
|2019-01-28 22:51||dvn||Note Added: 0013507|
|2019-02-13 23:28||Christian Grothoff||Note Added: 0013722|
|2019-02-16 14:44||Christian Grothoff||Status||feedback => resolved|
|2019-02-16 14:44||Christian Grothoff||Resolution||open => fixed|
|2019-02-16 14:44||Christian Grothoff||Fixed in Version||=> 0.11.0|
|2019-02-16 14:44||Christian Grothoff||Note Added: 0013817|
|2019-02-28 11:17||Christian Grothoff||Status||resolved => closed|