The small linux problem thread

Could Someone help me understand what I have to do to fix this issue. I’m on Mint Cinnamon 19 and my computer keeps soft freezing and then hard freezing after this message appears in my kernel log:

mmap: qtdemux0:sink (3605): VmData 268607488 exceed data ulimit 268435456. Update limits or use boot option ignore_rlimit_data.

I have found a thread where Linus responds to this problem citing a Database Size Limit needing to be deleted or altered, but I’m not quite sure where to find this variable and in what config file it may reside. Thread: https://lkml.org/lkml/2016/9/16/585

I’m not a complete noob and I’m more than capable of editing a config file, but I just don’t know where to look. These hard freezes are really killing me and forcing me to hard reboot quite often. And it’s definitely consistent whereas this is the last message in my kern.log.1 everytime I hard Reset after a lockup.

Try editing /etc/systemd/system.conf and /etc/systemd/user.conf and raise the DefaultLimitNOFILE value

Thanks for the ultrafast response. I’m looking at those config files right now and those variables are currently commented out and have no value at the end. Should I uncomment it and add some arbitrarily larger value or is there a specific value you’d recommend to add to this? Also what’s the syntax, should it be just a large number in bytes or can I specify like 1GB or something?

Check what the current value is with ulimit -Hn

4096 is the current return on that command

Sorry, I jumped to the wrong conculsion and I was thinking about a different issue. On the mailing list the program with the issue is named specifically, but it looks like you’re having an issue with qtdemux0:sink exceeding a hard limit for size. While I’m having trouble finding what that is, you could try the suggestion in the error message of adding ignore_rlimit_data to your boot option; to at least see if it stops your crashing.

You can either add that option to your /etc/default/grub on the GRUB_CMDLINE_LINUX line, rerun grub configuration and reboot. Or you can press e while booting when at the grub menu, and add the the option to GRUB_CMDLINE_LINUX there, without making a permenant change.

I will give the boot parameter a shot to see if it helps with the freezing, however, it was warned against as not a great solution by the man himself. Would you happen to know where the variable for the qtdemux limit resides so I may directly edit that value rather than impose a system wide boot variable change?

I agree that’s not a great solution, but using it temporarily isn’t terrible and will at least help to determine if that error message is part of the crashing that you’re having or if it’s just some unrelated issue in the background.

Alright, The boot parameter is set, I’ll give it a whirl and see if I can recreate the issue. I’ll be back to report if I continue to run into the problem. Thanks for all your help though. Cheers!

Got a stupid question.

If you set env on a launcher for a game with a Wine .desktop launcher, will that env carry through to the actual game? For instance, env WINEESYNC=1 for Overwatch, which has to first launch the Battlenet client.

And more importantly, how can you verify the variable is set according to how the program sees it? Not how the shell variables see it?

It should effect the launcher and every child process of the launcher, including the game. Give it a shot with DXVK_HUD and if you see the HUD you’re golden.

My Environment Variables have a ton of options for DXVK_HUD so I decided to only pass through the fps option. Sure enough, it did the trick.

There should be a better way to verify those variables though for ones that are hard to tell, like Esync.

I can’t believe but with the latest 4.19.9-300 kernel my monitor now works with 95hz. After almost 3 months. I missed this so much! I don’t know if any of you here did something or made a report? But I thank the person.

I will update my post so if anybody is in the same boat as I was will know to update.

2 Likes

You could make the .desktop output the contents of relevant variables to a file as well.

Hey all, I’m having a hard time finding out how to do this because I don’t really know what to search for.

How do I limit the startup time or the shutdown time for a service?

Ubuntu takes minutes to boot, because some services are trying to start and it’s counting 1m30s for each one. Same with shutdown. There’s some UID that’s waiting to stop and so it waits 1m30s to 5m00s for it to stop and reboot/shutdown.

Isn’t there a way to limit this? Like don’t try more than 15 seconds before killing it and just reboot/shutdown?

I’m doing some work on Ubuntu specifically otherwise I wouldn’t really care. But damn every time I reboot I just sit and spin in my chair because the startup and shutdown of some services takes forever.

This sometimes happens on other distros, but it’s rare, if only once after the initial install/update. Not sure why Ubuntu does it every iteration.

My research has gotten me to setting ulimits and for changing the startup time in GRUB lol which isn’t really what I’m looking for.

Any help would be greatly appreciated.

Thanks

I believe you do this thru systemd no?

@Eden talked about how to do this once before. I Forgot what he said.

1 Like

Thanks! I’ll keep poking around.

1 Like

take grub out of quiet mode and watch the shutdown process, it should give you an idea of what specific service is taking so long.

1 Like

If it is a systemd type solve.

Can I become admindev?

1 Like

Yeah, I know what process it is, I hit F12 and watch it tick down.

I want to know how to kill the 90 second countdown.