After upgrading from storjshare-cli to sotorjshare-daemon, I got this:

root@JGI02:~# storjshare start --config /root/config.json
Secp256k1 bindings are not compiled. Pure JS implementation will be used.

  * starting share with config at /root/config.json
root@JGI02:~# storjshare status
stream.js:74
      throw er; // Unhandled stream error in pipe.
      ^

TypeError: Cannot read property 'toString' of undefined
    at /root/.nvm/versions/node/v6.9.1/lib/node_modules/storjshare-daemon/node_modules/cli-table/lib/index.js:182:26
    at Array.forEach (native)
    at generateRow (/root/.nvm/versions/node/v6.9.1/lib/node_modules/storjshare-daemon/node_modules/cli-table/lib/index.js:181:11)
    at /root/.nvm/versions/node/v6.9.1/lib/node_modules/storjshare-daemon/node_modules/cli-table/lib/index.js:275:16
    at Table.forEach (native)
    at Table.toString (/root/.nvm/versions/node/v6.9.1/lib/node_modules/storjshare-daemon/node_modules/cli-table/lib/index.js:258:10)
    at /root/.nvm/versions/node/v6.9.1/lib/node_modules/storjshare-daemon/bin/storjshare-status.js:51:30
    at Proto.apply (/root/.nvm/versions/node/v6.9.1/lib/node_modules/storjshare-daemon/node_modules/dnode-protocol/index.js:123:13)
    at Proto.handle (/root/.nvm/versions/node/v6.9.1/lib/node_modules/storjshare-daemon/node_modules/dnode-protocol/index.js:99:19)
    at D.dnode.handle (/root/.nvm/versions/node/v6.9.1/lib/node_modules/storjshare-daemon/node_modules/dnode/lib/dnode.js:140:21)
root@JGI02:~# storjshare status

┌──────────────────────────────────────────┬─────────┬────────┬───────┬──────────┐
│ Node ID                                  │ Status  │ Uptime │ Peers │ % Shared │
├──────────────────────────────────────────┼─────────┼────────┼───────┼──────────┤
│ f**************************************9 │ stopped │ 17s    │ 0     │ ...      │
└──────────────────────────────────────────┴─────────┴────────┴───────┴──────────┘

Note that the daemon stops anyway (that's another bug) and is not stopped by the status command.

Package Versions

Replace the values below using the output from storjshare --version.

 * daemon: 2.1.0, core: 6.0.13, protocol: 1.1.0

Replace the values below using the output from node --version.

6.9.2

Expected Behavior

Startup speeds should be similar between the old CLI and the current Daemon approach.

Actual Behavior

I use to be able to start up 1160 nodes in slight under 20 minutes, simply by invoking a startup in backgroun followed by a 1 second sleep (in order to avoid trashing the OS). All nodes would then run as expected.

Using the daemon on the same system, each startup takes 8-9 seconds, requiring over 3 hours to spin up all 1160 nodes. Attempts to start in parallel, by running the command in background and spawning them 1 second apart like what was done with the CLI, appears to work, although nodes get started out of order and still apparently only one at a time, 8-9 seconds apart - by the time all where done, over 500 had disappeared

Steps to Reproduce

Please include the steps the reproduce the issue, numbered below. Include as
much detail as possible.

1. ...
2. ...
3. ...

Still don't know how to deal with this fuckery, see nodejs/node#9367

Package Versions

Replace the values below using the output from storjshare --version.

2.0.4

Replace the values below using the output from node --version.

v6.9.4

Expected Behavior

Please describe the program's expected behavior.

First rule for a farmer: Don't lose your private key or all shards are lost. -> Don't lose your config.json file. Default location should be somewhere in my home directory. Best place would be ~/.config/storjshare/shares/<nodeID>/config.json. That is the default folder created by storjshare.

Actual Behavior

Please describe the program's actual behavior. Please include any stack traces
or log output in the back ticks below.

root@storj:~# storjshare create --sjcx ...

  * configuration written to /opt/tmp/636ac391e41f6965381d17b4b22d96b5dc36c470.json

Steps to Reproduce

Please include the steps the reproduce the issue, numbered below. Include as
much detail as possible.

1. Run storjshare create with minimum options.

I'm running storjshare-daemon 2.1.2 under OXS Sierra.
II'm using the storjshare-load command in order to load my (meta)-configuration ...
daemon starting, then It crashes.
When I invoke the storjshare status command I've got this error message :

==========================================

MacMini-de-Admin:~ Administrateur$ storjshare status
fs.js:640
return binding.open(pathModule._makeLong(path), stringToFlags(flags), mode);
^

Error: ENFILE: file table overflow, open '/Users/Administrateur/.nvm/versions/node/v6.9.1/lib/node_modules/storjshare-daemon/node_modules/bitcore-lib/lib/uri.js'
at Error (native)
at Object.fs.openSync (fs.js:640:18)
at Object.fs.readFileSync (fs.js:508:33)
at Object.Module._extensions..js (module.js:578:20)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at Object. (/Users/Administrateur/.nvm/versions/node/v6.9.1/lib/node_modules/storjshare-daemon/node_modules/bitcore-lib/index.js:57:15)

• Level/leveldown#340 is merged
• v1.6.0 is coming (Level/leveldown#342)

Remember to point back upstream.

Package Versions

Replace the values below using the output from storjshare --version.

2.0.1

Replace the values below using the output from node --version.

v6.9.4

OS: windows 10

Expected Behavior

Start running the daemon.

Actual Behavior

Try to run the generated config results in an error.

C:\Users\Meije>storjshare start --config E:\StorjCLI\config.json

  * daemon is not running, starting...
module.js:471
    throw err;
    ^

Error: Cannot find module 'weak'
    at Function.Module._resolveFilename (module.js:469:15)
    at Function.Module._load (module.js:417:25)
    at Module.require (module.js:497:17)
    at require (internal/module.js:20:19)
    at new D (C:\Users\Meije\AppData\Roaming\npm\node_modules\storjshare-daemon\node_modules\dnode\index.js:28:20)
    at Function.exports.connect (C:\Users\Meije\AppData\Roaming\npm\node_modules\storjshare-daemon\node_modules\dnode\index.js:12:13)
    at Object.<anonymous> (C:\Users\Meije\AppData\Roaming\npm\node_modules\storjshare-daemon\bin\storjshare-start.js:24:20)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)
    at Module.runMain (module.js:604:10)
    at run (bootstrap_node.js:394:7)
    at startup (bootstrap_node.js:149:9)
    at bootstrap_node.js:509:3

C:\Users\Meije>

Steps to Reproduce

Please include the steps the reproduce the issue, numbered below. Include as
much detail as possible.

Generate a new config.
Try to run the generated config.

Package Versions

Replace the values below using the output from storjshare --version.

  * daemon: 2.1.0, core: 6.0.14, protocol: 1.1.0

Replace the values below using the output from node --version.

7.4.0

Expected Behavior

First start, trying to fetch status of any nodes running with storjshare status.

Actual Behavior

root@subwolf-nas:~# storjshare status 

  * daemon is not running, starting...
stream.js:74
      throw er; // Unhandled stream error in pipe.
      ^

Error: connect ECONNREFUSED 127.0.0.1:45015
    at Object.exports._errnoException (util.js:1022:11)
    at exports._exceptionWithHostPort (util.js:1045:20)
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1090:14)
root@subwolf-nas:~# 
root@subwolf-nas:~# 
root@subwolf-nas:~# storjshare status 

┌─────────────────────────────────────────────┬──────────┬──────────┬──────────┬──────────┬──────────┐
│ Share                                       │ Status   │ Uptime   │ Restarts │ Peers    │ Shared   │
└─────────────────────────────────────────────┴──────────┴──────────┴──────────┴──────────┴──────────┘
root@subwolf-nas:~# 

Works fine after the first try. Maybe wait a a bit longer if the daemon is not running?

Package Versions

Replace the values below using the output from storjshare --version.

* daemon: 2.2.0, core: 6.1.1, protocol: 1.1.0

Replace the values below using the output from node --version.

6.9.2

Expected Behavior

Storj node's memory utilization should remain within operational bounds (e.g. Can vary, but should return to some base stat occassionally)

Actual Behavior

Now that the network "chatter" bug has been somewhat tamed I can run hundreds of nodes again. This enables me to see patterns between nodes. Currently seeing memory unevenly leak between shares (linux node instances). See the "top" paste below and note that some nodes are using over 4GB of memory while others are under 1.5GB. Base appears to be around 1.26GB as per 2nd screenshot. This system has been running 694 nodes running for approximately 24 hours on a 56 core (hyperthreaded) 256GB dual Xeon box.

Sorted by memory usage: http://puu.sh/tNlX2/8ce32ec94a.png

Unsorted showing base usage: http://puu.sh/tNmIV/a529f79693.png

Suspect the leak never really went away, it was just hidden by the resent network activity slowdown.

Steps to Reproduce

Please include the steps the reproduce the issue, numbered below. Include as
much detail as possible.

1. Run lots of nodes for a day
2. Observe memory growth
3. ...

Please provide a port # option and a # Tunnels option in the Create command. Of course, if #tunnels = 0, no tunnel ports should be defined, nor should a tunnel server port. Likely, if say #tunnels = 8 the min,max settings should be adjusted accordingly.

Ah... and while your at it: an option to specify storage size.

... and perhaps a "restart all" command...

... and the ability to set public ip via flag.

Package Versions

Replace the values below using the output from storjshare --version.

 * daemon: 2.1.2, core: 6.0.15, protocol: 1.1.0

Replace the values below using the output from node --version.

6.9.2

Expected Behavior

Access to deamon should be restricted by userid that launches it.

Actual Behavior

Please describe the program's actual behavior. Please include any stack traces
or log output in the back ticks below.

Currently all users on a Linux box can fully control the storjshare daemon, issuing killall's at will.  Access is only limited by OS filesystem permissions on things like log files.

The ability of any user on the system to terminate the activities started by another user is not appropriate.

Steps to Reproduce

Please include the steps the reproduce the issue, numbered below. Include as
much detail as possible.

1. ...
2. ...
3. ...

Package Versions

Replace the values below using the output from storjshare --version.

2.0.4

Replace the values below using the output from node --version.

v6.9.4

Expected Behavior

Please describe the program's expected behavior.

storjshare --version should print out the storj-lib and protocol version

Actual Behavior

Please describe the program's actual behavior. Please include any stack traces
or log output in the back ticks below.

storjshare --version
2.0.4

Package Versions

Replace the values below using the output from storjshare --version.

2.1.2

Replace the values below using the output from node --version.

6.9.4 LTS

Expected Behavior

Please describe the program's expected behavior.
Giving the command to start a node -- > Behavior should be = Node started ...

Actual Behavior

Please describe the program's actual behavior. Please include any stack traces
or log output in the back ticks below.

Node does not start and gives the following error :

module.js:471
throw err;
^

Error: Cannot find module 'weak'
at Function.Module._resolveFilename (module.js:469:15)
at Function.Module._load (module.js:417:25)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at new D (C:\Users\user\AppData\Roaming\npm\node_modules\storjshare-daemon\n
ode_modules\dnode\index.js:28:20)
at Function.exports.connect (C:\Users\user\AppData\Roaming\npm\node_modules
storjshare-daemon\node_modules\dnode\index.js:12:13)
at Object. (C:\Users\user\AppData\Roaming\npm\node_modules\storjs
hare-daemon\bin\storjshare-killall.js:13:20)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)

### Steps to Reproduce

Please include the steps the reproduce the issue, numbered below. Include as
much detail as possible.

Simply give the start command ... 

Well the problem happened on windows 7 professional 64 bit and 32 bit (two different machines) .

The first time the problem occurred I deleted (uninstalled) Node.js , git , storjshare , windows-build-tools , even after and re installing the error occurred again .... 

While installing the storjshare I get those warnings (every-time I install) : 
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\storjsh
are-daemon\node_modules\weak):
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] install: `node-gyp re
build`
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: Exit status 1

OS = OSX (Sierra)
storjshare --version => deamon : 2.1.0, core : 6.0.12, protocol : 1.0.0

MacMini-de-Admin:DataFarming Administrateur$ storjshare save --snapshot /Users/Administrateur/DataFarming/conf.txt
/Users/Administrateur/.nvm/versions/node/v6.9.1/lib/node_modules/storjshare-daemon/bin/storjshare-save.js:31
rpc.save(storjshare_save.snapshot, (err) => {
^

TypeError: rpc.save is not a function
at D. (/Users/Administrateur/.nvm/versions/node/v6.9.1/lib/node_modules/storjshare-daemon/bin/storjshare-save.js:31:7)
at emitTwo (events.js:106:13)
at D.emit (events.js:191:7)
at Proto. (/Users/Administrateur/.nvm/versions/node/v6.9.1/lib/node_modules/storjshare-daemon/node_modules/dnode/lib/dnode.js:53:14)
at emitOne (events.js:96:13)
at Proto.emit (events.js:188:7)
at Proto.handleMethods (/Users/Administrateur/.nvm/versions/node/v6.9.1/lib/node_modules/storjshare-daemon/node_modules/dnode-protocol/index.js:118:10)
at Proto.handle (/Users/Administrateur/.nvm/versions/node/v6.9.1/lib/node_modules/storjshare-daemon/node_modules/dnode-protocol/index.js:77:14)
at D.dnode.handle (/Users/Administrateur/.nvm/versions/node/v6.9.1/lib/node_modules/storjshare-daemon/node_modules/dnode/lib/dnode.js:140:21)
at D.dnode.write (/Users/Administrateur/.nvm/versions/node/v6.9.1/lib/node_modules/storjshare-daemon/node_modules/dnode/lib/dnode.js:106:22)

The new release of storjshare-daemon provide the node path as information under the node id information. The problem is that the column ins not wide enough to see the end of the path (which is not very useful). See attached file.

If storjshare-logs is run without a nodeid it shows the output of all running nodes like pm2 logs

Package Versions

Replace the values below using the output from storjshare --version.

2.0.0

Replace the values below using the output from node --version.

v6.9.4

Expected Behavior

Run start running the daemon.

Actual Behavior

Try to run the generated config results in an error.

C:\Users\work>storjshare start --config "C:\Users\work\AppData\Local\Temp\8a84785601268ae7501c788457549098e98aef42.json"
undefined:56
  "loggerOutputFile": "C:\Users\work\.config\storjshare\logs\8a84785601268ae7501c788457549098e98aef42.log",
                          ^

SyntaxError: Unexpected token U in JSON at position 727
    at Object.parse (native)
    at exports.parse (C:\Users\work\AppData\Roaming\nvm\v6.9.2\node_modules\storjshare-daemon\node_modules\rc\lib\utils.js:15:17)
    at addConfigFile (C:\Users\work\AppData\Roaming\nvm\v6.9.2\node_modules\storjshare-daemon\node_modules\rc\index.js:31:20)
    at module.exports (C:\Users\work\AppData\Roaming\nvm\v6.9.2\node_modules\storjshare-daemon\node_modules\rc\index.js:47:20)
    at Object.<anonymous> (C:\Users\work\AppData\Roaming\nvm\v6.9.2\node_modules\storjshare-daemon\lib\config\daemon.js:16:31)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)

So if you add backslashes to the path you still get:

C:\Users\work>storjshare start --config "C:\Users\work\AppData\Local\Temp\8a84785601268ae7501c788457549098e98aef42.json"
undefined:58
  "storagePath": "D:\",


SyntaxError: Unexpected token
 in JSON at position 841
    at Object.parse (native)
    at exports.parse (C:\Users\work\AppData\Roaming\nvm\v6.9.2\node_modules\storjshare-daemon\node_modules\rc\lib\utils.js:15:17)
    at addConfigFile (C:\Users\work\AppData\Roaming\nvm\v6.9.2\node_modules\storjshare-daemon\node_modules\rc\index.js:31:20)
    at module.exports (C:\Users\work\AppData\Roaming\nvm\v6.9.2\node_modules\storjshare-daemon\node_modules\rc\index.js:47:20)
    at Object.<anonymous> (C:\Users\work\AppData\Roaming\nvm\v6.9.2\node_modules\storjshare-daemon\lib\config\daemon.js:16:31)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)

After you add the backslashes for the storage path too:

C:\Users\work>storjshare start --config "C:\Users\work\AppData\Local\Temp\8a84785601268ae7501c788457549098e98aef42.json"

  failed to start share, reason: failed to read config at C:\Users\work\C:\Users\work\AppData\Local\Temp\8a84785601268ae7501c788457549098e98aef42.json

Steps to Reproduce

Please include the steps the reproduce the issue, numbered below. Include as
much detail as possible.

1. Generate the config.
2. Try to run the generated config.
3. Add double blackslashes to loggerOutputFile
4. Add double blackslashes to storagepath
5. Looks for config in the wrong place.

Package Versions

Replace the values below using the output from storjshare --version.

  * daemon: 2.1.2, core: 6.0.15, protocol: 1.1.0

Replace the values below using the output from node --version.

6.9.2

Expected Behavior

storjshare save command should always work

Actual Behavior

storj@i5serv ~ $ storjshare save
/usr/lib64/node_modules/storjshare-daemon/bin/storjshare-save.js:31
  rpc.save(storjshare_save.snapshot, (err) => {
      ^

TypeError: rpc.save is not a function
    at D.<anonymous> (/usr/lib64/node_modules/storjshare-daemon/bin/storjshare-save.js:31:7)
    at emitTwo (events.js:106:13)
    at D.emit (events.js:191:7)
    at Proto.<anonymous> (/usr/lib64/node_modules/storjshare-daemon/node_modules/dnode/lib/dnode.js:53:14)
    at emitOne (events.js:96:13)
    at Proto.emit (events.js:188:7)
    at Proto.handleMethods (/usr/lib64/node_modules/storjshare-daemon/node_modules/dnode-protocol/index.js:118:10)
    at Proto.handle (/usr/lib64/node_modules/storjshare-daemon/node_modules/dnode-protocol/index.js:77:14)
    at D.dnode.handle (/usr/lib64/node_modules/storjshare-daemon/node_modules/dnode/lib/dnode.js:140:21)
    at D.dnode.write (/usr/lib64/node_modules/storjshare-daemon/node_modules/dnode/lib/dnode.js:106:22)

Since I've successfully used save before (on a different machine), my guess is this is realted to one share being stopped...

storj@i5serv ~ $ storjshare status

┌─────────────────────────────────────────────┬──────────┬──────────┬──────────┬──────────┬──────────┐
│ Share                                       │ Status   │ Uptime   │ Restarts │ Peers    │ Shared   │
├─────────────────────────────────────────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ acd0979d5f30adf78ee916089728c30ed9fbf1f4    │ running  │ 40m 41s  │ 15       │ 155      │ 564.8MB  │
│   → /storj/node03                           │          │          │          │          │ (2%)     │
├─────────────────────────────────────────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ 11101de0a7edef3348c043ce4296f91261d1e747    │ stopped  │ 55m 5s   │ 30       │ 78       │ 16.71MB  │
│   → /storj/node00                           │          │          │          │          │ (0%)     │
├─────────────────────────────────────────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ 0842ead3a1e08f72032792ea0fc30bdbfc5d2a15    │ running  │ 41m 4s   │ 14       │ 160      │ 584.11MB │
│   → /storj/node01                           │          │          │          │          │ (2%)     │
├─────────────────────────────────────────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ 065428feab8f78f887d45196a53f9f4c2768de59    │ running  │ 41m 4s   │ 12       │ 180      │ 327.02MB │
│   → /storj/node02                           │          │          │          │          │ (1%)     │
├─────────────────────────────────────────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ 0657b98c8b22112847abdd66d529c08de1675576    │ running  │ 41m 4s   │ 11       │ 181      │ 301.42MB │
│   → /storj/node04                           │          │          │          │          │ (1%)     │
├─────────────────────────────────────────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ cf64503c959b1240c73ff516e3e878954e94fa46    │ running  │ 40m 8s   │ 13       │ 162      │ 408.19MB │
│   → /storj/node05                           │          │          │          │          │ (1%)     │
├─────────────────────────────────────────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ b05c859969f4611c66fdb84438ab746b15406e4e    │ running  │ 41m 15s  │ 17       │ 147      │ 2MB      │
│   → /storj/node06                           │          │          │          │          │ (0%)     │
├─────────────────────────────────────────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ ed30be8d70025ed00d2f8fc57f599e7e20015d93    │ running  │ 41m 36s  │ 10       │ 162      │ 285.33MB │
│   → /storj/node07                           │          │          │          │          │ (1%)     │
├─────────────────────────────────────────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ f100019c3598566f32cf0e4331f1df9a0af33e28    │ running  │ 41m 4s   │ 13       │ 145      │ 3.46MB   │
│   → /storj/node08                           │          │          │          │          │ (0%)     │
├─────────────────────────────────────────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ d717d514b327f6211d53dc653c5111a02a32feef    │ running  │ 41m 15s  │ 14       │ 144      │ 320.89MB │
│   → /storj/node09                           │          │          │          │          │ (1%)     │
├─────────────────────────────────────────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ 1fa56da183e0f58d0ffc465559e32f6315a15473    │ running  │ 41m 15s  │ 8        │ 160      │ 463.15MB │
│   → /storj/node10                           │          │          │          │          │ (1%)     │
├─────────────────────────────────────────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ e985c145e425bb61566676780d4631a88d8726f9    │ running  │ 41m 10s  │ 14       │ 148      │ 78.55MB  │
│   → /storj/node11                           │          │          │          │          │ (0%)     │
├─────────────────────────────────────────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ e6c88b300873c92a831d4e8770bf13285b8c638e    │ running  │ 40m 8s   │ 17       │ 146      │ 288.68MB │
│   → /storj/node12                           │          │          │          │          │ (1%)     │
├─────────────────────────────────────────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ 3291d205b786bfdd33e814be63f4a771244b77ba    │ running  │ 41m 39s  │ 13       │ 163      │ 246.99MB │
│   → /storj/node13                           │          │          │          │          │ (1%)     │
├─────────────────────────────────────────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ b98858b98cf851103485d4de4eb33bfd58b0b269    │ running  │ 41m 39s  │ 12       │ 164      │ 190.25MB │
│   → /storj/node14                           │          │          │          │          │ (1%)     │
├─────────────────────────────────────────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ ab62b2de9aa7ae04925700d1f2423129543e55db    │ running  │ 40m 54s  │ 12       │ 154      │ 284.02MB │
│   → /storj/node15                           │          │          │          │          │ (1%)     │
└─────────────────────────────────────────────┴──────────┴──────────┴──────────┴──────────┴──────────┘

Steps to Reproduce

Please include the steps the reproduce the issue, numbered below. Include as
much detail as possible.

1. ...
2. ...
3. ...

Package Versions

Replace the values below using the output from storjshare --version.

daemon: 2.2.0
core: 6.1.1
protocol: 1.1.0

Replace the values below using the output from node --version.

v6.9.4

Expected Behavior

Please describe the program's expected behavior.

root@Server011:~# grep "storageAllocation" /root/.config/storjshare/farmer-config.json    
        "storageAllocation": "0B",

root@Server011:~# storjshare start --config /root/.config/storjshare/farmer-config.json                      

  * starting share with config at /root/.config/storjshare/farmer-config.json

root@Server011:~# storjshare status
┌─────────────────────────────────────────────┬──────────┬──────────┬──────────┬──────────┬──────────┐
│ Share                                       │ Status   │ Uptime   │ Restarts │ Peers    │ Shared   │
├─────────────────────────────────────────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ bbb93df17ce4baa7a32c18f653184b9ae4876cb8    │ running  │ 8s       │ 0        │ 0        │  0B      │
│   → /root/storjshare-daemon-data            │          │          │          │          │ (100%)   │
└─────────────────────────────────────────────┴──────────┴──────────┴──────────┴──────────┴──────────┘

Actual Behavior

Please describe the program's actual behavior. Please include any stack traces or log output in the back ticks below.

root@Server011:~# grep "storageAllocation" /root/.config/storjshare/farmer-config.json    
        "storageAllocation": "0B",
root@Server011:~# grep "storageAllocation" /root/.config/storjshare/farmer-config.json    
        "storageAllocation": "0",
root@Server011:~# grep "storageAllocation" /root/.config/storjshare/farmer-config.json    
        "storageAllocation": null,


root@Server011:~# storjshare start --config /root/.config/storjshare/farmer-config.json

  failed to start share, reason: invalid storage size

Currently running +1300 dæmonds dedicated to help farmers who only have access to the storj network via tunnel. Therefor not so interested in catching shards with these dæmonds :)

//Th3Van

It would be very useful to have at least those 2 information in the table produced by the storjshare status command :

1. The path to the node (by alphabetical order in column 1# if possible)
2. The size (in octet) of the directory

Package Versions

Replace the values below using the output from storjshare --version.

daemon: 2.1.0, core: 6.0.14, protocol: 1.1.0

Replace the values below using the output from node --version.

7.4.0

Expected Behavior

Everything runs as normal.

Actual Behavior

Please describe the program's actual behavior. Please include any stack traces
or log output in the back ticks below.

{"level":"info","message":"replying to message to cccdf4d7e72c4e9b733fa81b3c2e38f9df7926a9","timestamp":"2017-01-24T09:38:03.408Z"}
/usr/lib/node_modules/storjshare-daemon/node_modules/storj-lib/lib/storage/manager.js:212
  if (this._options.disableReaper) {
          ^

TypeError: Cannot read property '_options' of undefined
    at StorageManager._initShardReaper (/usr/lib/node_modules/storjshare-daemon/node_modules/storj-lib/lib/storage/manager.js:212:11)
    at Readable.<anonymous> (/usr/lib/node_modules/storjshare-daemon/node_modules/storj-lib/lib/storage/manager.js:178:5)
    at emitNone (events.js:86:13)
    at Readable.emit (events.js:185:7)
    at endReadableNT (/usr/lib/node_modules/storjshare-daemon/node_modules/readable-stream/lib/_stream_readable.js:926:12)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickDomainCallback (internal/process/next_tick.js:122:9)

Steps to Reproduce

Please include the steps the reproduce the issue, numbered below. Include as
much detail as possible.

1. ... Just let it run.

On the first run I would like to start them one by one and call a storjshare command safe running nodes (replace the name with a better one) to safe all running nodes on a meta config. Later I would like to start all nodes at once with storjshare restart safed nodes (replace that one as well)

That will allow me to handle all nodes with a simple crontab / autostart entry.

Package Versions

Replace the values below using the output from storjshare --version.

 daemon: 2.2.0, core: 6.1.2, protocol: 1.1.0

Replace the values below using the output from node --version.

6.9.4

Expected Behavior

Be able to start more than one node.

Actual Behavior

First node starts as expected; trying to start second node results in non-stop attempts to start and stop node

First node starts (95aa3bf33532518a7d07f89d75e40743587a2cd5):

storjshare daemon --foreground
{"level":"info","message":"attempting to start share with config at path /Users/barbara/.config/storjshare/configs/95aa3bf33532518a7d07f89d75e40743587a2cd5.json","timestamp":"2017-02-06T18:08:12.503Z"}
{"level":"info","message":"got status query","timestamp":"2017-02-06T18:08:22.668Z"}

Second node keeps restarting (48761767997bd4a674d0cd230f6b79ce6ae6e01b):

{"level":"info","message":"attempting to start share with config at path /Users/barbara/.config/storjshare/configs/48761767997bd4a674d0cd230f6b79ce6ae6e01b.json","timestamp":"2017-02-06T18:10:33.170Z"}
{"level":"info","message":"share 48761767997bd4a674d0cd230f6b79ce6ae6e01b exited with code 1","timestamp":"2017-02-06T18:10:34.171Z"}
{"level":"info","message":"attempting to restart share with node id 48761767997bd4a674d0cd230f6b79ce6ae6e01b","timestamp":"2017-02-06T18:10:34.171Z"}
{"level":"info","message":"attempting to stop share with node id 48761767997bd4a674d0cd230f6b79ce6ae6e01b","timestamp":"2017-02-06T18:10:34.172Z"}
{"level":"info","message":"attempting to start share with config at path /Users/barbara/.config/storjshare/configs/48761767997bd4a674d0cd230f6b79ce6ae6e01b.json","timestamp":"2017-02-06T18:10:34.175Z"}
{"level":"info","message":"share 48761767997bd4a674d0cd230f6b79ce6ae6e01b exited with code 1","timestamp":"2017-02-06T18:10:35.172Z"}
{"level":"info","message":"attempting to restart share with node id 48761767997bd4a674d0cd230f6b79ce6ae6e01b","timestamp":"2017-02-06T18:10:35.173Z"}
{"level":"info","message":"attempting to stop share with node id 48761767997bd4a674d0cd230f6b79ce6ae6e01b","timestamp":"2017-02-06T18:10:35.173Z"}
{"level":"info","message":"attempting to start share with config at path /Users/barbara/.config/storjshare/configs/48761767997bd4a674d0cd230f6b79ce6ae6e01b.json","timestamp":"2017-02-06T18:10:35.177Z"}
{"level":"info","message":"share 48761767997bd4a674d0cd230f6b79ce6ae6e01b exited with code 1","timestamp":"2017-02-06T18:10:36.175Z"}
{"level":"info","message":"attempting to restart share with node id 48761767997bd4a674d0cd230f6b79ce6ae6e01b","timestamp":"2017-02-06T18:10:36.175Z"}
{"level":"info","message":"attempting to stop share with node id 48761767997bd4a674d0cd230f6b79ce6ae6e01b","timestamp":"2017-02-06T18:10:36.175Z"}
{"level":"info","message":"attempting to start share with config at path /Users/barbara/.config/storjshare/configs/48761767997bd4a674d0cd230f6b79ce6ae6e01b.json","timestamp":"2017-02-06T18:10:36.178Z"}
{"level":"info","message":"share 48761767997bd4a674d0cd230f6b79ce6ae6e01b exited with code 1","timestamp":"2017-02-06T18:10:37.142Z"}
{"level":"info","message":"attempting to restart share with node id 48761767997bd4a674d0cd230f6b79ce6ae6e01b","timestamp":"2017-02-06T18:10:37.142Z"}
{"level":"info","message":"attempting to stop share with node id 48761767997bd4a674d0cd230f6b79ce6ae6e01b","timestamp":"2017-02-06T18:10:37.142Z"}
{"level":"info","message":"attempting to start share with config at path /Users/barbara/.config/storjshare/configs/48761767997bd4a674d0cd230f6b79ce6ae6e01b.json","timestamp":"2017-02-06T18:10:37.145Z"}
{"level":"info","message":"share 48761767997bd4a674d0cd230f6b79ce6ae6e01b exited with code 1","timestamp":"2017-02-06T18:10:38.123Z"}
{"level":"info","message":"attempting to restart share with node id 48761767997bd4a674d0cd230f6b79ce6ae6e01b","timestamp":"2017-02-06T18:10:38.123Z"}
{"level":"info","message":"attempting to stop share with node id 48761767997bd4a674d0cd230f6b79ce6ae6e01b","timestamp":"2017-02-06T18:10:38.123Z"}

Happens when trying to start nodes in different order as well:

First node starts (48761767997bd4a674d0cd230f6b79ce6ae6e01b):

storjshare daemon --foreground
{"level":"info","message":"attempting to start share with config at path /Users/barbara/.config/storjshare/configs/48761767997bd4a674d0cd230f6b79ce6ae6e01b.json","timestamp":"2017-02-06T18:18:45.558Z"}
{"level":"info","message":"got status query","timestamp":"2017-02-06T18:19:15.181Z"}

Second node starts (95aa3bf33532518a7d07f89d75e40743587a2cd5):

{"level":"info","message":"attempting to start share with config at path /Users/barbara/.config/storjshare/configs/48761767997bd4a674d0cd230f6b79ce6ae6e01b.json","timestamp":"2017-02-06T18:18:45.558Z"}
{"level":"info","message":"got status query","timestamp":"2017-02-06T18:19:15.181Z"}
{"level":"info","message":"attempting to start share with config at path /Users/barbara/.config/storjshare/configs/95aa3bf33532518a7d07f89d75e40743587a2cd5.json","timestamp":"2017-02-06T18:20:11.169Z"}
{"level":"info","message":"share 95aa3bf33532518a7d07f89d75e40743587a2cd5 exited with code 1","timestamp":"2017-02-06T18:20:12.089Z"}
{"level":"info","message":"attempting to restart share with node id 95aa3bf33532518a7d07f89d75e40743587a2cd5","timestamp":"2017-02-06T18:20:12.089Z"}
{"level":"info","message":"attempting to stop share with node id 95aa3bf33532518a7d07f89d75e40743587a2cd5","timestamp":"2017-02-06T18:20:12.089Z"}
{"level":"info","message":"attempting to start share with config at path /Users/barbara/.config/storjshare/configs/95aa3bf33532518a7d07f89d75e40743587a2cd5.json","timestamp":"2017-02-06T18:20:12.093Z"}
{"level":"info","message":"share 95aa3bf33532518a7d07f89d75e40743587a2cd5 exited with code 1","timestamp":"2017-02-06T18:20:13.008Z"}
{"level":"info","message":"attempting to restart share with node id 95aa3bf33532518a7d07f89d75e40743587a2cd5","timestamp":"2017-02-06T18:20:13.008Z"}
{"level":"info","message":"attempting to stop share with node id 95aa3bf33532518a7d07f89d75e40743587a2cd5","timestamp":"2017-02-06T18:20:13.008Z"}
{"level":"info","message":"attempting to start share with config at path /Users/barbara/.config/storjshare/configs/95aa3bf33532518a7d07f89d75e40743587a2cd5.json","timestamp":"2017-02-06T18:20:13.013Z"}
{"level":"info","message":"share 95aa3bf33532518a7d07f89d75e40743587a2cd5 exited with code 1","timestamp":"2017-02-06T18:20:13.913Z"}
{"level":"info","message":"attempting to restart share with node id 95aa3bf33532518a7d07f89d75e40743587a2cd5","timestamp":"2017-02-06T18:20:13.913Z"}
{"level":"info","message":"attempting to stop share with node id 95aa3bf33532518a7d07f89d75e40743587a2cd5","timestamp":"2017-02-06T18:20:13.913Z"}
{"level":"info","message":"attempting to start share with config at path /Users/barbara/.config/storjshare/configs/95aa3bf33532518a7d07f89d75e40743587a2cd5.json","timestamp":"2017-02-06T18:20:13.917Z"}
{"level":"info","message":"share 95aa3bf33532518a7d07f89d75e40743587a2cd5 exited with code 1","timestamp":"2017-02-06T18:20:14.843Z"}
{"level":"info","message":"attempting to restart share with node id 95aa3bf33532518a7d07f89d75e40743587a2cd5","timestamp":"2017-02-06T18:20:14.843Z"}
{"level":"info","message":"attempting to stop share with node id 95aa3bf33532518a7d07f89d75e40743587a2cd5","timestamp":"2017-02-06T18:20:14.843Z"}

Steps to Reproduce

Please include the steps the reproduce the issue, numbered below. Include as
much detail as possible.

1. Start one config
2. Start second config

Package Versions

Replace the values below using the output from storjshare --version.

 * daemon: 2.2.0, core: 6.1.1, protocol: 1.1.0

Replace the values below using the output from node --version.

v6.9.1

Expected Behavior

N/A

Actual Behavior

doNotTraverseNat should get renamed to manualportforwarding, or the other way around.
The description should be changed as well as it can be confusing to non-native english speakers:

// Enables NAT traversal strategies, first UPnP, then reverse HTTP tunnel
// if that fails. Disable if you are public or using dynamic DNS
"doNotTraverseNat": true,

I set this to "false", as the description states "Disable if you are public..." and I'm public, there are no closed ports to the node. It should change to "Enable if you are public.." or "Set as true if you are public..."

Steps to Reproduce

N/A

Hi,

I started with a clean home directory, and nodejs installed in /usr/bin:

storj@misc:~$ export LANG=C
storj@misc:~$ ls -a
.  ..  .bash_history  .bash_logout  .bashrc  .profile  .ssh  .viminfo
storj@misc:~$ grep nvm .bashrc 
storj@misc:~$ nodejs --version
v6.9.2

I installed NVM following instructions in the README:

storj@misc:~$ curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.31.1/install.sh | bash
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  7766  100  7766    0     0   162k      0 --:--:-- --:--:-- --:--:--  164k
=> Downloading nvm from git to '/home/storj/.nvm'
=> Cloning into '/home/storj/.nvm'...
remote: Counting objects: 6072, done.
remote: Total 6072 (delta 0), reused 0 (delta 0), pack-reused 6072
Receiving objects: 100% (6072/6072), 1.71 MiB | 2.49 MiB/s, done.
Resolving deltas: 100% (3750/3750), done.
Checking connectivity... done.
* (detached from v0.31.1)
  master

=> Appending source string to /home/storj/.bashrc
(node:14879) fs: re-evaluating native module sources is not supported. If you are using the graceful-fs module, please update it to a more recent version.
(node:14886) fs: re-evaluating native module sources is not supported. If you are using the graceful-fs module, please update it to a more recent version.
=> Close and reopen your terminal to start using nvm
storj@misc:~$ logout
Connection to misc closed.
progval@bastion:~$ ssh storj@misc
storj@misc:~$ export LANG=C

But then, running nvm install --lts fails:

storj@misc:~$ nvm install --lts
grep: unrecognized option '--lts'
Usage: grep [OPTION]... PATTERN [FILE]...
Try 'grep --help' for more information.
grep: unrecognized option '--lts'
Usage: grep [OPTION]... PATTERN [FILE]...
Try 'grep --help' for more information.
Version '--lts' not found - try `nvm ls-remote` to browse available versions.

Package Versions

OS: windows 10

Replace the values below using the output from storjshare --version.

2.1.0

Replace the values below using the output from node --version.

6.9.4

Expected Behavior

Please describe the program's expected behavior.

Actual Behavior

Please describe the program's actual behavior. Please include any stack traces
or log output in the back ticks below.

C:\Users\Meije>storjshare save
C:\Users\Meije\AppData\Roaming\npm\node_modules\storjshare-daemon\bin\storjshare-save.js:31
  rpc.save(storjshare_save.snapshot, (err) => {
      ^

TypeError: rpc.save is not a function
    at D.<anonymous> (C:\Users\Meije\AppData\Roaming\npm\node_modules\storjshare-daemon\bin\storjshare-save.js:31:7)
    at emitTwo (events.js:106:13)
    at D.emit (events.js:191:7)
    at Proto.<anonymous> (C:\Users\Meije\AppData\Roaming\npm\node_modules\storjshare-daemon\node_modules\dnode\lib\dnode.js:53:14)
    at emitOne (events.js:96:13)
    at Proto.emit (events.js:188:7)
    at Proto.handleMethods (C:\Users\Meije\AppData\Roaming\npm\node_modules\storjshare-daemon\node_modules\dnode-protocol\index.js:118:10)
    at Proto.handle (C:\Users\Meije\AppData\Roaming\npm\node_modules\storjshare-daemon\node_modules\dnode-protocol\index.js:77:14)
    at D.dnode.handle (C:\Users\Meije\AppData\Roaming\npm\node_modules\storjshare-daemon\node_modules\dnode\lib\dnode.js:140:21)
    at D.dnode.write (C:\Users\Meije\AppData\Roaming\npm\node_modules\storjshare-daemon\node_modules\dnode\lib\dnode.js:106:22)

C:\Users\Meije>

After this error it killed my running node. It worked the second time though after restarting the node again, so this was a one-time error so far. The node was running non-stop for 4 days. 

Steps to Reproduce

Please include the steps the reproduce the issue, numbered below. Include as
much detail as possible.

1. Storjshare save
2. Error
3. ...

Package Versions

Replace the values below using the output from storjshare --version.

* daemon: 2.1.2, core: 6.0.15, protocol: 1.1.0

Replace the values below using the output from node --version.

v6.6.0

Actual Behavior

Runs out of memory

{"level":"info","message":"sending PUBLISH message to {\"userAgent\":\"6.0.11\",\"protocol\":\"1.0.0\",\"address\":\"87.120.97.229\",\"port\":5250,\"nodeID\":\"4489beb1eb683a2ef70aaa6bcb6050f6176017b9\",\"lastSeen\":1485137632623}","timestamp":"2017-01-23T02:13:52.624Z"}
{"level":"info","message":"replying to message to 0d9b2cc55a461047fa227f368ceb25b89326d8ba","timestamp":"2017-01-23T02:13:52.656Z"}

<--- Last few GCs --->

  634234 ms: Mark-sweep 1332.7 (1438.4) -> 1332.6 (1438.4) MB, 1123.5 / 8.6 ms [allocation failure] [GC in old space requested].
  635365 ms: Mark-sweep 1332.6 (1438.4) -> 1332.6 (1438.4) MB, 1131.1 / 8.5 ms [allocation failure] [GC in old space requested].
  636516 ms: Mark-sweep 1332.6 (1438.4) -> 1341.8 (1417.4) MB, 1150.1 / 8.6 ms [last resort gc].
  637670 ms: Mark-sweep 1341.8 (1417.4) -> 1351.0 (1417.4) MB, 1154.5 / 8.6 ms [last resort gc].


<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0x6bef58cfb51 <JS Object>
    1: resolve [path.js:~1133] [pc=0x19926c10d0c7] (this=0x55d645e97e1 <an Object with map 0x25575011fab1>)
    2: arguments adaptor frame: 1->0
    3: du [/usr/local/lib/node_modules/storjshare-daemon/node_modules/du/index.js:~7] [pc=0x19926c1d5a06] (this=0x6bef58e60e1 <JS Global Object>,dir=0x21673139e5b1 <String[45]: /mnt/md3/storj/sharddata.kfs/253.s/018753.ldb>,options=0x2e14d9140b21 <an Ob...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [/usr/local/bin/node]
 2: 0x10a3b3c [/usr/local/bin/node]
 3: v8::Utils::ReportApiFailure(char const*, char const*) [/usr/local/bin/node]
 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [/usr/local/bin/node]
 5: v8::internal::Factory::NewRawOneByteString(int, v8::internal::PretenureFlag) [/usr/local/bin/node]
 6: v8::internal::String::SlowFlatten(v8::internal::Handle<v8::internal::ConsString>, v8::internal::PretenureFlag) [/usr/local/bin/node]
 7: v8::internal::Runtime_StringCharCodeAtRT(int, v8::internal::Object**, v8::internal::Isolate*) [/usr/local/bin/node]
 8: 0x19926b4079a7

Steps to Reproduce

I had it running for about 3 days.

Reported by @mohammedioz
storj-archived/core#637

I need to move my drives from Windows which used the GUI to Linux that will use CLI (daemon)

Also please explain the way to configure the daemon for the linux (Changing the IP , choosing the port ...)

Package Versions

Replace the values below using the output from storjshare --version.

* daemon: 2.1.2, core: 6.0.15, protocol: 1.1.0

Replace the values below using the output from node --version.

6.9.2

Expected Behavior

Desire the ability to query via the storjshare command if the daemon is running. DO NOT want it to autostart if its down, since the query may be running on a different userid than the shares are normally spawned on.

Output can be minimal, but please set different return codes for up and down so the status can be checked in script.

Perhaps a "--status" option on the "storjshare daemon" command?

Alternative: have the daemon issue an "autosave" on some configurable timeframe (e.g. "storjshare daemon autosave 600" for a 10 minute event) and autoload upon failure. This, of course, would imply a high level catch be added to capture any future potential outage.

Another alternative: have the daemon create a pid file that an external script could check.

Actual Behavior

The daemon process looks very similar to share processes, with everything being identified by the OS as command "node". Counting "node" processes to see if the daemon is running is crude and relatively expensive on machines with 10's of thousands of processes running.

Steps to Reproduce

Please include the steps the reproduce the issue, numbered below. Include as
much detail as possible.

1. ...
2. ...
3. ...

1- A few users on rocketchat have requested the ability to hide the node window from the taskbar in windows, meaning that they want the node to run in the background. This could be done with something like storjshare --background.
2- We have had some requests to make the storjshare status output dynamic, meaning that the data in the table is updated in real time. This could be done with something like storjshare status --dynamic.

As I understand now clients with minimum ping get more contracts.

So let's imagine the following situation:

Imaging I have 24Tb rig at home, my connection is 100mbit. I want to get as much data as possible. But as my home connection ping is relatively high I get not much contracts.

I deploy several [kvm] VPSs in a datacenter, install storjshare-daemon there and mount my 24/8 TB rig as a folder to each VPS.

Expected Behavior

In this case:

1. My storj client has minimum ping [because it is in datacenter]
2. I get as much contracts as possible (see 1)
3. I can cope with future penalty [if it would be implemented] of the same IP, counterparty address, big data folder etc. (cause I can deploy VPSs with differen IPs and even in different datacenters and I dont see a way, how storj network can understand that all of them point to the same data rig in fact).
4. With enabled fscache on a VPS I can save the traffic on often-downloaded shards and unload my 100 mbit home connection and deploy even more VPS :)

Actual Behavior

Why is that bad:

1. If my data rig goes offline too many shards would become unavailable.
2. The idea of a decentralized storage in fact doesnt work in such a case and I can cope with many future penalties (see point 3 above).

Steps to Reproduce

My suggestion is to add a small [inside-daemon] latency test of a data folder. Cause imho even the slowest HDD on the same system would have much lower writing latency than even a second [storage-only] VPS in the same network [with storj-daemon VPS].

At least it would help storj more or less understand how many nodes use mounted data folder at another location.

p.s. I tested such a scheme in November and it worked fine (used NFS).

Andy aka rrivv_1 on chat

To avoid having to manually or script starting a number of shares, implement a snapshot --save and snapshot --load command to save the metadata for currently running shares for ressurecting all of them later.

Package Versions

Replace the values below using the output from storjshare --version.

2.0.4

Replace the values below using the output from node --version.

v6.9.4

Expected Behavior

Please describe the program's expected behavior.

My prefered editor is vi and not nano. I would expect to open the config file in vi or at least don't print out the exeception.

Actual Behavior

Please describe the program's actual behavior. Please include any stack traces
or log output in the back ticks below.

root@storj:~# storjshare create --sjcx ...

  * configuration written to /opt/tmp/636ac391e41f6965381d17b4b22d96b5dc36c470.json
  * opening in your favorite editor to tweak before running
events.js:160
      throw er; // Unhandled 'error' event
      ^

Error: spawn nano ENOENT
    at exports._errnoException (util.js:1022:11)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:193:32)
    at onErrorNT (internal/child_process.js:359:16)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)
    at Module.runMain (module.js:606:11)
    at run (bootstrap_node.js:394:7)
    at startup (bootstrap_node.js:149:9)
    at bootstrap_node.js:509:3

Package Versions

Replace the values below using the output from storjshare --version.

 * daemon: 2.1.0, core: 6.0.14, protocol: 1.1.0

Replace the values below using the output from node --version.

6.9.2

Expected Behavior

As the Master Control Program, the daemon must be 100% rock steady and reliable.

Actual Behavior

Seeing apparently random crashes where going to check a status or version returns: * daemon is not running, starting...

And all running processes vanish.

Had 654 processes running this evening (an event that takes well over an hour to get started due to the current speed of start commands), went to check the version for another issue, and got the infamous message.

Daemon log file shows nothing special (tail clip):

{"level":"info","message":"attempting to restart share with node id 6d9b8b5f528ac823b3bac62e1c38cc071502f804","timestamp":"2017-01-19T00:34:35.085Z"}
{"level":"info","message":"attempting to stop share with node id 6d9b8b5f528ac823b3bac62e1c38cc071502f804","timestamp":"2017-01-19T00:34:35.087Z"}
{"level":"info","message":"attempting to start share with config at path /storj/node28/config","timestamp":"2017-01-19T00:34:35.093Z"}
{"level":"info","message":"share bde2a8d25715d6dd5c2787902942054b2b0c157b exited with code 1","timestamp":"2017-01-19T00:34:41.131Z"}
{"level":"info","message":"attempting to restart share with node id bde2a8d25715d6dd5c2787902942054b2b0c157b","timestamp":"2017-01-19T00:34:41.132Z"}
{"level":"info","message":"attempting to stop share with node id bde2a8d25715d6dd5c2787902942054b2b0c157b","timestamp":"2017-01-19T00:34:41.132Z"}
{"level":"info","message":"attempting to start share with config at path /storji5/node08/config","timestamp":"2017-01-19T00:34:41.138Z"}
{"level":"info","message":"share bf36153e99dcd9cdbcec9c3ba133db3694695c4b exited with code 1","timestamp":"2017-01-19T00:34:47.458Z"}
{"level":"info","message":"attempting to restart share with node id bf36153e99dcd9cdbcec9c3ba133db3694695c4b","timestamp":"2017-01-19T00:34:47.458Z"}
{"level":"info","message":"attempting to stop share with node id bf36153e99dcd9cdbcec9c3ba133db3694695c4b","timestamp":"2017-01-19T00:34:47.458Z"}
{"level":"info","message":"attempting to start share with config at path /storj/node343/config","timestamp":"2017-01-19T00:34:47.464Z"}
{"level":"info","message":"share 8069bc8bb65199ea1d17a0e34f814e8b094b9995 exited with code 1","timestamp":"2017-01-19T00:35:11.951Z"}
{"level":"info","message":"attempting to restart share with node id 8069bc8bb65199ea1d17a0e34f814e8b094b9995","timestamp":"2017-01-19T00:35:11.952Z"}
{"level":"info","message":"attempting to stop share with node id 8069bc8bb65199ea1d17a0e34f814e8b094b9995","timestamp":"2017-01-19T00:35:11.952Z"}
{"level":"info","message":"attempting to start share with config at path /storj/node494/config","timestamp":"2017-01-19T00:35:11.958Z"}
{"level":"info","message":"share 4fc36349aa482bfee700b59eb13baab1386140a5 exited with code 1","timestamp":"2017-01-19T00:35:13.844Z"}
{"level":"info","message":"attempting to restart share with node id 4fc36349aa482bfee700b59eb13baab1386140a5","timestamp":"2017-01-19T00:35:13.845Z"}
{"level":"info","message":"attempting to stop share with node id 4fc36349aa482bfee700b59eb13baab1386140a5","timestamp":"2017-01-19T00:35:13.845Z"}
{"level":"info","message":"attempting to start share with config at path /storj/node388/config","timestamp":"2017-01-19T00:35:13.850Z"}
{"level":"info","message":"share 9265dc5f9f013fa23418d58f3b6e95cd301336cd exited with code 1","timestamp":"2017-01-19T00:35:16.563Z"}
{"level":"info","message":"attempting to restart share with node id 9265dc5f9f013fa23418d58f3b6e95cd301336cd","timestamp":"2017-01-19T00:35:16.563Z"}
{"level":"info","message":"attempting to stop share with node id 9265dc5f9f013fa23418d58f3b6e95cd301336cd","timestamp":"2017-01-19T00:35:16.563Z"}
{"level":"info","message":"attempting to start share with config at path /storj/node392/config","timestamp":"2017-01-19T00:35:16.573Z"}
{"level":"info","message":"share f0a8410c2c1d7e0674bc51e579e1ca12b567b47b exited with code 1","timestamp":"2017-01-19T00:35:22.996Z"}
{"level":"info","message":"attempting to restart share with node id f0a8410c2c1d7e0674bc51e579e1ca12b567b47b","timestamp":"2017-01-19T00:35:22.997Z"}
{"level":"info","message":"attempting to stop share with node id f0a8410c2c1d7e0674bc51e579e1ca12b567b47b","timestamp":"2017-01-19T00:35:22.997Z"}
{"level":"info","message":"attempting to start share with config at path /storj/node436/config","timestamp":"2017-01-19T00:35:23.020Z"}
{"level":"info","message":"share 4362cdadf4e849ba13efcea787d78346f7c67712 exited with code 1","timestamp":"2017-01-19T00:35:23.797Z"}
{"level":"info","message":"attempting to restart share with node id 4362cdadf4e849ba13efcea787d78346f7c67712","timestamp":"2017-01-19T00:35:23.798Z"}
{"level":"info","message":"attempting to stop share with node id 4362cdadf4e849ba13efcea787d78346f7c67712","timestamp":"2017-01-19T00:35:23.798Z"}
{"level":"info","message":"attempting to start share with config at path /storji5/node49/config","timestamp":"2017-01-19T00:35:23.813Z"}

As previously reported in other issues posted this evening, this is happening with smaller daemon instances running only 16 shares as well.

Posted this issue to focus on the daemon crash issue.

Steps to Reproduce

Please include the steps the reproduce the issue, numbered below. Include as
much detail as possible.

1. ...
2. ...
3. ...

Package Versions

Replace the values below using the output from storjshare --version.

 * daemon: 2.1.0, core: 6.0.14, protocol: 1.1.0

Replace the values below using the output from node --version.

6.9.2

Expected Behavior

Nodes continue to run.

Actual Behavior

Node routinely crashing with error message "Failed to join network"

Full log attached.

Steps to Reproduce

Please include the steps the reproduce the issue, numbered below. Include as
much detail as possible.

1. ...
2. ...
3. ...
   node00.zip

Package Versions

Replace the values below using the output from storjshare --version.

2.0.4

Replace the values below using the output from node --version.

v6.9.4

Expected Behavior

Please describe the program's expected behavior.

Sending telemetry reports.

Actual Behavior

Please describe the program's actual behavior. Please include any stack traces
or log output in the back ticks below.

My node is not sending any telemetry report. No entry on the logfile and I don't find any code line on github.

I want to farm and install Storj by Docker, but it is not intuitive what an how to use it.

Usually it works like this in Docker world:

1. I will look for Docker instructions in README on GitHub where should be example for docker pull, docker run and basic configuration.
2. If not and I see Dockerfile in the repo I will try to search for a project on hub.docker.com with a proper README and auto builds (because it is safer).

This project have no repo on the Hub (nothing connected with this repo = auto build) and in namespace "storj*", so for Docker users there is no trustworthy image what we can use without much thinking.

Package Versions

Replace the values below using the output from storjshare --version.

* daemon: 2.1.0, core: 6.0.14, protocol: 1.1.0

Replace the values below using the output from node --version.

6.9.2

Expected Behavior

One single master location to determine basic problems.

Actual Behavior

Daemon should know WHY a farm process has stopped and included that on the status display for anything not in a "running" state. Initally, simple issues, like "Failed to parse configuration file", "Port in use", "Other process error", "Unknown - other error", etc. would be helpful.

Key is that this should be sent back ANY time a process terminates voluntarily, even if the process log level is set to 0.

Steps to Reproduce

Please include the steps the reproduce the issue, numbered below. Include as
much detail as possible.

1. ...
2. ...
3. ...

Package Versions

Replace the values below using the output from storjshare --version.

  * daemon: 2.1.2, core: 6.0.15, protocol: 1.1.0

Replace the values below using the output from node --version.

6.9.4

Expected Behavior

start

Actual Behavior

storjshare start --config /srv/.storj/config.json

failed to start share, reason: invalid payout address

Steps to Reproduce

Is it still required to have 10.000 SJCX at that address? If yes, that might be the problem here.

storjshare --version
2.0.4

node --version
v6.9.4


### Actual Behavior

Deamon hung up if i want to start a node

### Steps to Reproduce

1. storjshare daemon --foreground

{"level":"info","message":"attempting to start share with config at path /storj/config.json","timestamp":"2017-01-14T00:18:43.936Z"}
stream.js:74
throw er; // Unhandled stream error in pipe.
^

Error: Non-base58 character
at Object.decode (/usr/lib/node_modules/storjshare-daemon/node_modules/bitcore-lib/node_modules/bs58/lib/bs58.js:51:37)
at Function.Base58.decode (/usr/lib/node_modules/storjshare-daemon/node_modules/bitcore-lib/lib/encoding/base58.js:48:26)
at Function.Base58Check.decode (/usr/lib/node_modules/storjshare-daemon/node_modules/bitcore-lib/lib/encoding/base58check.js:45:31)
at Function.PrivateKey._transformWIF (/usr/lib/node_modules/storjshare-daemon/node_modules/bitcore-lib/lib/privatekey.js:196:50)
at PrivateKey._classifyArguments (/usr/lib/node_modules/storjshare-daemon/node_modules/bitcore-lib/lib/privatekey.js:108:25)
at new PrivateKey (/usr/lib/node_modules/storjshare-daemon/node_modules/bitcore-lib/lib/privatekey.js:48:19)
at Function.PrivateKey.fromString.PrivateKey.fromWIF (/usr/lib/node_modules/storjshare-daemon/node_modules/bitcore-lib/lib/privatekey.js:236:10)
at new KeyPair (/usr/lib/node_modules/storjshare-daemon/node_modules/storj-lib/lib/crypto-tools/keypair.js:22:40)
at Object.KeyPair (/usr/lib/node_modules/storjshare-daemon/node_modules/storj-lib/lib/crypto-tools/keypair.js:18:12)
at RPC.start (/usr/lib/node_modules/storjshare-daemon/lib/api.js:88:24)
at Proto.apply (/usr/lib/node_modules/storjshare-daemon/node_modules/dnode-protocol/index.js:123:13)
at Proto.handle (/usr/lib/node_modules/storjshare-daemon/node_modules/dnode-protocol/index.js:99:19)
at Object.dnode.handle (/usr/lib/node_modules/storjshare-daemon/node_modules/dnode/lib/dnode.js:140:21)
at Object.dnode.write (/usr/lib/node_modules/storjshare-daemon/node_modules/dnode/lib/dnode.js:106:22)
at Socket.ondata (_stream_readable.js:555:20)
at emitOne (events.js:96:13)

2. storjshare start --config /storj/config.json

(Debian, Vserver)

When starting this way:

root@JGI02:~# storjshare start --config /root/config.json
Secp256k1 bindings are not compiled. Pure JS implementation will be used.

  * starting share with config at /root/config.json
root@JGI02:~#

Nothing happens, but the process fails after 15-20 seconds:

root@JGI02:~# storjshare status

┌──────────────────────────────────────────┬─────────┬────────┬───────┬──────────┐
│ Node ID                                  │ Status  │ Uptime │ Peers │ % Shared │
├──────────────────────────────────────────┼─────────┼────────┼───────┼──────────┤
│ f**************************************9 │ stopped │ 15s    │ 0     │ ...      │
└──────────────────────────────────────────┴─────────┴────────┴───────┴──────────┘

Nothing (not a line) in logs by:
root@JGI02:~# storjshare logs -i f**************************************9
Nor by:
root@JGI02:~# tail -f /root/.config/storjshare/logs/f**************************************9.log

For those of us that like to script our configurations, it would be very handy to have a -noedit option on storjshare create that foregoes the opening of an editor.

Package Versions

Windows 10

Replace the values below using the output from storjshare --version.

2.0.3

Replace the values below using the output from node --version.

6.9.4

Expected Behavior

Log monitoring does not hang, and closing the monitoring windows does not kill storjshare.

Actual Behavior

When going into the log monitoring mode (e.g. storjshare logs --nodeid 72d6daaa086a7e25d53c58234d03bf9594b78590 ) after storjshare-daemon is running it will freeze after a few seconds and when the CMD window is closed, it automatically kills Storjshare-daemon and a complete restart is necessary.

Steps to Reproduce

Please include the steps the reproduce the issue, numbered below. Include as
much detail as possible.

1. Start storjshare
2. Start logging monitoring
3. kill logging monitoring window

I am trying to install command-line interface on my nas (synology 1513+ DSM 6.0.2-8451 Update 7):
sudo npm install -g storjshare-daemon

But I am getting error:
npm WARN engine [email protected]: wanted: {"node":"^6.9.1"} (current: {"node":"4.4.2","npm":"2.15.0"})
npm WARN deprecated [email protected]: use uuid module instead

[email protected] install /usr/local/lib/node_modules/storjshare-daemon/node_modules/dnode/node_modules/weak
node-gyp rebuild

gyp WARN EACCES user "root" does not have permission to access the dev dir "/root/.node-gyp/4.4.2"
gyp WARN EACCES attempting to reinstall using temporary dev dir "/usr/local/lib/node_modules/storjshare-daemon/node_modules/dnode/node_modules/weak/.node-gyp"
gyp ERR! build error
gyp ERR! stack Error: not found: make
gyp ERR! stack at F (/usr/local/lib/node_modules/npm/node_modules/which/which.js:63:19)
gyp ERR! stack at E (/usr/local/lib/node_modules/npm/node_modules/which/which.js:72:29)
gyp ERR! stack at /usr/local/lib/node_modules/npm/node_modules/which/which.js:81:16
gyp ERR! stack at /usr/local/lib/node_modules/npm/node_modules/which/node_modules/isexe/index.js:44:5
gyp ERR! stack at /usr/local/lib/node_modules/npm/node_modules/which/node_modules/isexe/access.js:8:5
gyp ERR! stack at FSReqWrap.oncomplete (fs.js:82:15)
gyp ERR! System Linux 3.10.77
gyp ERR! command "/volume1/@appstore/Node.js_v4/usr/local/bin/node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /usr/local/lib/node_modules/storjshare-daemon/node_modules/dnode/node_modules/weak
gyp ERR! node -v v4.4.2
gyp ERR! node-gyp -v v3.3.1
gyp ERR! not ok
npm WARN engine [email protected]: wanted: {"node":"4.x.x 6.x.x"} (current: {"node":"4.4.2","npm":"2.15.0"})
npm WARN optional dep failed, continuing [email protected]

[email protected] postinstall /usr/local/lib/node_modules/storjshare-daemon/node_modules/storj-lib/node_modules/diglet/node_modules/tldjs
node ./bin/postinstall.js

npm WARN deprecated [email protected]: to-iso-string has been deprecated, use @segment/to-iso-string instead.
npm WARN deprecated [email protected]: Jade has been renamed to pug, please install the latest version of pug instead of jade
npm WARN deprecated [email protected]: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue

[email protected] install /usr/local/lib/node_modules/storjshare-daemon/node_modules/storj-lib/node_modules/restify/node_modules/dtrace-provider
node scripts/install.js

[email protected] install /usr/local/lib/node_modules/storjshare-daemon/node_modules/storj-lib/node_modules/diglet/node_modules/bunyan/node_modules/dtrace-provider
node scripts/install.js

[email protected] install /usr/local/lib/node_modules/storjshare-daemon/node_modules/storj-lib/node_modules/restify/node_modules/bunyan/node_modules/dtrace-provider
node scripts/install.js

[email protected] install /usr/local/lib/node_modules/storjshare-daemon/node_modules/storj-lib/node_modules/secp256k1
prebuild-install || node-gyp rebuild || echo "Secp256k1 bindings compilation fail. Pure JS implementation will be used."

prebuild-install info begin Prebuild-install version 2.1.0
prebuild-install info looking for local prebuild @ prebuilds/secp256k1-v3.2.5-node-v46-linux-x64.tar.gz
prebuild-install WARN install EACCES: permission denied, access '/root/.npm'
gyp WARN EACCES user "root" does not have permission to access the dev dir "/root/.node-gyp/4.4.2"
attempting to reinstall using temporary dev dir "/usr/local/lib/node_modules/storjshare-daemon/node_modules/storj-lib/node_modules/secp256k1/.node-gyp"
gyp ERR! build error
gyp ERR! stack Error: not found: make
gyp ERR! stack at F (/usr/local/lib/node_modules/npm/node_modules/which/which.js:63:19)
ERR! stack at E (/usr/local/lib/node_modules/npm/node_modules/which/which.js:72:29)
gyp ERR! stack at /usr/local/lib/node_modules/npm/node_modules/which/which.js:81:16
gyp ERR! stack at /usr/local/lib/node_modules/npm/node_modules/which/node_modules/isexe/index.js:44:5
gyp ERR! stack at /usr/local/lib/node_modules/npm/node_modules/which/node_modules/isexe/access.js:8:5
gyp ERR! stack at FSReqWrap.oncomplete (fs.js:82:15)
gyp ERR! System Linux 3.10.77
gyp ERR! command "/volume1/@appstore/Node.js_v4/usr/local/bin/node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /usr/local/lib/node_modules/storjshare-daemon/node_modules/storj-lib/node_modules/secp256k1
gyp ERR! node -v v4.4.2
gyp ERR! node-gyp -v v3.3.1
gyp ERR! not ok
Secp256k1 bindings compilation fail. Pure JS implementation will be used.

[email protected] install /usr/local/lib/node_modules/storjshare-daemon/node_modules/storj-lib/node_modules/leveldown
prebuild --install

prebuild info begin Prebuild version 5.1.2
prebuild info looking for local prebuild @ prebuilds/leveldown-v1.5.3-node-v46-linux-x64.tar.gz
prebuild WARN install EACCES: permission denied, access '/root/.npm'
prebuild info install We will now try to compile from source.
prebuild ERR! build error
prebuild ERR! stack Error: not found: make
prebuild ERR! stack at getNotFoundError (/usr/local/lib/node_modules/storjshare-daemon/node_modules/storj-lib/node_modules/leveldown/node_modules/prebuild/node_modules/node-gyp/node_modules/which/which.js:13:12)
prebuild ERR! stack at F (/usr/local/lib/node_modules/storjshare-daemon/node_modules/storj-lib/node_modules/leveldown/node_modules/prebuild/node_modules/node-gyp/node_modules/which/which.js:68:19)
prebuild ERR! stack at E (/usr/local/lib/node_modules/storjshare-daemon/node_modules/storj-lib/node_modules/leveldown/node_modules/prebuild/node_modules/node-gyp/node_modules/which/which.js:80:29)
prebuild ERR! stack at /usr/local/lib/node_modules/storjshare-daemon/node_modules/storj-lib/node_modules/leveldown/node_modules/prebuild/node_modules/node-gyp/node_modules/which/which.js:89:16
prebuild ERR! stack at /usr/local/lib/node_modules/storjshare-daemon/node_modules/storj-lib/node_modules/leveldown/node_modules/prebuild/node_modules/node-gyp/node_modules/which/node_modules/isexe/index.js:44:5
prebuild ERR! stack at /usr/local/lib/node_modules/storjshare-daemon/node_modules/storj-lib/node_modules/leveldown/node_modules/prebuild/node_modules/node-gyp/node_modules/which/node_modules/isexe/access.js:8:5
prebuild ERR! stack at FSReqWrap.oncomplete (fs.js:82:15)
prebuild ERR! not ok
prebuild ERR! build Error: not found: make
prebuild ERR! build at getNotFoundError (/usr/local/lib/node_modules/storjshare-daemon/node_modules/storj-lib/node_modules/leveldown/node_modules/prebuild/node_modules/node-gyp/node_modules/which/which.js:13:12)
prebuild ERR! build at F (/usr/local/lib/node_modules/storjshare-daemon/node_modules/storj-lib/node_modules/leveldown/node_modules/prebuild/node_modules/node-gyp/node_modules/which/which.js:68:19)
prebuild ERR! build at E (/usr/local/lib/node_modules/storjshare-daemon/node_modules/storj-lib/node_modules/leveldown/node_modules/prebuild/node_modules/node-gyp/node_modules/which/which.js:80:29)
prebuild ERR! build at /usr/local/lib/node_modules/storjshare-daemon/node_modules/storj-lib/node_modules/leveldown/node_modules/prebuild/node_modules/node-gyp/node_modules/which/which.js:89:16
prebuild ERR! build at /usr/local/lib/node_modules/storjshare-daemon/node_modules/storj-lib/node_modules/leveldown/node_modules/prebuild/node_modules/node-gyp/node_modules/which/node_modules/isexe/index.js:44:5
prebuild ERR! build at /usr/local/lib/node_modules/storjshare-daemon/node_modules/storj-lib/node_modules/leveldown/node_modules/prebuild/node_modules/node-gyp/node_modules/which/node_modules/isexe/access.js:8:5
prebuild ERR! build at FSReqWrap.oncomplete (fs.js:82:15)
npm ERR! Linux 3.10.77
npm ERR! argv "/volume1/@appstore/Node.js_v4/usr/local/bin/node" "/usr/local/bin/npm" "install" "-g" "storjshare-daemon"
npm ERR! node v4.4.2
npm ERR! npm v2.15.0
npm ERR! code ELIFECYCLE

npm ERR! [email protected] install: prebuild --install
npm ERR! Exit status 2
npm ERR!
npm ERR! Failed at the [email protected] install script 'prebuild --install'.
npm ERR! This is most likely a problem with the leveldown package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! prebuild --install
npm ERR! You can get information on how to open an issue for this project with:
npm ERR! npm bugs leveldown
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!
npm ERR! npm owner ls leveldown
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR! /volume1/homes/admin/npm-debug.log
npm-debug.txt

Package Versions

Replace the values below using the output from storjshare --version.

 * daemon: 2.1.0, core: 6.0.13, protocol: 1.1.0

Replace the values below using the output from node --version.

6.9.2

Expected Behavior

Either the daemon should support a virtually unlimited number of clients (perhaps limited by memory) or a published number should be provided (and perhaps multiple daemons per server supported).

Actual Behavior

Current while attempting to start 1160 nodes, sequentially, all would appear to start, and casual tracking during the process would show progress as expected. Coming back some time later, the daemon appeared to have dropped the first 573 (one run) nodes but had all the remaining ones.

Likewise, in another attempt, I noted having 811 nodes running, only to discover 33 running a short while later.

Likewise had 652 nodes running this morning before going to work and came back to a crashed daemon that wasn't running at all. daemon.log contained nothing other than share restart commands, no other obvious errors.

Steps to Reproduce

Please include the steps the reproduce the issue, numbered below. Include as
much detail as possible.

1. Crank up 1000+ nodes.
2. Wait several hours for the nodes to start
3. Check the status

Streamline the setup of using HTTPS for the shard server so that shards can be served to a web browser without running into mixed-content security policy blocks.

This could be done with integrating: https://certbot.eff.org/ and other configuration options.

Moved from https://github.com/Storj/storjshare-cli/issues/242.

Package Versions

Replace the values below using the output from storjshare --version.

  * daemon: 2.1.2, core: 6.0.15, protocol: 1.1.0

Replace the values below using the output from node --version.

v6.9.1

Expected Behavior

Send usual telemetry reports

Actual Behavior

No telemetry messages in the log, only the following warnings :

{"level":"warn","message":"telemetry report rejected, reason: Cannot read property 'nodeID' of undefined","timestamp":"2017-01-20T16:34:05.203Z"}

Steps to Reproduce

1. Update to daemon: 2.1.2 and run a node for a while
2. cat /path/to/node/log.txt | grep telem

Highly requested feature from users. User are using their network line for some other task, or have some terrible ISP that caps their Internet. They would like to add a setting to limit/cap their bandwidth usage.

Note that there are already 3rd party applications that can do this, but users would like native support:

• Windows: Net Balancer
• Mac: Waterroof or Noobproof
• Linux: Wondershaper

Duplicates

https://github.com/Storj/storjshare-cli/issues/150
storj-archived/storjshare-gui#281
storj-archived/storjshare-gui#361
storj-archived/core#552

Package Versions

Replace the values below using the output from storjshare --version.

2.0.1

Replace the values below using the output from node --version.

v6.9.4

OS: windows 10

Expected Behavior

Start running the daemon.

Actual Behavior

Try to run the generated config results in an error.

C:\Users\Meije>storjshare start --config C:\Users\Meije\storjshare\config.json
undefined:56
  "loggerOutputFile": "C:\Users\Meije\.config\storjshare\logs\72d6daaa086a7e25d53c58234d03bf9594b78590.log",
                          ^

SyntaxError: Unexpected token U in JSON at position 732
    at Object.parse (native)
    at exports.parse (C:\Users\Meije\AppData\Roaming\npm\node_modules\storjshare-daemon\node_modules\rc\lib\utils.js:15:17)
    at addConfigFile (C:\Users\Meije\AppData\Roaming\npm\node_modules\storjshare-daemon\node_modules\rc\index.js:31:20)
    at module.exports (C:\Users\Meije\AppData\Roaming\npm\node_modules\storjshare-daemon\node_modules\rc\index.js:47:20)
    at Object.<anonymous> (C:\Users\Meije\AppData\Roaming\npm\node_modules\storjshare-daemon\lib\config\daemon.js:16:31)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)

C:\Users\Meije>

Steps to Reproduce

Please include the steps the reproduce the issue, numbered below. Include as
much detail as possible.

Generate the config.
Try to run the generated config.

Full log when trying to install:

C:\Users\super3>npm install -g storjshare-daemon
npm WARN deprecated [email protected]: use uuid module instead
npm WARN deprecated [email protected]: Jade has been renamed to pug, please install the latest version of pug instead of jade
npm WARN deprecated [email protected]: to-iso-string has been deprecated, use @segment/to-iso-string instead.
npm WARN deprecated [email protected]: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
C:\Program Files\nodejs\storjshare-restart -> C:\Program Files\nodejs\node_modules\storjshare-daemon\bin\storjshare-restart.js
C:\Program Files\nodejs\storjshare-start -> C:\Program Files\nodejs\node_modules\storjshare-daemon\bin\storjshare-start.js
C:\Program Files\nodejs\storjshare -> C:\Program Files\nodejs\node_modules\storjshare-daemon\bin\storjshare.js
C:\Program Files\nodejs\storjshare-stop -> C:\Program Files\nodejs\node_modules\storjshare-daemon\bin\storjshare-stop.js
C:\Program Files\nodejs\storjshare-destroy -> C:\Program Files\nodejs\node_modules\storjshare-daemon\bin\storjshare-destroy.js
C:\Program Files\nodejs\storjshare-logs -> C:\Program Files\nodejs\node_modules\storjshare-daemon\bin\storjshare-logs.js
C:\Program Files\nodejs\storjshare-daemon -> C:\Program Files\nodejs\node_modules\storjshare-daemon\bin\storjshare-daemon.js
C:\Program Files\nodejs\storjshare-status -> C:\Program Files\nodejs\node_modules\storjshare-daemon\bin\storjshare-status.js
C:\Program Files\nodejs\storjshare-killall -> C:\Program Files\nodejs\node_modules\storjshare-daemon\bin\storjshare-killall.js
C:\Program Files\nodejs\storjshare-create -> C:\Program Files\nodejs\node_modules\storjshare-daemon\bin\storjshare-create.js

> [email protected] install C:\Program Files\nodejs\node_modules\storjshare-daemon\node_modules\weak
> node-gyp rebuild


C:\Program Files\nodejs\node_modules\storjshare-daemon\node_modules\weak>if not defined npm_config_node_gyp (node "C:\Users\super3\AppData\Roaming\nvm\v6.9.4\node_modules\npm\bin\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.js" rebuild )  else (node "" rebuild )
Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch.
  weakref.cc
  win_delay_load_hook.cc
..\src\weakref.cc(17): fatal error C1083: Cannot open include file: 'stdlib.h': No such file or directory [C:\Program F
iles\nodejs\node_modules\storjshare-daemon\node_modules\weak\build\weakref.vcxproj]
C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h(31): fatal error C1083: Cannot open include file: 'ctype.h':
 No such file or directory (compiling source file C:\Users\super3\AppData\Roaming\nvm\v6.9.4\node_modules\npm\node_modu
les\node-gyp\src\win_delay_load_hook.cc) [C:\Program Files\nodejs\node_modules\storjshare-daemon\node_modules\weak\buil
d\weakref.vcxproj]
gyp ERR! build error
gyp ERR! stack Error: `C:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onExit (C:\Users\super3\AppData\Roaming\nvm\v6.9.4\node_modules\npm\node_modules\node-gyp\lib\build.js:276:23)
gyp ERR! stack     at emitTwo (events.js:106:13)
gyp ERR! stack     at ChildProcess.emit (events.js:191:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:215:12)
gyp ERR! System Windows_NT 10.0.14393
gyp ERR! command "C:\\Program Files\\nodejs\\node.exe" "C:\\Users\\super3\\AppData\\Roaming\\nvm\\v6.9.4\\node_modules\\npm\\node_modules\\node-gyp\\bin\\node-gyp.js" "rebuild"
gyp ERR! cwd C:\Program Files\nodejs\node_modules\storjshare-daemon\node_modules\weak
gyp ERR! node -v v6.9.4
gyp ERR! node-gyp -v v3.4.0
gyp ERR! not ok
C:\Program Files\nodejs
`-- [email protected]
  +-- [email protected]  (git+https://github.com/littleskunk/fd-diskspace.git#2866a4cf147649d97f81fb33464bcbf0f8176bd5)  `-- [email protected]
    +-- [email protected]  (git://github.com/bugventure/jsen.git#9e57a9d653ff4ea47d364fc37da0f1659bfb8e89)
    `-- [email protected]  (git://github.com/bookchin/node-ntp-client.git#64a1d2318284578b90f388565de7c4b5a2441233)

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\storjshare-daemon\node_modules\weak):
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] install: `node-gyp rebuild`
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: Exit status 1```