Reorganization of init systems files, adding systemd sample config

docs/HOWTO.rst

@@ -100,7 +100,7 @@ might do::
 
 Then copy the all sample scripts from the ElectrumX source tree there::
 
-    cp -R /path/to/repo/electrumx/samples/scripts ~/scripts/electrumx
+    cp -R /path/to/repo/electrumx/samples/daemontools ~/scripts/electrumx
 
 This copies 3 things: the top level server run script, a log/ directory
 with the logger run script, an env/ directory.
@@ -136,7 +136,7 @@ Using systemd
 This repository contains a sample systemd unit file that you can use to
 setup ElectrumX with systemd. Simply copy it to :code:`/etc/systemd/system`::
 
-    cp samples/systemd-unit /etc/systemd/system/electrumx.service
+    cp samples/systemd/electrumx.service /etc/systemd/system/
 
 The sample unit file assumes that the repository is located at
 :code:`/home/electrumx/electrumx`. If that differs on your system, you need to

samples/systemd/electrumx.conf

@@ -0,0 +1,95 @@
+#suggested /etc/electrumx.conf for systemd
+
+#
+#REQUIRED
+#
+
+    DB_DIRECTORY =
+    USERNAME = electrumx
+    ELECTRUMX = /usr/local/bin/electrumx_server.py
+
+    #Bitcoin Node RPC Credentials
+    DAEMON_URL = http://username:password@hostname:port/
+        #port is optional, defaults to COIN RPC default
+
+#
+#REQUIRED FOR PUBLIC VISIBILITY
+#
+
+    #HOST = 0.0.0.0
+        #listen on interface, (0.0.0.0 is any)
+    #TCP_PORT = 50001
+    #SSL_PORT = 50002
+        #Requires
+        #SSL_CERTFILE = /path/to/server.crt
+        #SSL_KEYFILE = /path/to/server.key
+
+#
+#OPTIONAL VISIBILITY
+#
+
+    #BANNER_FILE = /path/to/banner
+    #DONATION_ADDRESS =
+    #IRC = yes
+    #IRC_NICK =
+    #REPORT_HOST = $HOST
+    #REPORT_TCP_PORT =  #defaults to TCP_PORT
+    #REPORT_SSL_PORT =  #defaults to SSL_PORT
+    #RPC_PORT = 8000
+
+
+#
+#MISC
+#
+    #COIN = Bitcoin  # lib/coins.py
+    #NETWORK = mainnet  # lib/coins.py
+    #DB_ENGINE = leveldb
+        #leveldb, rocksdb, lmdb (You'll need to install appropriate python packages)
+
+    #REORG_LIMIT = 200
+        #maximum number of blocks to be able to handle in a chain
+        #reorganisation.  ElectrumX retains some fairly compact
+        #undo information for this many blocks in levelDB.
+
+    #ANON_LOGS =
+         #Set to anything non-empty to remove IP addresses from logs.
+
+
+#These following environment variables are to help limit server
+#resource consumption and to prevent simple DoS.  Address subscriptions
+#in ElectrumX are very cheap - they consume about 100 bytes of memory
+#each and are processed efficiently.  I feel the defaults are low and
+#encourage you to raise them.
+
+    #MAX_SUBS = 250000
+        #Maximum number of address subscriptions across all sessions
+    #MAX_SESSION_SUBS = 50000
+        #Maximum number of address subscriptions permitted to a single session.
+
+
+#If synchronizing from the Genesis block your performance might change
+#by tweaking the following cache variables.  Cache size is only checked
+#roughly every minute, so the caches can grow beyond the specified
+#size.  Also the Python process is often quite a bit fatter than the
+#combined cache size, because of Python overhead and also because
+#leveldb consumes a lot of memory during UTXO flushing.  So I recommend
+#you set the sum of these to nothing over half your available physical
+#RAM:
+
+    #HIST_MB = 300
+        #amount of history cache, in MB, to retain before flushing to
+        #disk.  Default is 300; probably no benefit being much larger
+        #as history is append-only and not searched.
+
+    #UTXO_MB = 1000
+       #amount of UTXO and history cache, in MB, to retain before
+       #flushing to disk.  Default is 1000.  This may be too large
+       #for small boxes or too small for machines with lots of RAM.
+       #Larger caches generally perform better as there is
+       #significant searching of the UTXO cache during indexing.
+       #However, I don't see much benefit in my tests pushing this
+       #too high, and in fact performance begins to fall.  My
+       #machine has 24GB RAM; the slow down is probably because of
+       #leveldb caching and Python GC effects.  However this may be
+       #very dependent on hardware and you may have different
+       #results.