It might be possible to do odd things w/ the PID in the PID file when PID limit is large

[mulkieran]

See comment here: stratis-storage/stratisd#1482 (comment), and here: stratis-storage/stratisd#1482 (comment).

[jbaublitz]

I've taken a look into this. @bgurney-rh is correct in that stratisd only overwrites the number of bytes corresponding to the string representation in decimal of the new PID. This will not report the wrong PID if there's an overflow because of the following:

1. If there's no flock on the PID file, it will not ever reach that code and therefore the contents don't matter.
2. If there's a flock on the PID file from a process other than stratisd (which could only happen if a root user decided to acquire a lock on that file) and the PID is larger than can be contained by an i32, the .parse().ok() method will return None as .parse() will return

Err(ParseIntError { kind: Overflow })

This will bubble up to the .unwrap_or_else() and be displayed as <unknown>.

However, if a root user does acquire a lock on the file and there is a number that can be represented as an i32 in the PID file, then the PID will be reported incorrectly as an invalid process ID. The solution to this problem and this comment mentioned above is that we should probably wipe the contents of the file on shutdown to avoid this.