Interestingly enough; this happened to several customers at just about the same time the other week on new servers that we added into the farm. In servers in the farm, we had set a Diagnostic Logs location to a customized location (e.g. D:\Logs); and we even gave the WSS_WPG and WSS_Admin_WPG accounts full control permissions to the folder beforehand (something you normally don’t have to do).
When this was happening, all of the files are created as expected at the (default) 30 minute interval, but the contents remained empty.
I discovered that removing the server from the farm; deleting the ULS log location; rebooting the servers; and then rejoining the servers to the farm was an option that appeared to work (most of the time), but I needed a better solution (that was less disruptive to everybody).
After doing some digging when looking at a server in the farm with a working ULS logging configuration and a server without a valid ULS logging configuration, I noticed that the service account that the “SharePoint Tracing Service” (in this case Contoso\DSP_Services) wasn’t included in the “Performance Log Users” group that is local to the server.
By adding that service account to the “Performance Log Users” group, and running a “net stop SPTraceV4” then “net start SPTraceV4”, the ULS logs begin actually logging to the files.
Best as I can judge, this normally happens automatically when a server is joined to a farm; but sometimes it fails (most commonly when the user logging into the server is inside of a group inside of a group inside of the Local Administrators group that UAC blocks access to). I’ve noticed this on SharePoint 2010 RTM, SP1 and 2013 RTM (and March 2013 Public Update) servers across