I ran electrum -v and figured out that the problem was my SSL certificate had expired.  For some reason, I could not connect in via port 50001.  So, unfortunately, anyone who has connected to my server in the past will not be able to connect unless (s)he deletes their wallet and restores from the seed because otherwise the old certificate will fail to verify.

I found my laptop's IP address among the connections.  So, my client connects to the server, but the server does not serve any data to my laptop.  Presumably, I have a low connections count because clients see my server and connect to it but when they fail to retrieve data they connect to another server.

I reviewed my logs again.  Actually, the SSL connections were not of the format IP:50002.  So, that hasn't changed since my server's last working state.  I upgraded Ubuntu to 18.04 LTS and upgraded to python 3.7 which increased the number of connections to approximately 30, but I could still not connect via an Electrum client.  Also, a couple months ago when I could connect I had about 10X the connections.  

Furo4kin, have you looked at these issues?
https://github.com/kyuupichan/electrumx/issues/556
https://github.com/kyuupichan/electrumx/issues/94

Let me know if your logs match any output from these issues.  Issue #556 seems to match the timeline of our problems.  I am unsure where the weakest point would be in a DOS attack, but I suppose it would be my router.

Furo4kin, if you would like any more info as I learn more, I could PM you if you allow messages from newbies

How would ElectrumX syncing issues cause you to lose coins?  I presume you configured bitcoin core with --disable-wallet.  I have a similar issue where I have a low number of SSL connections and I cannot connect to my server via my wallet.  Is this a physical home server or a virtual server?  I think my issue is cause by a networking error: bad router config, DNS issues.  Since your symptoms are similar, we may have the same source problem.  I pinged your server domain names, but they did not resolve to an IP address.

Aug 17 13:51:37 icarus electrumx_server[1984]: INFO:ElectrumX:[1202] SSL 92.156.243.66:56970, 2 total
Aug 17 13:52:28 icarus electrumx_server[1984]: INFO:ElectrumX:[1203] SSL 190.91.37.177:65412, 2 total
Aug 17 13:53:18 icarus electrumx_server[1984]: INFO:ElectrumX:[1204] SSL 190.91.37.177:49218, 2 total
Aug 17 13:54:14 icarus electrumx_server[1984]: INFO:ElectrumX:[1205] SSL 190.91.37.177:49350, 2 total
Aug 17 13:55:24 icarus electrumx_server[1984]: INFO:ElectrumX:[1206] SSL 190.91.37.177:49538, 2 total
Aug 17 13:56:28 icarus electrumx_server[1984]: INFO:ElectrumX:[1207] SSL 190.91.37.177:49654, 2 total
Aug 17 13:57:30 icarus electrumx_server[1984]: INFO:ElectrumX:[1208] SSL 190.91.37.177:49846, 2 total
Aug 17 13:58:15 icarus electrumx_server[1984]: INFO:ElectrumX:[1209] SSL 190.91.37.177:49966, 2 total
Aug 17 13:59:33 icarus electrumx_server[1984]: INFO:ElectrumX:[1210] SSL 190.91.37.177:50190, 2 total
Aug 17 14:00:08 icarus electrumx_server[1984]: INFO:ElectrumX:[1211] SSL 190.91.37.177:50260, 2 total
Aug 17 14:01:04 icarus electrumx_server[1984]: INFO:ElectrumX:[1212] SSL 217.182.138.142:41128, 2 total
Aug 17 14:01:51 icarus electrumx_server[1984]: INFO:ElectrumX:[1213] SSL 185.128.27.99:56548, 3 total
Aug 17 14:31:03 icarus electrumx_server[1984]: INFO:ElectrumX:[1214] SSL 217.182.138.142:34996, 2 total
Aug 17 14:36:58 icarus electrumx_server[1984]: INFO:ElectrumX:[1215] SSL 71.204.162.202:58830, 3 total
Aug 17 14:39:28 icarus electrumx_server[1984]: INFO:ElectrumX:[1216] SSL 73.32.220.70:57214, 3 total

I try to connect to my server but cannot.  From looking at the logs, it appeared as though my max connections somehow got lowered to 2 or 3, but then after looking at the logs more closely it looks like ElectrumX serves mostly 190.91.37.177 .  I did upgrade to LEDE from a small business router recently.  However, I would think if my IPtables config were the issue that I would have trouble SSHing into Icarus (my server).  Initially, I had trouble SSHing into Icarus but after reconfiguring IPtables I could SSH into Icarus.  About the same time that SSH started working, my AWS server notifications notified me that my server was up.  So, apparently Icarus serves watching only wallets.

 I have no clue why my SSL connections are not on 50002; I plan to tweak IPtables.  If that does not work then I'll upgrade to Ubuntu 18, so that I will be working with a fresh install.  If that doesn't fix it.  I will reset my router config.

I'm going to reply on the thread, so that the next person that sees your question knows that it has been answered.  Also, someone else might have the same question.

Firstly, I like to break up a large problem into smaller ones.  So, in script kiddie fashion, I copy and paste one of these scripts https://en.bitcoin.it/wiki/API_reference_(JSON-RPC) in order to make sure that you can communicate between processes.  A few things can go wrong here.  I've seen a version update break the (inter-process communication) IPC  in both Zcash  and a Bitcoin Unlimited.  It may have been from the same pull which was not properly vetted or separate pulls.  Make sure your username and password match.  If you use Perl, it may have issues parsing some characters in the password, so omit or replace any suspect characters.

JM required
walletnotify=curl -sI --connect-timeout 1 http://localhost:62602/walletnotify?%s
alertnotify=curl -sI --connect-timeout 1 http://localhost:62602/alertnotify?%s
I'm not sure if JMCS does, but I use them.  I think that should get you in the right direction.

I am still a bit unclear by the phrase, "Avoid address reuse." in the high level design doc.  It could me strictly mean do not reuse address, or it could mean do not associate addresses (as in co-joining two addresses into a third address), or do not mix the dirty laundry with the clean laundry.  I found the figure in Wikipedia's coinjoining page more illuminated than the figures in the high level doc and in Gregory Maxwell's.  It appears as though from Wikipedia's figure, that the privacy is a function of the depth level.

Let L represent the depth level and P the privacy, then P=P(L) where P strictly increase with L.   That is to say that change addresses remain tainted.

Also, since the transaction fees are so high now, it seems reasonable to consider consolidating coins into one address (for both makers and takers which would require takers to run a full node), so as to lower the kb of transactions.  I am still a little fuzzy about the the number of UTXO per users.

Is this proposition correct?
Let N=the number of user, then N-1=the number of makers. Let O=the number of UTXO going into the coinjoin. Let M=the average number of transaction inputs per user

N*M<=O

Hence by running a full node the users increase reliability and lower the need for more than one input and lowering the lower bound of each of the following transaction inputs, transaction data size,  the transaction fee.

I did not realize that the new version of JoinMarket does not output to the terminal just logs. So I had to clean my UTXO. I moved each UTXO to a new address, to ?untaint? them and I managed to coinjoin as a taker with absurd_fee_per_kb=925000.  The price was bit high maybe I had set the number of makers, ?N?, too high or maybe the increase is due to the new market value for transaction fees.  I am still tweaking parameters to try to coinjoin as a maker.

How many times, is N used for different parameters? It sounds as though, N represents at least the the target block confirmation time and the number target makers simultaneously.  Perhaps that's theoretically acceptable if each lives in a different namespace, but from a practical perspective why would anyone want to obfuscate that?  I will reread the high level design to rule out the possibility that maker coinjoin attempts are not failing due to something with the protocol.

This morning, I thought if the problem is not with IRC, but with a lack of demand (due to fees), such that, I cannot find a counterparty, then I should just tumble. I should easily find a counterparty.  Makers responded.

2017-12-20 12:12:50,549 [MainThread  ] [INFO ]  fee breakdown for J59guRuX5ct5H2KF totalin=8090451 cjamount=6280195 txfee=22 realcjfee=245
2017-12-20 12:12:50,551 [MainThread  ] [INFO ]  fee breakdown for J58pyc32abnCjf9V totalin=13236610 cjamount=6280195 txfee=8064 realcjfee=8074
2017-12-20 12:12:50,554 [MainThread  ] [INFO ]  fee breakdown for J549nFYzjyWtkd9k totalin=7000000 cjamount=6280195 txfee=74 realcjfee=166
2017-12-20 12:12:50,568 [MainThread  ] [INFO ]  fee breakdown for J5Dm1LNSVD71cPGg totalin=250000000 cjamount=6280195 txfee=0 realcjfee=63
2017-12-20 12:12:50,571 [MainThread  ] [INFO ]  fee breakdown for J582pgC6GjfA8mj8 totalin=11810274 cjamount=6280195 txfee=0 realcjfee=685
2017-12-20 12:12:50,580 [MainThread  ] [INFO ]  fee breakdown for J54B3A58fYh1WEdU totalin=30000000 cjamount=6280195 txfee=0 realcjfee=6374
2017-12-20 12:12:50,582 [MainThread  ] [INFO ]  fee breakdown for J59w76vRTjNiqLKR totalin=7592378 cjamount=6280195 txfee=22 realcjfee=188
2017-12-20 12:12:50,583 [MainThread  ] [INFO ]  fee breakdown for J5F9XcX6aiZ86Ufg totalin=9916408 cjamount=6280195 txfee=0 realcjfee=2506

Unhandled Error
...

Estimated fee per kB greater than absurd value: 350000, quitting.

Amp server or network failure unhandled by client application.  Dropping connection!  To avoid, add errbacks to ALL remote commands!
Traceback (most recent call last):
Failure: twisted.protocols.amp.UnknownRemoteError: Code<UNKNOWN>: Unknown Error

At the moment, I have no clues.  I will digest this later when I have time.

JM daemon setup has completed, but the terminal has output anything beyond

2017-12-19 19:37:02,808 [MainThread  ] [INFO ]  Warning: too high txfee to be profitable, halfing it to: 590
2017-12-19 19:37:02,808 [MainThread  ] [INFO ]  Warning: too high txfee to be profitable, halfing it to: 295
2017-12-19 19:37:02,808 [MainThread  ] [INFO ]  Warning: too high txfee to be profitable, halfing it to: 147
2017-12-19 19:37:02,808 [MainThread  ] [INFO ]  starting yield generator
2017-12-19 19:37:03,189 [MainThread  ] [INFO ]  Listening on port 27183
connection was made, starting client
2017-12-19 19:37:07,645 [MainThread  ] [INFO ]  JM daemon setup complete

I have forwared port 27183 on my router, but I don't read anything happening on that port when I run nmap on my laptop.  When I run top, on my home server I don't see any additional process under the user under which I started the yield generator.  Is my IRC setup dysfunctional, or has the high fees from the blocksize cap priced out takers? Or perhaps something else?  I have just run the yield generators with default settings.

In my last iteration of reinstalling, I had commented the following and and replaced it with the sudo installation.
#ExecStart=/home/electrum/electrumx/electrumx_server.py
ExecStart=/usr/local/bin/electrumx_server.py

As a rough postmortem, I got so used to appending the instructions with tweaks such as "pip3" instead of "pip" and "sudo apt-get install" instead of "apt-get install" I lost sight of the fact the in order to contain the privileges of user electrum you want to make sure electrum only starts files/processes which are not owned by root.  I am actually still a little fuzzy how the user electrum could even access a file in /usr (?inherentence from systemctl?).  Therefore, "python3.6 setup.py install" should work for anyone else attempting to install on Ubuntu, but you will probably need the symbolic link from my last post.  I don't know what the error was that caused my to comment the line above was, but my guess is that I would not of seen it on debian (if python3.6 baked in).

I have reinstalled Ubuntu 16 LTS.  Previously I had ElectrumX working, but with unexplained downtime and unreliable fee estimates.  Hence I reinstalled Ubuntu server.  I have reinstalled Ubuntu a few times after failing.  At one point, I symbolically linked /usr/bin/python3 to /usr/bin/python3.6 which broke the package management.  Now I have /usr/local/bin/python3 -> /usr/bin/python3.6 which seems to work; although, I have an error which may or may not be related to package management/dependencies:

Dec 14 16:26:05 icarus electrumx_server.py[2534]: Traceback (most recent call last):
...

Dec 14 16:26:05 icarus electrumx_server.py[2534]:   File "/usr/local/lib/python3.6/dist-packages/electrumx-1.2.1-py3.6.egg/server/block_processor.py", line 148, in __init__
Dec 14 16:26:05 icarus electrumx_server.py[2534]:     self.cancel_history_compaction()
Dec 14 16:26:05 icarus electrumx_server.py[2534]: AttributeError: 'BlockProcessor' object has no attribute 'cancel_history_compaction'

I have no clue whether the issue is with dependencies such as leveldb or something else entirely.

I state that I run BU on my server: icarus.tetradrachm.net. I would like to generalize on the question of the benefits of knowing which server you connect to. Originally, I switched. to Electrum when I read that Jaxx discouraged sending mining payments to their wallet addresses. This lead me to suspect that my Jaxx wallet would trust a central server.  Since I ran a full node in any case, I decided to run electrum-server beside it, so that I could connect to my trusted full node. However, it sounds as though since electrum uses SPV which eliminates the profitability of a sybil attack, I could use auto-connect with little risk.  Also, by using electrum in contrast to Jaxx, Mycelium, et. al.  I connect to a full node in a more decentralized manner.

I signed a new certificate which listed the FQDN.  However, I still had the same error. After reading this, https://github.com/spesmilo/electrum/issues/1782, I realized that my laptop and phone thin wallets had connected to my server when I had my original SSL certificate in which I had filled out all the fields.  I had deleted this one when I got too much spam from bots scraping my e-mail off the certificate.  Since the original certificate was in my thin clients ~/.electrum/certs as trusted, my server was either flagged as MITM'd or my thin client tried to use the incorrect certificate, so my server refused the connection.  After deleting the trusted certificates, I have connected via SSL on both thin clients now.

On another topic, with regards to bootstrapping speed, my online instructor stated that VFS is much faster than ext4.  So, I am considering reformatting my 4TB bitcoind HDD and 0.5TB  electrumX SSD, and lowering bitcoind's dbcache from the current setting of 3GB.  Bitcoind uses 10% of my 20GB of RAM after bootstrapping.  I welcome any resource allocation suggestions.

I have the verbose output from electrum (not the server).

[Network] connecting to icarus.tetradrachm.net:50002:s as new interface
[icarus.tetradrachm.net] SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)
[icarus.tetradrachm.net] wrong certificate
[Network] connecting to icarus.tetradrachm.net:50002:s as new interface

I am hosting publicly: icarus.tetradrachm.net.   When I followed the directions on the aforementioned guide, I did not get any errors.  However, when I attempt to connect my electrum light wallet to my full node electrumX server I get a green light when I choose 50001 and uncheck SSL and a red light when I choose SSL 50002.  Typing "journalctl | grep electrum" in the terminal prints, "electrumx_server.py[1069]: INFO:ElectrumX:[1919] SSL 70.181.17.94:33670, 89 total" among other TCP and SSL connections which confuses me. Perhaps my SSL is misconfigured on my light wallet end?

I know that web servers tend to have their signed certificates hosted by a 3rd party CA.  Does this apply to electrumX/electrum-server? I have not paid to register a CSR with a CA.

I set /etc/hosts and the  DNS A record to the remote IP.  From there, I port forwarded to the server's internal IP which works. Still, SSL remains improperly configured.  I followed the directions on https://freedomnode.com/blog/69/how-to-install-an-electrum-server-using-full-bitcoin-node-and-electrumx

Is SSL worth setting up?

Now, electrum connects to electrumX when I set my A record in the DNS to the internal IP 10.0.0.2 => icarus.tetradrachm.net.  If I change the A record to my home router's external IP, electrum shows my electrum server as offline. I assume that the home router is firewalling electrumX, or electrumX needs a global IP (that is port forwarding will not suffice).

Update: nmap -p N 10.0.0.2 reports that both ports are open, where N = {5001, 5002}.  Thus, I suspect the forward DNS is firewalled.  I had this problem when I setup SSH, I could only logon outside my home network by using IPv6.  However, I have tried to configure electrumX with IPv6 and that did not work at the time, but I may have changed reconfigured other options since.  I will retry IPv6.

Could someone explain the last mile of setting up an electrum-server or electrumX server on a home network? My FQDN resolves, but it does not appear to be pointing to my desktop running electrumX. Perhaps the FQDN points to my router? I registered a domain name, but do I need a subdomain as well?