The funniest to watch was systemd deciding to kill user processes on "last logout" so it would happily kill your elected PostgreSQL cluster leader as soon as the last follower is done catching up the WAL via rsync (over SSH). It was the perfect whack-a-mole game, always killing the leader once the cluster healed. Obviously you had to mark any service user as a system account.
How else could systemd purge left over processes (e.g. GNOME tracker and gvfsd)?!? You don't expect developers of the inevitable perfect Linux desktop to fix their code? No lets break the system and take down the well behaving applications with the fallout unless the operator knows (and has permission) to restore the old behaviour. Oh and I hope you didn't expect screen/tmux/dtach/nohup to work.
If you're using systemd as a service manager (which you probably should do, if your hosts are running systemd?), you don't need the user running your services to be a system user. You can just have (either) your services launch from a systemwide systemd service, or make sure your user has lingering enabled if you're using systemd user services.
If you're not using systemd to manage your application's services, you can still use the methods above if you just have systemd launch your process supervisor of choice (which you should definitely do if your hosts are running systemd and you're using some other process supervisor).
How else could systemd purge left over processes (e.g. GNOME tracker and gvfsd)?!? You don't expect developers of the inevitable perfect Linux desktop to fix their code? No lets break the system and take down the well behaving applications with the fallout unless the operator knows (and has permission) to restore the old behaviour. Oh and I hope you didn't expect screen/tmux/dtach/nohup to work.