I have a couple of comments:
My main comment is about the duplication of data. I understand it’s needed for support to debug, but keep in mind that obfuscation takes time. The more duplication of data, the longer taking a snapshot will take. I’m not saying we shouldn’t get it, I’m just saying we should be smart about it. It isn’t just taking extra space in a directory, it is taking extra time while taking the snapshot. If it takes 30m-1hr to take a snapshot, admins might not want to do it (logs can be huge).
If pbs_snapshot is replacing pbs_diag, I’d remove the -d option. It’s a way of taking the output of pbs_diag and converting it to pbs_snapsho formt. We’re not going to use pbs_diag any more, so why have an option for it?
Just as a note, by putting the log directories one level deeper than in the normal PBS_HOME, we can’t run tracejob on them. If all the log directories were in the same place, you can point tracejob at that directory and it’ll work. The separation does keep things tidy though.
As for sudo, the real requirement is a command run as root. I wouldn’t say to run it as sudo. You don’t need sudo privileges, you need root. the sudo command is just one way of getting it. You could run su -c just as easily. You could make a side note that sudo is alright, but I wouldn’t make the interface section use it.
While it is an admin orientated tool, it can still be run as a normal user. You don’t get everything, but you get most things. This would allow those of us who have accounts on customer sites to take partial snapshots without bugging the admin. If sudo is embedded inside the tool, the admins will get upset at us for running it. I’ll add my vote to run sudo outside the tool.