AWS/Azure deploy - Never restart a transactor that is in a bad state

[Brecht De Rooms]

Dear,

Concerning
in the AWS docs it states:

"Troubleshooting the Transactor AMI
The Transactor AMI is designed as an expendable, commodity resource. It
should be used once, and fail fast and shutdown in the face of any
unrecoverable error.
If you believe that the transactor is in a damaged state, you should shut
it down and let CloudFormation start a new one. Never restart a transactor
that is in a bad state, as you may propagate (and worsen) the problem."

When reading this I am wondering what this actually means for people who
are not using the AMI or are doing a custom deploy (e.g. such as Room Key's
deploy). I can imagine that the AMI is also using systemd or upstart to
start a datomic service and am wondering why this could cause problems and
why a restart fixes the problem. This seems quite crucial to know if you
are deploying datomic.
- If we create a VM ourselves and run a transactor on that VM (using
systemd, config is included below) which points to a DynamoDB or Postgres.
Imagine that the transactor dies. Does the above statement imply that we
can not stop and restart the transactor using systemd?
- If we should not do this, what should we do instead? Restarting the
machine will also just restart a transactor, or is it different if another
transactor (failback) takes over in between
- Why is this different from running locally and stopping/starting the
transactor if things go wrong?

I think it's important for deploying datomic that this is clear since the
statement above gives me a 'unstable' feeling.

*Possible systemd config:*
[Unit]
Description = Datomic Transactor

[Service]
PIDFile=/var/run/datomic.pid
User = datomic
Type = simple
ExecStart = /usr/lib/datomic/bin/transactor
/usr/lib/datomic/config/transactor.properties

[Install]
WantedBy = multi-user.target