This is a curious one. ISPConfig 3.2.8p1, NginX, on Ubuntu 20.04.4 LTS. This is *more* likely to occur on back to back remote API calls to create a site. Not sure why or where to look, my first stop would usually be the domain in question's log file but... I'm also unable to create such a folder with either root or the client's permission, i.e.: root@server1:/var/www/test101.example.com # mkdir log mkdir: cannot create directory ‘log’: Operation not permitted Any clues, or where to look for clues greatly appreciated.
Update: Definitely some sort of race condition as it does not appear to occur if I await ISPConfig's job queue to be empty before invoking another create site request. It appears to be more likely to fail at creating a site's log folder if there is are pending requests, i.e. another create site, delete a site/database/shell in the job queue at the time a create site request is made. sys_datalog is not showing any errors in the error column, and the status is "ok" for all entries.
Update 2: Looks like the issue is occuring because I'm attempting to sudo su -c [username] "cp some files" before the site and associated shell is "ready". Prior, I was only waiting for the site folder to appear, but the sites_shell_user_add probably wasn't finished. Why the log directory doesn't get created as a result is a bit of a mystery but it appears that if I hold out by polling for the /var/www/test101.example.com/home/[username] to appear; I'm fine. Issuing multiple remote commands (i.e. sites_shell_user_add, sites_web_domain_add), in the job queue works well if I wait for said shells to finish before doing "other stuff". I'm not sure if waiting for the /home/[username] folder is the right way to go about it but so far so good. log folders appear to be generated without issue now.
All entries in the sys_datalog get processed in order by ISPConfig, so there is no need to wait for an API call as long as you do things within the ISPConfig server process scope. Of course, you can not copy something into a folder that has not be created manually from an outside script before ISPConfig created it and if your script creates it instead of ISPConfig, then things must break as well, and that#s what probably happens here. My guess is your script is doing things outside of ISPConfig job processing order which then causes this problem. E.g. if you want to write a script that copies things into a website, then you should write that script as an ispconfig server plugin and not as an external script that is executed separately and this plugin must have a name that is at the end when ordered alphabetically, so your plugin name should e.g. start with x like 'xcustomplugin".
There is no tutorial on that topic yet. But I'll try to write a short guide on how to write a server-side plugin next week. You might also find a few posts here in the forum, probably in the dev forum, on how to do that.
