Web server = apache Basedir = /var/www Website path = /var/www/clouds/cloud_[client_id]/site_[website_id] Website symlinks = /var/www/sites/by_name/[website_domain]/:/var/www/sites/by_id/site_[website_id]/ I noticed that the symlinks were not being created, and suspected a permissions issue or missing base folder. Yup, I found this in /var/log/ispconfig/cron.log In there are these corresponding lines: Questions: 1) Is a hunt for "return code: 1" the SOP (standard operating procedure) for detecting errors? Why isn't an explicit ERROR logged? 2) Note that the log entries are in reverse order of the operations. I haven't looked at the code but I can understand how this happens. Is it worthwhile to pursue an inquiry into how the logging is done so that we can see messages about what is going to happen followed by the result rather than preceded by the result? 3) Since a lot can happen in one second, for understanding the actual time line has adding the millisecond value to logging been considered? I dunno if that's a performance issue, but hey, we've got the debug flag on, we know we're not running optimally. 4) It looks like the cron.log just echoes output from the processes it calls. But note that the detailed error for the "ln -s" operation appears in the cron.log (2>&1?) and not in the ispconfig.log. So all we get in the ispconfig.log is "return code: 1" while the reason for that error is only in the cron.log. If we have DEBUG mode on, I would hope that syserr is being captured wherever possible. 5) About this specific symlink issue, I have not seen a rule that says the folder path needs to be created before symlinks can be created. Is it worth an enhancement request to create the base path for a symlink with mkdir -p before the ln command? This is a problem in the case where we want a single folder to hold symlinks for all website_domain names for a cient: /var/www/clients/client1/sites/domain1.tld > /var/www/clients/client1/site_34 /var/www/clients/client1/sites/domain2.tld > /var/www/clients/client1/site_41 That extra 'sites' folder needs to be created under all clientX folders. Without a mkdir -p before the ln, that won't happen, and within inserting some shim/event code there's no option for us to ensure that folder gets created. 6) OK, so I created /var/www/sites/by_id and /var/www/sites/by_name. Note again my symlink templates: /var/www/sites/by_name/[website_domain]/ /var/www/sites/by_id/site_[website_id]/ The by_name link is created correctly. The by_id link is literally 'site_[website_id]' -> /var/www/clouds/cloud_1/site_2// 6a) OK, mea culpa, I rechecked the doc and [website_id] isn't a valid placeholder for this field. Does anyone else feel like this would be useful? 6b) Note the double slash terminating the valid link. I know it doesn't matter, but it's not clean. The default symlink templates have trailing slashes too. The simple solution here is to eliminate that trailing slash off the default. OR ... is there actually something here that could go wrong? 7) Is there any simple way yet to auto-rebuild symlinks for all sites? I'm think it would be cool if a change to the symlink field triggers this. I just tried it, that doesn't happen. Thanks for going on this little trip with me.
From a recent thread: While kinda brutal, that does answer a question about how to fix the situation. The thing is that the software provides a place for us to configure preferences - but if we use that feature it's easy for functionality to break. Telling people not to use the feature isn't the most diplomatic solution to the problem. Some validation for the symlink field would be much more user friendly. Until that gets implemented (I know, it's FOSS and this is an opportunity to make a contribution) I'll add this as a topic in the new documentation when we get started with that. In addition to the symlink issues, I'm finding that a couple vhost subdomains are getting pointed in the apache config to the root clientX/siteY folder, not the "web" folder under that. This is because I didn't specify the web folder for the vhost. It defaults to empty = root. But that's not a valid value. The doc says "This field must not be empty" (section 4.6.1.3). So I go to try to fix it and the field is disabled/immutable. This is another situation where there is no validation, and users are left to walk into issues. Tracing errors like this can be difficult - in this case not but in other cases "can be". This is another place for enhancement - rather than improving logging for an error, in this case preventing easy errors with field validation. Yeah, I know - it's FOSS... I'll offer to do what I can when I can. For now I'm just documenting what I see for others.
Any non-zero return code signals an error, so safe_exec informs you of the return code and the command run. There's no way a wrapper function like safe_exec can know what it indicates; the code calling safe_exec would be in a position to know that, and could be modified with further debug (or warning) messages if appropriate. You could file a request for those as needed, or just open the editor to find the spot it's needed and add the error and submit an MR with that, it's probably not a lot more work that filing an issue for something simple like that. The ln error being present in cron.log is from what you noticed: It seems that server.sh does not capture nor log stdout/stderror, where cron.sh does; this is at least partly why server debugging steps have folks run server.sh manually, to see those errors. A normal $app->log() seems to not work in cronjobs, but does from server.sh. I just found in the last week or two that there is some other logging logic when handling some cron related tasks that specifically checks the log_priorty setting of config.inc.php; in a brief test I increased the logging level using that setting, and indeed had more logging messages when running cronjobs. It seems in my observations that cron jobs do not use log level set under Server Config at all. Probably so. (It's a pretty simple fix.) I don't know of any problem it would cause. You could try to resync websites, but if that doesn't do it, (check code to confirm, but) probably not.
This exercise is good in a few ways. Based on Till's note about deleting and recreating everything, I figured it's time to write my site maintenance scripts. That led to another thread I just posted in the dev forum. The thing about mkdir -p before ln also leads to an easy MR (we think) so I'll do that at some point. And I also want to script the generation of more symlinks that are not auto-created for good reason. So this is all productive. The info about logs and cron, etc are really helpful. Thanks. I'm still learning about server.sh, where various logs are kept, or not, etc. I'm definitely going to install logwatch and other utilities to keep an eye on things. Clicking on the links in the Monitor page just doesn't cut it for me, and it's way too time consuming to tail and grep on the /var/log tree to see what's going on.
