If you aren't careful about how much logging output your program generates, you can still fill up a disk despite not creating more than one log file, causing all kinds of problems:
If run as root, you can literally fill the disk, since that bypasses quotas. Some filesystems also reserve a certain minimum amount of free space for root, to avoid the below problems.
If a filesystem is full, you can't even create a temporary file on the disk. If the filesystem you fill is also where some of your common temp space lives (
/var/tmp) programs trying to use that space will likely die if running or fail to start if not.
Programs that crash when this happens won't drop cores, if you've set your system up to allow this. That can make it difficult to reduce those programs' sensitivity to low-disk-space conditions, since it makes it harder to discover the specific code path that crashed the program.
You can run
logrotate along with your program to mitigate the risk of this.
logrotate isn't 100% foolproof. It typically runs as a cron job, so if you fill the disk between two
cron runs, the problem won't be corrected until
logrotate next runs.