Where are my log files?

To clarify, I know where the log files are located… I’ve been using Interworx for approx 3-4 weeks and login today to find that the first few weeks or so of my log files are missing… :confused:

The only related setting that I’ve found is the option of whether to save log files, which is on the siteworx/prefs page. “Save Web Transfer Logs” and I have that option set to “yes.”

So… where are my log files? Did Interworx delete them even though I specified for them to be saved?

I imagine that there must be a setting somewhere which is causing this. Can anyone fill me in on where I might find that?

I believe I dug up the way to correct this.

in iworx.ini


Can someone from Interworx please confirm whether this is the correct way to modify how long log files are saved with version 4 of Interworx?

Does Interworx need to be restarted in order for that config change to be effective?

Also, this sort of thing should have been specified somewhere in the control panel. Either on the nodeworx settings page or maybe the siteworx/prefs pages. With siteworx/prefs having the option to save logs, it really comes across as meaning that it will literally “save” logs, but that is not the case. Logs appear to only be saved temporarily. siteworx/prefs really should be updated so that the “?” popup help or even the page itself details how long the logs will be saved for.

Yes, that is the correct way to specify the many daily transfer logs to save. No, InterWorx does not need to be restarted for changes in the iworx.ini to go into effect.

When “save transfer logs” is set in SiteWorx is should be saving the logs to the SiteWorx user’s log directory, but under a different file name so they will not be purged ( {$date}-{$logname} as opposed to {$logname}-{$date}). If this is not occuring on your server please file a support ticket so we can look into this and determine the cause.

We’ll check into adding that to the settings page, and get it out in a future release. It would probably make sense for it to be there. :wink:

Just to make sure we’re on the same page, by “user’s log directory” you’re referring to: /home/USERNAME/var/DOMAINNAME/logs ?

Logs were, and are, being saved in those directories for my various sites. The problem is that only apparently the most recent 1 week worth of logs were saved.

The setting in siteworx essentially implies that all logs are being saved until deleted, but the default is actually to save the logs only temporarily (7 days).

It’s probably not a big deal, generally, but in my case I feel it to be quite important to maintain historic logs as they are very valuable with advertising sales as well as during potential acquisitions (in showing the long-term historic traffic of the site).

Anyhow, I believe I’m all set with the config change in iworx.ini.

I’ll post another reply with some possible suggestions on how I think this all might be improved, in case those ideas are helpful.

Yes I am referring to that directory. By any chance were these sites backuped and restored recently? We recently uncovered an issue in InterWorx 4 where statistics (including the daily transfer log files) were not being backed up correctly.


  1. On the /nodeworx/settings page, in the ‘stats’ section, you might put in the editable number of days to save log files. This would be the default server-wide.

2a. On /nodeworx/siteworx?action=edit&domain=domainname.com , in the ‘package options’ section, you might add a few related options:

2b. User editable # of logs to save: yes/no

2c. Setting for the max number of logs that a user can select to save, if the user has the option to edit.

2b+2c could be one setting. Setting a max would imply that the user can edit, otherwise the server default would be used.

2d. Setting for the # of log files to save. Default would be the server-wide default #. This would be editable by the admin whether or not a user has the option to edit. If the user does have the option to edit the number of log files to be stored, then they would be able to do so up to the max that’s specified in 2c.

  1. I’m not sure if Interworx already does this, but the log files saved could be automatically pruned (regardless of how many are specified to be saved) if the account is running out of HDD allocated space or maybe if the HDD itself is running out of space (which preferably would never happen). This might be based on the average log file size, or maybe the average of the past 7 log files (or whatever available if less than that) and begin deleting the oldest log file when the available remaining HDD account space is some multiple of the avg log file size. I mention this as it would be better to prune old logs before risking database corruption upon running out of space, etc.

4a. Log file naming. I believe it might be useful to name log files in the following format: domainname.com-transfer.log-MMDDYYYY.zip This would be convenient for those who have many sites and help to prevent logs from accidentally getting mixed up (after being downloaded & archived).

4b. And to improve further, instead of using MMDDYYYY I believe it would be beneficial to use YYYYMMDD, this way the logs can be very easily sorted through, first based on year, then month then date. This probably wouldn’t be much of an issue, though, since most would probably have logs of different years in separate folders after downloading them.

No, this wasn’t related to a backup issue. I just started using Interworx at the end of August. When I clicked through to the logs directory for one of my sites I noticed right away that there were fewer zipped access log files than what I was expecting (should have been more than two dozen) based on the configs that I set in nodeworx and siteworx. For my issue I believe it was solely the number of logs to save setting in iworx.ini. I changed the setting yesterday and can confirm that no other logs were deleted as of last night (checked a few of my accounts, but not all - it should be the same for all of them, though).

At some point I do intend on looking through how Interworx backsup my sites in order to make sure everything is there & restorable. Haven’t had time to do that just yet, but when I do I’ll be sure to mention if I come across any potential issues.