Why mongod.service is killed by my system?
Systemd is changing the PIDFile path at startup to /run/mongodb/mongod.pid.  However, the mongod doesn't consult the unit file, it uses its own config, usually /etc/mongod.conf.
Update both the unit file and the mongod.conf to use &quot;/run/mongodb/mongod.pid&quot; as the PIDFile.
Since mongod forks, systemd is expecting to see the pidfile created so that it knows the process has started.  That would use signal 15, it isn't the main problem, though.
Signal 6 occurs when the mongod itself calls abort.
The error calls out line 1598, which is:
Status WiredTigerRecordStore::updateRecord(OperationContext* opCtx,
                                           const RecordId&amp; id,
                                           const char* data,
                                           int len) {
    dassert(opCtx-&gt;lockState()-&gt;isWriteLocked());
    invariant(opCtx-&gt;lockState()-&gt;inAWriteUnitOfWork() || opCtx-&gt;lockState()-&gt;isNoop());

    WiredTigerCursor curwrap(_uri, _tableId, true, opCtx);
    curwrap.assertInActiveTxn();
    WT_CURSOR* c = curwrap.get();
    invariant(c);
    setKey(c, id);
    int ret = wiredTigerPrepareConflictRetry(opCtx, [&amp;] { return c-&gt;search(c); });
    invariantWTOK(ret);  &lt;&lt;--- Line 1598


The WiredTiger docs provide an description of WT_NOTFOUND:

#define WT_NOTFOUND
Item not found.
This error indicates an operation did not find a value to return. This includes cursor search and other operations where no record matched the cursor's search key such as WT_CURSOR::update or WT_CURSOR::remove.

The provided 3 log lines unfortunately don't give us any real clues as to what wasn't found.  It could have been a missing or corrupt data file, a damaged entry in the journal, or a truncated record.
What I suspect happened is the PIDFile mismatch led to systemd causing an unclean shutdown that left one or more files corrupt.
To fix this:

fix the PIDFile configuration in both the unit file and the mongod.conf so this doesn't happen again
make a backup of the dbpath
remove all of the files in the dbpath
attempt to start mongodb

If it is able to startup with the corrected PIDFile settings and a clean data directory, you can decide from there whether to restore the backup and attempt to repair the corrupt files, or just start over with an empty db.