search

sonic2kk / steamtinkerlaunch

Linux wrapper tool for use with the Steam client for custom launch options and 3rd party programs
GNU General Public License v3.0
2.05k stars 70 forks source link

STL repeatedly spawns `sleep 1` processes #1015

Closed AutumnalModding closed 5 months ago

AutumnalModding commented 6 months ago

System Information

Issue Description

STL (or at least it reasonably seems to be STL; it doesn't happen when it is closed) is repeatedly spawning sleep 1 processes - this can be seen via running Steam in a terminal and launching a game that uses STL as a compatibility tool.

Not only does this (presumably) fill up Proton logs; it also could reach the PID limit if left running for long enough - my system has only four days uptime and is already nearing one million process IDs, which is certainly not normal for a standard desktop install up for a measly four days (or even a server up for that short a time!)

Additionally on 32-bit systems this could repeatedly hit PID_MAX - on 64-bit systems it is 4194304, but on 32-bit systems and some kernels (WSL2 apparently does this; though why anyone would use STL on WSL2 is beyond me) it is the significantly smaller 32767.

Logs

I... don't think STL logs every single command it executes, does it?

sonic2kk commented 6 months ago

SteamTinkerLaunch does indeed use sleep 1, and this is required for some processes. It is pretty common for scripts to use it, too.

Are you saying using sleep 1 at all is the issue? If so, what do you propose as an alternative?

I will investigate briefly and see if I can replicate your results.

sonic2kk commented 6 months ago

When running a game with SteamTinkerLaunch, I am seeing 1-2 sleep processes being created per-game. These disappear when the game is closed (they disappear and one extra sleep process is created, and then closed), or after about 30 seconds. There are also Bash processes, 3-4 per game launch, and likewise these disappear when a game is closed.

So I'm not sure why your system is continually having theses processes spawn and remain. This has also not been reported before, and sleep has been used for a long time in SteamTinkerLaunch (and various other scripts). So I imagine if sleep was the entirety of the issue, it would've been reported long before now, and not included to begin with.

The majority of the usage of sleep has been included for 2-3 years, so these are not new additions.

AutumnalModding commented 6 months ago

When running a game with SteamTinkerLaunch, I am seeing 1-2 sleep processes being created per-game. These disappear when the game is closed (they disappear and one extra sleep process is created, and then closed), or after about 30 seconds. There are also Bash processes, 3-4 per game launch, and likewise these disappear when a game is closed.

Hrm. On my system it seems to be executed at least once a second. Perhaps there is a runaway while loop somewhere, at least in my case?

I could try replacing /usr/bin/sleep with a script that logs execution and calls the real process; though I would need to modify STL to use that instead of builtin sleep.

sonic2kk commented 6 months ago

I tested a game running with Proton 8.0 (PowerWash Simulator), GE-Proton (Yakuza 0), and a native game (Undertale), and I'm not seeing the behaviour. The sleep process sometimes does not even take as long as 30 seconds to disappear, and once a game has been closed for a while, there are no remaining sleep processes.

I tested this with Steam running from my application launcher and from terminal, and neither case reproduced the results. I don't have another device to verify this on.

Perhaps there is a runaway while loop somewhere, at least in my case?

You could try testing with a game you have never used SteamTinkerLaunch with before and seeing if that reproduces it. Try narrowing it down, and if it only happens with some specific games, see if you can find out what it is that reproduces it with that game.

I don't know if sleep or a function that calls it is used in a while loop, but I feel like if this was common enough it would've been widespread and reported already.

If memory serves, you recently opened an issue before with MO2, so I tested a game with ModOrganizer 2 just to see, since sleep is used with ModOrganizer 2's startup iirc. However, the sleep process disappeared quickly. So I don't think ModOrganizer 2 is the culprit.

Is the sleep process call coming from Bash? That would potentially be an indicator that it's SteamTinkerLaunch. Various system monitors are able to tell you the parent process. I can see for the sleep calls that appear for me, the parent process is Bash, so I can infer it's SteamTinkerLaunch (during system updates, dkms uses sleep, and I was able to see that dkms was the parent process in those cases, calling sleep 3, from KDE System Monitor).

I'll continue looking into this tomorrow eveniing.

sonic2kk commented 6 months ago

It might also be worth checking the logs to see if anything is being logged over and over again. Not all sleep processes are going to have a log with them but I think a lot of while loops would. It would also be unusual for STL to continue logging while the main game process is running, since that's not forked. It would be worth seeing if SteamTinkerLaunch is doing anything over and over.

AutumnalModding commented 6 months ago

Is the sleep process call coming from Bash? That would potentially be an indicator that it's SteamTinkerLaunch.

Yes; I checked ps -fA output - lily 928693 926955 0 15:53 pts/4 00:00:09 bash /home/lily/.local/share/Steam/compatibilitytools.d/SteamTinkerLaunch/steamtinkerlaunch waitforexitandrun /home/lily/Other/Mountpoints/Games/SteamLibrary/steamapps/common/Skyrim Sp (truncated unfortunately; but it is indeed STL)

Something of note is that the GUI never actually closes when using MO2 - and if I close MO2 (or the STL GUI, I forgot which) the game's launcher opens.

As for logs, unfortunately it got overwritten when I checked the version. (oops)

sonic2kk commented 6 months ago

Something of note is that the GUI never actually closes when using MO2 - and if I close MO2 (or the STL GUI, I forgot which) the game's launcher opens.

  1. Does this happen without ModOrganizer 2, did you test with a fresh game with no configuration?
  2. The ModOrganizer 2 GUI is expected to stay open. The rest sounds weird, and I have no idea what's happening. Make sure you're using ModOrganizer 2 in Game Mode and not Standalone Mode to launch your game (enable MO2 on the Game Menu for that game and launch the game, and open MO2 using the prompt after you launch the game).

Either way though I wasn't able to recreate this behaviour with MO2 so I don't think it matters for this issue, just a general usage pointer.

As for logs, unfortunately it got overwritten when I checked the version. (oops)

A fresh log is generated on each execution of SteamTinkerLaunch at /dev/shm/steamtinkerlaunch, so it shouldn't be too much trouble to get back 🙂

AutumnalModding commented 6 months ago

The ModOrganizer 2 GUI is expected to stay open.

Sorry, I should probably clarify; the STL GUI is the one that stays open (as well as MO2, ofc). And yes, it is via game mode - launching via compatibility tool. I'll try to get logs in a bit.

sonic2kk commented 6 months ago

Hmm, I'm not sure how the SteamTinkerLaunch GUI could even stay open. Pressing the "Play" button on the Main Menu will open the ModOrganizer 2 prompt, there should not be an opportunity for SteamTinkerLaunch to even stay open. The Main Menu closing is something Yad handles, when any of the buttons on the bottom row are pressed with any Yad dialog, that dialog will close.

It sounds like something is going very wrong here.

AutumnalModding commented 6 months ago

Hmm, I'm not sure how the SteamTinkerLaunch GUI could even stay open. Pressing the "Play" button on the Main Menu will open the ModOrganizer 2 prompt, there should not be an opportunity for SteamTinkerLaunch to even stay open. The Main Menu closing is something Yad handles, when any of the buttons on the bottom row are pressed with any Yad dialog, that dialog will close.

Of note: Pressing said button does not open MO2; even though the game is in the Steam category. Instead, it simply opens the generic launcher; and MO2 most be launched through the dedicated "ModOrganizer 2" button.

sonic2kk commented 6 months ago

Instead, it simply opens the generic launcher; and MO2 most be launched through the dedicated "ModOrganizer 2" button.

This is not how to use MO2, and could be the source of issues here. I dunno about this whole "Steam Category" thing but it's never worked for me, I've been trying to remove mentions of it. You should NOT be launching games via ModOrganizer 2 started from the GUI or steamtinkerlaunch mo2 start. You should ONLY start games when ModOrganizer 2 is started from the prompt.

You should go into the Game Menu and make sure ModOrganizer is enabled.

And once again, PLEASE test a fresh game WITHOUT ModOrganizer 2. I have asked a few times now, we need to see if this is limited to ModOrganizer 2 usage. Remember that MO2 is a heavily secondary and mostly unmaintained part of STL, since I don't use it and no one else helps out with it.

AutumnalModding commented 6 months ago

And once again, PLEASE test a fresh game WITHOUT ModOrganizer 2. I have asked a few times now, we need to see if this is limited to ModOrganizer 2 usage. Remember that MO2 is a heavily secondary and mostly unmaintained part of STL, since I don't use it and no one else helps out with it.

Will do. Testing Hyperdimension Neptunia: Sisters VS Sisters, clean install. Issue still occurs with the main menu GUI open. Additionally it still occurs when clicking 'Play' and the menu closes. Does not happen if the menu GUI is never opened.

Update: This seems to only occur when the menu GUI is open, meaning it has far less impact than previously where the menu stayed open.

sonic2kk commented 6 months ago

Thanks, I think this narrows the issue you're facing down then.

When the STL Main Menu is open (the screen that displays the game banner and all of the main menu buttons for things like One-Time Run, etc) this is the part that spawns all the sleep processes on your system. And since launching MO2 from the Main Menu keeps the Main Menu open (i.e. using in Standalone Mode, different from Game Mode which closes the GUI due to how Yad works), this is what spawns all of the sleep processes in your initial scenario.

Unfortunately even in this scenario, I'm still not seeing this behaviour. One sleep process is created, but it closes quickly and I'm not seeing any sleep processes lingering. I also checked the Game Menu and the Global Menu, and didn't see this behaviour either.

Can you stay on the Main Menu for a bit and then attach a log file? You can also check yourself and see if anything looks particularly strange that you'd like me to look at specifically.

I'm not able to re-create this behaviour.

By the way, a clean install isn't necessarily bad, but in case I gave the wrong impression, I meant just testing a game with SteamTinkerLaunch that you hadn't used before; a fresh game with no previous launches with STL.

AutumnalModding commented 6 months ago

By the way, a clean install isn't necessarily bad, but in case I gave the wrong impression, I meant just testing a game with SteamTinkerLaunch that you hadn't used before; a fresh game with no previous launches with STL.

I haven't used STL with this game either, or even launched it prior to today.

I'll try to get a log in a bit.

sonic2kk commented 6 months ago

Yes, it was just because you mentioned "clean install", I didn't want you to think you had to do a clean install each time :-)

sonic2kk commented 5 months ago

I will be taking an extended break from projects for health reasons, but if you are able to get the logs, please submit them. I have not been successful in reproducing this issue sadly but would be interested in finding out what is causing it.

From what I understand it happens with every game by idling on the Main Menu. The processes are spawned about once a second or so, in other words so frequently it is hard to miss (iit would be interesting to know if this happens on other menus, too, such as the Game Menu).

I request logs to see if STL is running a process or function repeatedly. For example, if it is constantly calling a certain function or attempting and failing to do something, we might see a lot of these. In addition, this would result in a log file becoming fairly large.

SteamTinkerLaunch logs for the last execution are stored at /dev/shm/steamtinkerlaunch/steamtinkerlaunch.log. The log file can be quite lengthy but should be possible to follow, and a section that is repeated constantly should stand out. Log lines contain a timestamp, the log type (mainly INFO,SKIP, ERROR), the name of the function that called it, and the log message itself. Example: Thu 18 Jan 20:23:16 GMT 2024 INFO - checkIntDeps - Yad is set correctly in the Global Config, nothing to do.

If you are unable to reproduce the problem further, feel free to close the issue. If you discover the cause please detail it, and optionally open a PR if you find an issue in the code. I'm unsure what causes this, I have not encountered this and it has not been reported before to my knowledge. If this has happened before it would've been a couple of years ago at least, and likely not widespread, so unfortunately it is not as straightforward as simply reproducing the problem it seems, and more investigation work will be needed - not necessarily by you alone, just in general. This is simply a note for anyone else that might pick this up while I'm gone (as unlikely as I think that will be...)

Hopefully we can get to the bottom of this, it is certainly one of the stranger issues I have come across.

sonic2kk commented 5 months ago

Have you been able to track down logs ? I'm curious as to what might be causing this. :slightly_smiling_face:

sonic2kk commented 5 months ago

Closing, please feel free to re-open anytime if you have more information to provide. I am still unable to reproduce the issue, and have not seen reports of this happening to other users, so I am not sure that the problem is widespread.

If you get logs it would be good to check if something is being called repeatedly as described a couple of comments above. I have not seen this in my own logs and testing, so I cannot figure out the problem unfortunately.