Removal of --disable-shutdown-check breaks automated background workflows
Closed this issue · 64 comments
Operating System Info
Windows 11
Other OS
No response
OBS Studio Version
32.0.0
OBS Studio Version (Other)
No response
OBS Studio Log URL
https://obsproject.com/logs/JlfFFjMDF7WYfiG2
OBS Studio Crash Log URL
No response
Expected Behavior
When OBS is launched automatically at login via a shortcut in shell:startup with flags such as:
"C:\Program Files\obs-studio\bin\64bit\obs64.exe" --disable-crash-handler --disable-shutdown-check
I expect OBS to start minimized and run silently in the background without showing any “didn’t shut down properly” / Safe Mode popup. This allows OBS to function as a headless/background audio processor (filters → VB-Cable) without any manual interaction after reboot.
Current Behavior
After updating to OBS 32.0.0 (and later), the Safe Mode / crash popup appears on every restart even when OBS is launched with the above flags. The --disable-shutdown-check flag appears to be removed/ignored in the new version, so OBS always complains that it didn’t shut down properly and blocks the intended hands-off startup. This prevents automated background workflows (OBS running as an audio processor) from working, because OBS must be manually dismissed before it will run minimized and route audio.
Steps to Reproduce
-
On Windows, create a shortcut to OBS (obs64.exe) and set its Target to: "C:\Program Files\obs-studio\bin\64bit\obs64.exe" --disable-crash-handler --disable-shutdown-check
-
Place that shortcut in the shell:startup folder so OBS launches at login.
-
Configure OBS to process your microphone (apply filters) and output to a virtual cable (e.g., VB-Cable) so other apps use the processed mic as their input.
-
Reboot the machine (or restart while OBS is running).
-
On login, observe that OBS shows the Safe Mode / crash popup and does not run silently in the background unless the popup is manually dismissed.
Observed result: Safe Mode / crash popup appears every boot, blocking automatic startup.
Anything else we should know?
This behavior did not occur in the 31.x series. Reverting to OBS 31.1.2 restores the previous behavior where the --disable-shutdown-check flag allowed unobtrusive background startup.
Downgrading to 31.1.2 fixes the issue for me.
Use case: I run OBS as a headless/background audio processor (microphone filters and monitor) and route the output to a virtual audio cable (VB-Cable) so games/Discord receive the processed mic. This must be fully automated — on every login — without user interaction. The removal/ignoring of the shutdown-check flag breaks that workflow.
A unclean shutdown doesn't necessarily mean there's an issue that can be fixed by the user, nor does it mean subsequent launches will certainly crash (thus needs safe mode), please don't just take that away.
Does having this flag in the program cause any burden for the development or maintenance? I can't imagine.
Yes, it does. It erodes the trust of the application by accepting that crashes are a normal expectation of using OBS. We'd prefer that these issues are reported and fixed, rather than silently ignored until something catastrophic happens, and we have to hear about how OBS deleted all their data.
Removing the flag has already had the intended effect, as we've had constructive conversations about several before unreported issues/crashes on shutdown that users were explicitly ignoring and not reporting to us.
If we fix even just one of those issues (work for which is already underway) because of the removal of this flag, I consider that enough to confirm we made the right decision.
I also use OBS as a silent background process, mainly as a ShadowPlay replacement via the replay buffer, and often shut down without stopping OBS. With 32.0.0 removing --disable-shutdown-check, every reboot now triggers the Safe Mode prompt and blocks automation.
I understand that this thread is marked "not planned" so I'm not asking to bring back the flag. But it would be helpful to have an official way to indicate a managed shutdown. Right now, the best option is scripting against obs-websocket to stop the replay buffer before exit, but there's no documented way to request OBS to shut down cleanly, and OS-level termination still trips the unclean sentinel.
Is there any openness to adding:
- an RPC that stops outputs and exits OBS while marking the session clean, or
- a launch flag to skip Safe Mode only if the previous session exited via that RPC?
This would preserve the intent of Safe Mode for real crashes while making OBS viable again as a persistent, headless background process.
Same issue, me and my friends are using OBS as a replacement for ShadowPlay as well, and the removal of --disable-shutdown-check breaks startup automation.
While I understand the importance of Safe Mode, and that the flag will not probably be added back, this also means that whenever the system gets shut down in a different way, we will still get the OBS crash popup.
Please reconsider a way for us to enjoy a life without popups after signing in 🙏
I also use it as a replacement for ShadowPlay, please add some way to add this functionality back
The scenarios where this dialog was showing up as a nuisance rather than helping identify problems, should hopefully be addressed by my fixes in #12668
@Warchamp7 I downloaded the Windows x64 artifact from #12668 and tested signing out/shutting down with the replay buffer active, and no crash dialog popped up after signing in! Additionally, the crash dialog still shows up as expected when killing the process with task manager.
Thank you very much!
I'm gonna chime in as well - so far over several reboots (with and without safe mode / plugins) I've not been seeing the crash dialog on both of my PCs with that artifact (Dual PC setup)
I'll definitely be keeping an eye out and hope it'll make it into one of the 32.0 subversions :)
While fixing the windows shutdown bug is good, pretending that OBS will never shutdown unexpectedly (either via a legitimate bug, an unexpected power outage) is frankly silly. This command line option was and is necessary.
We have been using OBS on Linux as a headless background data streamer for a neuroscience project (try to use open source where possible) with many remote systems that are not easy to access, and remote control via systemd was working before 32. We need to have silent restart be utterly reliable and this is now broken on Linux. We will just roll back to the older OBS for the moment, which seems counterproductive to a desire for continued improvement, while we look for a service we can use that allows for robust background use. I understand you want to expose potential problems, but it is still a legitimate point that an end user benefits from flags to bypass technical issues that are tangential or irrelevant to their usecase.
For anyone looking to work around this change on Windows, I wrote a guide detailing the simplest method here: https://gist.github.com/sjain882/3dddf90024aa4f919c6e4e0aa015885b.
Does anyone know where the .sentinel file is stored on linux?
While fixing the windows shutdown bug is good, pretending that OBS will never shutdown unexpectedly (either via a legitimate bug, an unexpected power outage) is frankly silly. This command line option was and is necessary.
For anyone looking to work around this change on Windows, I wrote a guide detailing the simplest method here: gist.github.com/sjain882/3dddf90024aa4f919c6e4e0aa015885b.
With Warchamp's PR (Artifact for downloading and testing) that should not be necessary anymore.
In my opinion, if there's a legitimate bug it should be reported and investigated / fixed.
If there is an unexpected power outage then you probably have more to worry about than a simple popup message from OBS telling you it crashed (which, in reality, it did, as well as your whole computer)
Though I'm not part of the OBS team so I'm not calling any shots here, just my point of view from both a developer and user standpoint
. If there is an unexpected power outage then you probably have more to worry about than a simple popup message from OBS telling you it crashed (which, in reality, it did, as well as your whole computer)
Thankfully, no. When there's a random power outage, most programs installed on our machines don't need to be opened once manually and patted on the head to tell it that nothing's wrong. Unfortunately, OBS now needs this, which is the problem.
We have many small systems which must work in a environment where unregulated shutdowns can be common (computers are essential far beyond a home or office). We still need systems to restart and work reliably, and V32 breaks our use case (stick to 31 or having a service to delete the sentinel file seems the best solution for us)...
On Linux I found the .sentinel folder, and so have adjusted my obs systemd user service to remove the sentinel files before obs starts and after it finishes:
[Service]
Type=simple
# to find some tools installed by pixi or brew etc
Environment=PATH=%h/.pixi/bin:%h/.local/bin:%h/bin:/usr/local/MATLAB/R2025a/bin:/home/linuxbrew/.linuxbrew/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin
ExecStartPre=-rm -rf %h/.var/app/com.obsproject.Studio/config/obs-studio/.sentinel
ExecStartPre=/usr/bin/sleep 15s
ExecStart=/usr/bin/flatpak run com.obsproject.Studio --startstreaming --disable-shutdown-check --minimize-to-tray
ExecStop=/usr/bin/flatpak kill com.obsproject.Studio
ExecStopPost=-rm -rf %h/.var/app/com.obsproject.Studio/config/obs-studio/.sentinel
Restart=always
RestartSec=15
I don't think @Warchamp7 fixes mentioned above fix the Linux problems, where OBS does not clean exit when using flatpak/systemd or terminal commands, so this is an ugly but functional interim solution...
@iandol Warchamp7 tried to fix that. The flatpak artifact from here: https://github.com/obsproject/obs-studio/actions/runs/18026053058?pr=12668#artifacts can be terminated via the SIGTERM signal from the terminal/htop, without create the warning dialog on the next start.
At the moment, it is not solving the problem on shutdown/reboot. But I would say, it goes for the most users in the right direction.
But I think, your use case will always to use the above custom systemd solution from you.
I'm on archlinux with OBS replay buffer as a background service and now I get the message everytime I shutdown/reboot the machine, hope for an official fix now that --disable-shutdown-check is gone
I don't have a good Linux environment to test with, so if anyone can provide some insight or logging of exactly what signals OBS is sent when logging off/shutting down that would be immensely helpful.
~/.config/obs-studio/logs files starts with
Crash or unclean shutdown detected
[...]
and logs ends as soon as replay buffer is activated, no other log lines there after or on shutdown.
journal logs on shutdown time:
obs[3808]: info: [pipewire] Stream 0x560f1e16e0c0 state: "streaming" (error: none)
obs[3808]: info: [pipewire] Stream 0x560f1e492b50 state: "streaming" (error: none)
obs[3808]: info: [pipewire] Framerate: 0/1
obs[3808]: info: [pipewire] Size: 3440x1440
obs[3808]: info: [pipewire] Modifier: 0x200000020937b03
obs[3808]: info: [pipewire] Format: 12 (Spa:Enum:VideoFormat:BGRA)
obs[3808]: info: [pipewire] Negotiated format:
obs[3808]: info: [pipewire] Framerate: 0/1
obs[3808]: info: [pipewire] Framerate: 0/1
obs[3808]: info: [pipewire] Size: 3440x1440
obs[3808]: info: [pipewire] Size: 3440x1440
obs[3808]: info: [pipewire] Modifier: 0x20000002096bb03
obs[3808]: info: [pipewire] Modifier: 0x200000020937b03
obs[3808]: info: [pipewire] Format: 12 (Spa:Enum:VideoFormat:BGRA)
obs[3808]: info: [pipewire] Format: 12 (Spa:Enum:VideoFormat:BGRA)
obs[3808]: info: [pipewire] Negotiated format:
obs[3808]: info: [pipewire] Negotiated format:
obs[3808]: info: [pipewire] Framerate: 0/1
obs[3808]: info: [pipewire] Size: 3440x1440
obs[3808]: info: [pipewire] Modifier: 0x20000002096bb03
obs[3808]: info: [pipewire] Format: 12 (Spa:Enum:VideoFormat:BGRA)
obs[3808]: info: [pipewire] Negotiated format:
obs[3808]: info: [pipewire] Stream 0x560f1e16e0c0 state: "paused" (error: none)
obs[3808]: info: [pipewire] Stream 0x560f1e492b50 state: "paused" (error: none)
is there anything else I can provide?
@Warchamp7 -- first off thank you for your hard work and contributions, you rock! I am using the flatpak install as it supports webrtc. The official way to exit a flatpak is run flatpak kill: https://docs.flatpak.org/en/latest/flatpak-command-reference.html#flatpak-kill -- it doesn't specify what signal it sends but an online search suggests this may be a SIGKILL -9
#10011 suggests that neither SIGKILL -9 nor SIGTERM -15 cleanly exit OBS on Linux. I can try each and report whether .sentinel is deleted
Didn't want to make messy scripts and resorted to denying write permissions to the folder in question:
...\AppData\Roaming\obs-studio.sentinel
Right click -> Properties -> Security -> click "Edit" beside "To change permissions, click Edit." -> deny Write permission to relevant groups
I only had myself (admin) as an owner of the folder and denied myself write permissions. Works flawlessly and the world is good again.
My 2 pesos: Not having any data notwithstanding, I'd argue that the flag they removed is a "power user" tweak and, by virtue of that, it's ultimately a "2% problem". I'd be shocked if more than a few % of daily active users actually use this flag.
Most users will use OBS normally, and on a bell curve, these users fall within the mean ± 1 standard deviation, which would mean the most significant issues that would impact the most amount of users would be found.
I understand the motivation, but given that the power users that use this flag are finding (and needing) workarounds makes the deprecation of the flag a moot point with no tangible benefit that will materially move any needle.
Just my thoughts. I could be wrong and it turns out half of daily active users use the flag, but even so, the other half should be creating enough bugs/crashes to some moderate degree of significance that the team would be able to see what's going on and address it.
If a warning for an unsafe shutdown is absolutely necessary, could it not be in an unblocking manner that doesn't need user interaction? The decision you have made about removing it is obviously based on data available to you, but the vocal minority complaining about data-corruption from using a flag meant to disable a safety feature is not, to me at least, a party you should base changes around.
The silent majority of people that use this flag are aware of the potential problems it can cause, and have deemed it fitting for their use-case, taking away that freedom because it "erodes the trust of the application" is counter-intuitive because at least to me, I now have lost "trust" in updates being beneficial as my workflow broke due to a tiny little hidden patchnote about a deprecated launch flag.
Chiming in as another user who runs OBS in the background. I control startup and shutdown via a Stream Deck and thus shutdown via a button is much easier than trying to shut down with a virtual cam running which is some 5 clicks vs. 1 press. Please bring this back for the people who know what they are doing and use this flag appropriately.
this has got to be the absolute worst argument ive ever seen in favor of removing this flag. i genuinely do not believe for a second that this has given you any new data, other than of course everyone universally hating it. i will probably never update obs again. good job on you for only making things worse.
personally, i use obs as a clipping software like many many others, and this flag was ESSENTIAL for that to function. because yeah, in the big 2025 im not going to have to do everything myself. signal rgb shuts down. steam shuts down. nordvpn shuts down. but obs just has chronic anxiety i guess. so the next time i log in, signal rgb starts up. steam starts up. nordvpn starts up. obs has a panic attack. this is actually so absurd.
please get back to me when its safe to update my products without fear of ruining everything i use them for!!
also thank you so much to sjain882 for the guide!!!! you are seriously awesome
Unacceptable and not relatable change. I am not going out of my way to use task scheduler or anything of that sort. The OBS team knows better than this. If you are going to remove a feature that many people rely on at least make sure it works flawless without it.
We encourage anyone who was using this flag to test #12668 to determine if this fixes their use cases. We strongly feel fixing the unclean shutdown situations is the better option than just adding the flag back and accepting the risks of data loss.
that solution does not include linux environment, also I experienced no data loss in over two year of flag use
Data loss caused by OBS? How?
Not a dev, so please take everything with the mode "easy speaking":
@amigthea It does, Warchamp was also investigating the Linux situation and some user tried to help them with logs. On my side, the SIGTERM behavior is fixed with it. On other users, not. So it needs more testing and figures out why it behaves different.
In general, the method who signal the next obs instance that the obs shutdown was unclear, was moved "up", so it occurs earlier in the shutdown process. So obs is with that PR more concern over it own internal system and a little bit less about 3rd-party.
@amigthea @L4cache In the shutdown phase of obs, it writes the actual settings/scene-collections back in the config files. An unclear shutdown can lead to corruption of that.
It doesn't mean in your workflow, but in general. That is what Warchamps PR try to adjust. That workflows, who shouldn't be affected by that, don't get the warning on restart.
In the shutdown phase of obs, it writes the actual settings/scene-collections back in the config files. An unclear shutdown can lead to corruption of that.
So basically, the damage is already done, using this flag or not doesn't change that.
Safe mode won't save that.
Fixing bug is good! But this flag have nothing to do with that! Was there really no one reporting shutdown issues before removal of this flag?
OBS only writes one currently active scene-collection back when shutting down, with backup. Sure, backups can fail, I'm not disagree with that.
But this writing back can probably be skipped? OBS is already writing it whenever the scene changes.
What about random power failures? We are not entering "normal" shutdown phase so no data loss can OBS cause. (There's a chance that my whole drive goes kaboom yeah I know that.)
I think that we're missing the point: this problem is faced even without power failures. What I'm seeing is that in a normal os shutdown request obs can't manage to cleanly stop the replay buffer before exiting, it basically creates the problem itself and blame the user if he didn't take time to open the gui, click on stop replay buffer, and only then shutdown the machine.
Simply issue a command to delete .sentinel and OBS Studio will open. If you are using Windows, you can create a REG_SZ in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run with the parameter
cmd.exe /c del "%APPDATA%\obs-studio\.sentinel" /f /q & start "" /d "C:\Program Files\obs-studio\bin\64bit" obs64.exe --startreplaybuffer --minimize-to-trayWas there really no one reporting shutdown issues before removal of this flag?
As the noise more or less show, no it wasn't reported in that capacity. The fixes/PR now a result that users started to go more in troubleshooting route and the obs devs get now the logs and crash reports.
The disable flag was used for everything on that subject and hide some problems.
What about random power failures? We are not entering "normal" shutdown phase so no data loss can OBS cause. (There's a chance that my whole drive goes kaboom yeah I know that.)
Yea, but maybe there was an active output, who wrote something? The popup is there, to inform, something was not right in the last session, be careful and check your obs setup before you are going to use it again, like before going live on stream. That is the intention of that popup.
What also come here in the way is CEF, who needs to be depended on the content, from under a second to 10 seconds or more, to close. A forced kill of CEF can lead that the browser source/docks are not right functional, until you delete manual some files from the last CEF session.
As I followed the discussion in discord, the flag was never intend to be on a release version, and it was decided to be removed for good. A casual user should be interrupted with it and an automation should be written to stop all outputs before and then send the proper exit signal. The latter is what the linked PR addressed and as I heard did have some successes on Windows so far. So the devs needs still help in testing and reporting in general and especial on Linux.
What I'm seeing is that in a normal os shutdown request obs can't manage to cleanly stop the replay buffer before exiting, it basically creates the problem itself and blame the user if he didn't take time to open the gui, click on stop replay buffer, and only then shutdown the machine.
IIRC that should be also addressed in the PR.
I have been running 2 OBS instances with the pull request by Warchamp (again, Artifact for downloading and testing) with no popups ever since he posted about it, so I can say that (at least on Windows) it seems to work properly - even changing settings before shutting down my PC (without closing OBS first) saves those changed settings.
As Tiberium already said, the biggest data loss would be something like an unclean encoder shutdown which can result in your recording being broken. Whether it's recoverable later is a different story - the fact that it is broken should already be reason enough for it to bring up a popup like that.
(Additionally the settings, as mentioned before, will not be saved properly on an unclean shutdown)
I'm hoping that there will be a proper solution for Linux as well in regards to shutdown / reboot but I'm just an observer on that part so I can't really test any stuff there. Surely there are more qualified users that are willing to lend a hand out there.
Better saying "check you configuration" than "sorry your configuration is gone" (in extreme cases), yeah.
But I'm a (self-proclaimed) advanced user and I know what I'm doing.
I'm just gonna acheive the same goal by denying the write permission to .sentinel.
I'm saying that the obsproject team cares about the majority of the users, that's fantastic. But I'm feeling too little cared.
for any slightly less power users that still want to use obs for clipping and dont want to do any manual configuration or dealing with a buncha extra bs, this is the .bat i use to start obs and prevent it from telling me about shutdowns. all it does it is delete the sentinel folder before launching, so obs has no idea of anything.
@echo off del /f /q "C:\Users\(USER)\AppData\Roaming\obs-studio\.sentinel" 2>nul cd "C:\Program Files\obs-studio\bin\64bit\" start "" "C:\Program Files\obs-studio\bin\64bit\obs64.exe" --startreplaybuffer --minimize-to-tray exit
all you need to do is replace (USER) with your user and place that into a .txt and change the extension to .bat. press "windows + r", type "shell:startup", press enter, and place the batch file into that folder. you should then see that in task manager > startup apps.
now, youll never see that message again! obs is once again the PERFECT clipping software.
maybe, developers, you should add more supporting features that makes it easier to use it this way. maybe an option that doesnt do as much of the shutdown cleanup work, or prepares it in a way that doesnt need it to wrap things up at all. obs is genuinely the best clipping software on earth, because its the best recording software on earth. i would love to do things your way, and whatever is the best way, but what you want right now just isnt it. it isnt simple, nor is it easy to understand for someone that doesnt know everything about all of this. and even if they could get it down if they tried, its so intimidating that a lot of people dont want to even think about it. this is the problem with pc users these days. while yes, most things are dead simple from the perspective of anyone who knows anything, most people know nothing. its not their fault or lack of intelligence or anything (most of the time lol), its just that theres so so so much to learn. and even for the power users who go far deeper than anyone else its such an unbelievable pain to have to constantly come back and troubleshoot every application at all times because everything is constantly changing.
personally, i wholeheartedly believe that flag should not have been removed. if you intentionally remove the warning, obviously its your fault if you miss something. that is completely understood when you make the decision to use it. it is purely survival of the fittest. so either let me make that decision for myself (because i can and will go out of my way to do it in the simplest way possible) or help me do it easier. not everyone knows how to solve every problem, and while i believe people should be more educated using computers, computers shouldnt have to be this hard. i have many friends who ive shown how to use obs for clipping because its such an amazing feature, and now ive had many friends that have no idea whats going wrong. so, i post my .bat to try and relieve this problem of an incomplete feature.
please, obs, just make things easier. im 10000% sure that you would have far less negative feedback to this if it wasnt the only easy way to shut down obs without preventing startup. thats LITERALLY ALL we want here. just let me shut down my pc and not have obs scream at me EVERY SINGLE TIME i load windows. i understand the want to have all problems reported, and i agree that this is bad for that goal, but we had no other EASY option. just give us an easy option.
thank you
for any slightly less power users...
Creating a batch file is not necessary. To avoid this and account for instances where you wish to run OBS as admin (e.g, for hotkeys in elevated programs and/or improved performance), you can follow this guide: https://gist.github.com/sjain882/3dddf90024aa4f919c6e4e0aa015885b
With Warchamp's PR (Artifact for downloading and testing) that should not be necessary anymore.
I have been running 2 OBS instances with the pull request by Warchamp (again, Artifact for downloading and testing) with no popups ever since he posted about it, so I can say that (at least on Windows) it seems to work properly - even changing settings before shutting down my PC (without closing OBS first) saves those changed settings.
With all due respect, your individual anecdotal experience, while valuable, does not mean that it will be everyone's experience. Given there is still a confirmed instance where shutdowns happen uncleanly (Linux), many more could exist that are yet to be discovered.
Until all those are confirmed solved and OBS can always be trusted to shut down cleanly on every system configuration, OBS configuration and user workflow (quite difficult to achieve), bypassing the shutdown check will absolutely remain necessary for certain users' workflows, which many can't afford to simply break or risk breaking overnight.
Until all those are confirmed solved
Which requires a version with those changes to be released to the public so users can actually test more cases and, optimally, also report issues instead of just enabling a flag to ignore them.
As for Linux, there has been some more ongoing discussion in the OBS Discord and it seems a bit trickier to get it working reliably there due to the differences in desktop environments.
One user mentioned it could be that during a shutdown the desktop / window manager seems to shutdown before OBS does which could cause it to crash for a legitimate reason as a side effect... Seems to be a tougher nut to crack due to all the different distros / desktop environments...
so users can actually test more cases
You appear to dismiss the fact that not everyone is in a position to do this, yet it has been forced upon them with OBS. A phenomenon rarely observed in most user-facing software!
While I appreciate the feedback here, I think this thread has run its course and has come full circle. I'd prefer to not have this just be an argument back and forth about if or if not we should return the flag to disable the check; that decision has already been made. If this is an immediate disruption to your workflow, and you are unable to enact any of the provided workarounds for the short term, not updating is always an option here. We do not force updates.
Let's try and focus on testing the PR, and providing usable feedback for use cases where OBS is given a graceful shutdown signal that are not already covered by the PR.
I just want to add that for Windows users denying the write permission is the simplest workaround.
It's just the basic access control built into the operating system itself and is already always there, no extra files, scheduled tasks etc. needs to be created.
I guess if you use it for automation tasks you probably have some "extra" things created already, but this is least amount of change imo.
First described here: #12650 (comment)
You don't need to be Admin user to do it. The sentinel folder C:\Users\[User Name]\AppData\Roaming\obs-studio\.sentinel is located in user folder, it's owned by user, so non-admin users still can change their own sentinel folder.
You can add an "Everyone" user to make it one step.
After this no one can write to this folder (in normal way, don't take this as a serious security approach), including yourself. But you can revert the modification you have done to grant access just in case.
BTW, the Roaming folder is meant to be synchronized (I'm sure no one's actually using it that way though), writing per-instance sentinel thing inside a synchronized folder makes little sense, didn't it?
i even added a workaround to delete .sentinel folder first before starting obs silently in background, why is this option got removed? i've encountered zero problems with this option for several years
Hi, I'm also affected by this, I opened an issue about this almost 2 years ago and was given the workaround to just use --disable-shutdown-check which now does not work. As I run OBS on startup this causes the safe mode prompt to appear on every boot.
The specific shutdown issue aside, I think it's a terrible idea to remove the --disable-shutdown-check flag. This is a program that can do all sorts of things and as shown in the above comments people will use it in all kinds of unforeseen ways. It is not possible to fix every single bug for every single use case. There will always be someone that will be screwed over by this. In my opinion, there MUST be a way to disable this behaviour. I understand if you don't want it to be a GUI element but a flag is something only advanced users who know what they're doing will use anyway.
And on a personal note, updates breaking my workflow is about the worst thing you can do to "erode my trust". Suffice to say I am not updating again without thoroughly going over the update notes.
Please test this PR if you are having issues on shutdown, and report if the issue is resolved for you, and provide logs/crash reports if it is not:
I just want to add that for Windows users denying the write permission is the simplest workaround.
Worth noting that the Task Scheduler approach makes it easier to toggle bypassing of the shutdown check by enabling/disabling the relevant task with a right click.
With permission denial, however, its more likely that a novice user will have to come back here to remind themselves of which dialogs to dig into.
Finally, if the user is already setting up or tweaking their OBS Autostart functionality, they'll be able to create/toggle the shutdown check right there in Task Scheduler in one go (which is the ideal way to setup OBS Autostart)
Normally, I would have asked to continue in a discussion instead of an already closed issue, but since discussions are not to be used for support questions or feature requests (and changing the prompt to non-modal or adding a flag is kind of a feature request) I was unsure if that is in your interest.
Please advice on how to best keep this topic constructive for you!
The main arguments that I could gather from this thread in favor of the removal are the following:
- The flag hides faults and limits reports
- I don't think the intention is to hide faults. The objection is the modal nature of the prompt, blocking startup. I don't think an informational prompt would be seen as problematic.
- Allowing bypass erodes trust in reliability
- Reliability includes automatic recovery, since software can't be perfectly reliable. The prompt prevents automatic recovery after a crash and breaks automation.
- The flag was never intended for release
- Intent should not outweigh deployments once workflows depend on behaviour. Right now, there is no reliable path for automation.
- The warning is justified since unclean exits can corrupt recordings or configs
- Making the user aware of possible corruption is valuable but this should not block operation.
- If e.g.
--startrecordingor--startreplaybufferis set, a missed prompt causes missed captures, which is avoidable.
- Simply don't update
- Advising users that rely on automation to not receive any security updates does not seem like a viable alternative, especially long-term.
I think the majority of complaints would be resolved by making the prompt non-modal. Faults remain always visible, not limiting reports, and OBS is not blocked from working when it doesn't need to be. This resolves automation, as well as a user simply missing the prompt and expecting OBS to start recording due to e.g. --startreplaybuffer, which seems like a common use case in this thread.
It would also be possible to keep the prompt modal by default, and provide a non-interactive mode that doesn't show modal prompts via flag, e.g. specifically --startup-prompt-nonmodal or perhaps less verbose with common flags like --quiet/--silent/--noninteractive. These should not reduce trust in the software, as allowing to suppress prompts is common.
While workarounds are certainly possible, it seems like non-interactive usage should be a valid use case and supported by OBS.
It's great that OBS will be able to shutdown gracefully more often, but recoverability from a crash should not be unnecessarily limited and is a requirement for non-interactive usage.
Addendum: https://obsproject.com/kb/launch-parameters still lists --disable-shutdown-check as available.
For people like me who use a minimal obs install on linux just to take replay buffer clips here's a script that clones the repo, disables safe mode check, compiles and makes a symlink to the executable called obs-unsafe. I don't guarantee this won't break anything. You also need the obs build dependencies normally so go take a look at those.
#!/usr/bin/sh
if [ -d "obs-studio" ]; then
cd obs-studio
git checkout .
git pull origin master
else
git clone --recurse-submodules https://github.com/obsproject/obs-studio.git
cd obs-studio
fi
sed -i '/program.checkForUncleanShutdown()/ s/^/\/\//' frontend/obs-main.cpp
mkdir build
cmake -DENABLE_RELOCATABLE=ON -DENABLE_NEW_MPEGTS_OUTPUT=OFF -DENABLE_JACK=ON -S . -B build/
make -C build
cd ..
ln -s obs-studio/build/rundir/RelWithDebInfo/bin/obs obs-unsafe
Please don't blame me for anything that breaks after doing this. I only did this for myself and decided to share in case it helps someone. The fact that I have to resort to something like this is unbelievable. Why there are safe mode checks turned on by default despite there being a --safe-mode flag is beyond me and whoever decided to remove the --disable-shutdown-check flag needs to use a modern program.
The flag was removed in OBS 32.0. We recommend fixing the issue causing OBS to uncleanly shutdown, or using our forums or Discord for further assistance with your automations.
Thank you!
@Fenrirthviti in a headless system, there’s nothing to fix when Windows shuts down normally (by pressing the power button). The issue arises when the headless system boots up again, as there’s no mouse or keyboard available to start OBS as intended. This breaks any use case where we rely on automated startup. Of course, removing the .sentinel would help in a batch script, but I’m not sure if the intention is better to force users to mess with the OBS file structure instead of providing a clean command-line flag?
OBS is not designed as, and is not supported to be, a headless application.
Yeah and apparently it's not designed as and is not supported to be convenient lmao. Who cares what it was designed for? There was a functionality that at least some of its users depended on and it randomly got taken away for basically no reason as far as I'm concerned. Whatever internal discussions the devs might've had doesn't concern me. If this specific flag is taken away then at least it should be replaced with options such as --no-exit-prompt-when-replay-buffer, --no-exit-prompt-when-recording, --no-exit-prompt-when-streaming, --no-exit-prompt-when-virtual-cam or something similar. If it was used to "bypass real crashes" and "people weren't reporting issues" then replace it with real intended functionality so people that depend on your program aren't hindered by your actions. If this option doesn't exist then we might as well not have --startreplaybuffer either, what purpose would that have other than automation? Why is --disable-shutdown-check taken away before people are given the option to disable shutdown prompts?
To anyone else coming from Google who's had this issue, here's how to fix it
TL;DR wipe the contents of the .sentinel folder and deny write access to it
Linux
cd ~
find . -name .sentinel
rm -rf ./.var/app/com.obsproject.Studio/config/obs-studio/.sentinel/*
chmod -R 400 ./.var/app/com.obsproject.Studio/config/obs-studio/.sentinel
Windows
- Same as above but
%APPDATA%\obs-studio\.sentinelis the path - Just stop OBS, empty the folder contents and change permissions
Auto-start replay buffer
- I have a startup app that runs this so it functions like Nvidia Shadowplay
/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=obs com.obsproject.Studio --startreplaybuffer --minimize-to-tray --disable-shutdown-check
Bring --disable-shutdown-check back please
Yeah and apparently it's not designed as and is not supported to be convenient lmao. Who cares what it was designed for? There was a functionality that at least some of its users depended on and it randomly got taken away for basically no reason as far as I'm concerned. Whatever internal discussions the devs might've had doesn't concern me. If this specific flag is taken away then at least it should be replaced with options such as
--no-exit-prompt-when-replay-buffer,--no-exit-prompt-when-recording,--no-exit-prompt-when-streaming,--no-exit-prompt-when-virtual-camor something similar. If it was used to "bypass real crashes" and "people weren't reporting issues" then replace it with real intended functionality so people that depend on your program aren't hindered by your actions. If this option doesn't exist then we might as well not have--startreplaybuffereither, what purpose would that have other than automation? Why is--disable-shutdown-checktaken away before people are given the option to disable shutdown prompts?
You CAN disable the prompt to warn when outputs are active. It's the first setting in the Advanced section of Settings.
You CAN disable the prompt to warn when outputs are active. It's the first setting in the Advanced section of Settings.
Yes but obs still complains about not cleanly shutting down. You know exactly what I mean when I'm asking for new launch arguments, don't take it out of context please. What I'm asking for isn't a purely UI method of disabling a box. I want OBS to either cleanly shut down or at least think it cleanly shut down when I have replay buffers on. As it stands every program on my computer can handle a system shutdown but OBS can't unless I fix the developer's idea of a fix myself.
Edit: If the option to ignore unclean shutdowns is removed it should be replaced with actual fixes that prevent the program from falsely thinking it crashed. I should also just have the option to ignore it until the actual fix is implemented.
So not only did the --disable-shutdown-check removal break many people's workflows, it was also done in some random unrelated commit?! As if this change wasn't annoying enough already 🤦♂️😩
I had to go and download the entire repo just to be able to find the specific commit that removed it.
It wasn't mentioned AT ALL in any commit message, or even on the PR's description.
In fact, the PR it's in (PR #11943) literally says:
Types of changes
* New feature (non-breaking change which adds functionality)
* Code cleanup (non-breaking change which makes code smaller or more readable)
Non breaking change??? I'm sure the crowds of people that have complained about this clearly disruptive change would beg to differ.
We need this feature again to automatically start automation when Windows restarts abnormally (Windows or voltage issue, not OBS).
Or workarroud please!
You CAN disable the prompt to warn when outputs are active. It's the first setting in the Advanced section of Settings.
Yes but obs still complains about not cleanly shutting down. You know exactly what I mean when I'm asking for new launch arguments, don't take it out of context please. What I'm asking for isn't a purely UI method of disabling a box. I want OBS to either cleanly shut down or at least think it cleanly shut down when I have replay buffers on. As it stands every program on my computer can handle a system shutdown but OBS can't unless I fix the developer's idea of a fix myself.
You asked for launch arguments that bypass the exit confirmation. I was stating there is already a setting to remove that confirmation window. A launch argument is not needed.
The separate issue is OBS still flagging some shutdowns as unclean when they should not be. There is a separate PR for addressing that bug.
Edit: If the option to ignore unclean shutdowns is removed it should be replaced with actual fixes that prevent the program from falsely thinking it crashed. I should also just have the option to ignore it until the actual fix is implemented.
Have you tested the above linked PR that is aimed at addressing the erroneous crash issues?
You CAN disable the prompt to warn when outputs are active. It's the first setting in the Advanced section of Settings.
Yes but obs still complains about not cleanly shutting down. You know exactly what I mean when I'm asking for new launch arguments, don't take it out of context please. What I'm asking for isn't a purely UI method of disabling a box. I want OBS to either cleanly shut down or at least think it cleanly shut down when I have replay buffers on. As it stands every program on my computer can handle a system shutdown but OBS can't unless I fix the developer's idea of a fix myself.
You asked for launch arguments that bypass the exit confirmation. I was stating there is already a setting to remove that confirmation window. A launch argument is not needed.
The separate issue is OBS still flagging some shutdowns as unclean when they should not be. There is a separate PR for addressing that bug.
Edit: If the option to ignore unclean shutdowns is removed it should be replaced with actual fixes that prevent the program from falsely thinking it crashed. I should also just have the option to ignore it until the actual fix is implemented.
Have you tested the above linked PR that is aimed at addressing the erroneous crash issues?
Could you please send a screenshot of that mentioned feature? I dont see it in settings.
I just wanted to mention another usecase that I have on linux: I use the output timer feature to have OBS automatically stop recording after a given period of time. Sometimes I have to leave the computer alone and so after starting recording, I shh into it from phone and then manually set a shutdown period (say it's currently 16:00, I set OBS to record for an hour, start recording, then ssh and issue command "sudo shutdown 17:05" to have a buffer of 5 minutes and then shutdown). This allows the computer to turn itself off after the recording job is finished.
Back when that "OBS studio crash detected" box was made to appear by default after unclean shutdown, I started using a script with --disable-shutdown-check to autostart with system instead of OBS directly . Now it pops up again at every boot. And since I'm on flatpak, I find no easy way to install an older build that I'm aware of.
I think this has become another case of XKCD Workflow and that flag, however unnecessary to the devs now is a feature to many users (like me) and we rely on it :-/
Have you tested the above linked PR that is aimed at addressing the erroneous crash issues?
@Warchamp7 I started getting cmake errors a few days ago, it was compiling fine before. Is there an issue with dependencies relating to Qt::GuiPrivate or did I mess something up?
I think this specific issue has run its course. I'd prefer we didn't turn this in to a showcase of edge cases of edge cases and support questions, and instead focus on the fix that has been proposed.
As such, I will be locking this thread, as the discussion doesn't seem to be productive or moving in the right direction, and is turning in to a support thread. I recommend anyone coming across this to read all the replies here to obtain the full context before deciding to open a new issue report. Support questions should be posted to our Forums or Discord.
Again, we understand that this is a disruption to certain workflows (supported or not), and are making steps to correct those pain points rather than continue to provide a messy bypass.
Thanks for your understanding as we work through things.