How can I find a rogue script that just won't quit - in Linux

[guyinpv]

I have a Ubuntu server up on VULTR which I use as a web server and it runs Vesta Control Panel, which I do really like and want to keep using.

The problem is Vesta has lost its mind with its backup system.

What is happening is that Vesta "thinks" there is one backup in progress, but it thinks this endlessly and it never stops. If I try to manually create a backup it will error saying that one is in progress.

The "in progress" backup never finishes, and fills up the entire drive space of the server with /backup/tmp.* folders until the server runs out of space and everything stops working.

I can delete all those tmp.* folders and gain 50% drive space back, but it will fill up again within a number of hours.

I've restarted the Vesta service and it doesn't work. I've gone as far as restarting the whole server and that doesn't stop it either.

My question is basically how can I FIND this script that refuses to stop and is filling up the drive with tmp folders? Why is it kicking right back up when the server is restarted?

I'm not the best when it comes to dealing with running processes and what is doing what. Am I able to figure out what specific service/process is responsible for creating specific files and folders? Can I monitor what process is accessing that /backup folder?
Obviously the script is connected with Vesta but I still don't know how to use that info. Like where is the script running from or what it might be called. Maybe it's even part of the larger Vesta service and I can't even stop it individually?

Any ideas how to find this script and fix it? Or at least stop it. I've reported to Vesta on two different web channels but no response. I haven't found anybody else having this runaway backup script issue.

And just in case anybody asks, it is not the case that the script simply needs all this room. I used to have multiple backups stored and it never used this much space. Now, all backups are deleted for all accounts, it should definitely not need this much temp storage to do a backup of some small websites.

I just need some way to make the connection of THIS script keeps writing to THIS folder. Is there a way to find this out? Not sure what my options are.

[scottalanmiller]

That's not super easy unless the script is holding the file open currently or the script is altering the file as a user that is only used by that script. There isn't a residual "this is the script that created the process that altered this file" metadata anywhere. You have to connect the file to the process that changed it to the script that made that process. That's a bit.

The easiest thing to do, I'm sure, is to approach this from the application side and find out what it uses to do these tasks and handle it that way.