I think the safest way to do this is for the long-running process to listen to a socket. Once the short process is done, it connects to that socket, sends over any relevant information, and disconnects.
Socket communication to localhost should never fail, so this should not introduce any meaningful risk. Sockets are better than using files to synchronize because there is no risk another process or user will alter or delete the file, and file permissions cannot prevent a socket from working.
As with other methods, sockets allow you to send arbitrary information. It could be as simple as "hi, go do your thing" or it could be a complex serialized data structure. Whatever you need.
Finally, sockets typically work by using streams to serialize and deserialize data on both ends. Both sockets and streams are very standard and established communication methods supported by virtually all operating systems and programming environments. Even if you change your technology stack in the future or expand to work with a program written in a different language in addition to what you have today, that part should still work.
I recommend checking out the list of registered IP ports and picking one that is not in use. According to the bottom of the page, ports in the range 49,152 to 65,535 cannot be registered and should be available for any use (including this one) without interfering with standard applications (e.g. an FTP/SFTP server).
scala_app && other_thing
? Or run the other_thing from within your Scala app?