Why are files in /tmp or /run automatically deleted?
Because your service starts a "daemon" that immediately exits, therefore marking the service as "stopped" within seconds of starting, therefore causing the kdestroy
from ExecStop= to be run.
Option 2: Change the .service definition to tell systemd that this is supposed to be a task that immediately exits, using these options:
[Service]
Type=oneshot
RemainAfterExit=yes
The Type=oneshot
mode is additionally useful because will make systemd wait for ExecStart= to fully complete before the service is marked as "active", avoiding the need to add the arbitrary sleep 2
. In other words, it lets you use After=kinit.service
without worrying that other things will start "too early".
Option 1: Replace kinit with the k5start
daemon from https://www.eyrie.org/~eagle/software/kstart/. This is a real daemon – a long-running process – and will be tracked as such. It will handle periodic renewal as well.
If you use k5start with the -b
option ("Detach on startup") and change the .service to Type=forking
mode accordingly, you will also get the same "delay until success" behavior.
(There's also a third option of letting gssproxy
handle all tickets, but cifs.upcall in CentOS doesn't support that yet. For other uses besides mounting filesystems, KRB5_CLIENT_KTNAME
would let the program itself acquire tickets from keytab as needed, but it won't work in this case.)
What is the preferred location for these ccache files?
Personally I would stick with /tmp/krb5cc_*
or /run/user/<uid>/krb5cc_*
. (Those are the only locations NFS rpc.gssd checks.)
For SMB, cifs.upcall will look at the system default location for the UID that's performing the mount (i.e. whatever is defined in krb5.conf), which is usually /tmp/krb5cc_0
when systemd is doing so. (Although cifs.upcall can scrape KRB5CCNAME out of the invoker's environment, that doesn't help with automounts being involved, as cifs.upcall would only see systemd or autofsd as the caller.)
Is PrivateTmp a better solution?
PrivateTmp won't help, because it's not an external task that's deleting your file, it's the service itself doing so.