The current EpicGamesLauncher-Mac-Shipping is constantly printing the names of running processes to the console log. It’s hard to tell if this is having a measurable impact on performance (I’m having serious performance problems with UE4 4.21 but I’m opening a separate bug report for that problem), but it is certainly filling up the log and using disk space for no apparent or valid purpose. I’ve attached just a few minutes of output from Console.log. It’s logging so much that console.app lags a several minutes behind.
Hi Kneebiter,
Where did you get this log file from? I’ve checked the launcher logs on mac and don’t see it reproducing?
They’re not from the Unreal Logs, they’re from the system logs at /private/var/log/system.log but are coming from the Unreal Launcher process. You can see them live by opening the Console.app.
Interestingly, I’m at work now on a Late 2013 Mac Pro, and I’m not seeing this behavior here, so it would seem to be either something specific to the iMac Pro, or to my specific system configuration at home (which may, or may not be related to the significant performance issues I’ve been having on that machine with Unreal (only Unreal).
Some more information - just launching the Epic Games Launcher doesn’t trigger. I also have to open a project in the editor (in my case, a 4.21 project). Once I do that, the EpicGamesLauncher starts spamming the system log with process names over and over and over until I quit either the editor or the launcher.
Hi Kneebiter,
From some quick googling it looks like its a log file which is just logging actions which are happening on the system. I’ve confirmed that the Launcher isn’t actively logging to that system, instead I suspect that the OS actions themselves are configured to do so.
When we launch an app we look at running processes to allow us to monitor when the application has closed. This stops us updating the application automatically when the app is open and also allows us to control various aspects of the UI.
To look for that running process we need to enumerate all the running processes on the machine looking for the one we launched.
I’ll be sure to follow up with the team to ensure we aren’t adversely effecting performance in the process on mac.
From some quick googling it looks like
its a log file which is just logging
actions which are happening on the
system. I’ve confirmed that the
Launcher isn’t actively logging to
that system, instead I suspect that
the OS actions themselves are
configured to do so.
So, yeah, that’s actually not quite correct. /private/var/log/system.log is the persistent output of the unified logging system, which treats any logging entity (basically, any running process) as a “subsystem”. Log items of any kind go to Console.app. Those at any log level other than ‘default’, then get persisted to the system.log file.
Entries in the system log from a specific subsystem are always from that process. The system is not going to log on behalf of a process and a subsystem can’t pretend to be another subsystem. These log entries coming from the subsystem called EpicGamesLauncher-Mac-Shipping, have to be coming from the launcher process in the form of one of the os_log methods, or a higher-level logging system whose implementation calls os_log (NSLog, Swift’s print, printf in C, cout in C++)
Somewhere in the launcher code, there’s a log statement firing in a loop, timer, or delegate once every second that’s triggering an os_log call for every running userland process. While this probably isn’t a huge issue performance-wise on my hardware, it could have a non-trivial impact on older or lower-end machines, Regardless of that, it’s definitely bad etiquette to spam the system logs like this because it makes it very difficult to identify and debug problems, such as the performance issue I’m currently seeing in 4.21.
Anything logged at the default level isn’t persisted to the log file, so those types of messages are only available as long as they are in the logging buffer. With this constant spam from the launcher, that means any transient logging scrolls out of the buffer almost immediately, making them hard to spot or copy.