Page MenuHome

Blender doesn't quit after python script/render in background mode (stuck trying to close OpenAL device)
Closed, ArchivedPublic

Description

System Information
Linux Mint 17.2 Rafaela (GNU/Linux 3.16.0-38-generic x86_64), Pulseaudio
(Mate Desktop Environment)

Blender Version
Broken: Blender 2.78 (sub 0) e8299c8
Worked: Same version on Windows 10 64bit and Antergos Linux 64 Bit (with GNOME 3.22.2)

Short description of error
When blender is run through a background command like

./blender -b -f 0

on a system on which the current desktop session is inactive (user logged on, but "switch user" was performed), blender does not quit after completing the render. Same holds for "--python" and "--python-expr" options.

I have a gitlab-ci-runner (build slave for gilab-ci) installed on this operating system to test some blender python scripts. Logging in via SSH and running blender also leaves blender running.

Exact steps for others to reproduce the error

No blend file needed.

  1. Download "blender-2.78a-linux-glibc211-x86_64.tar.bz2" from blender.org/download
  2. Extract
  3. "Switch User"
  4. Log in to same user account via SSH
  5. Run "./blender -b -f 0"

Thanks for being so awesome! :)
Regards, Jonathan.

Details

Type
Bug

Event Timeline

Oh, well.

I forgot to test the nightly build. 69dbeeca48 works! (Sorry, I was confused, the build was running on the Antergos runner instead.) Latest build also doesn't work.

Joey Ferwerda (TheOnlyJoey) closed this task as Resolved.
Joey Ferwerda (TheOnlyJoey) claimed this task.

No problem, can happen.
Will close.

@Joey Ferwerda (TheOnlyJoey) Sorry there was a misunderstanding, I had edited the comment shortly after posting it, you may have only read the original unedited comment sent via email notification?

The problem does still occur with the latest build.

I cannot confirm that, here with latest master, it quits as expected with that command.

Bastien Montagne (mont29) triaged this task as Needs Information from User priority.Feb 10 2017, 11:47 AM

On a side note, please note that running blender -b -f 0 will run your system’s blender, not the one you extracted from archive (unless you properly set paths of course?).

And please also do try the latest build from our buildbot.

Hi @Bastien Montagne (mont29)!

please note that running blender -b -f 0

Yes, sorry, that should have been ./blender -b -f 0. I don't have any other blender installed on that system.

And please also do try the latest build from

I did that on 8th of February (see above comments). Will try a newer one.

I cannot confirm that, here with latest master

Just to be certain: This only happens on Mint 17.2.

The newest build from the buildbot (blender-2.78-38155c7d3c-linux-glibc219-x86_64.tar.bz2) also does not work for me.

Just as follow up, had quick chat over IRC with @Jonathan Hale (Squareys), tried a few more things (like running with debug mode, or with factory-startup) over ssh, nothing new. Here is a result from command line over ssh: http://pasteall.org/241216.

Note that the ultimate Blender quit line is missing, which seems to indicates that Blender is indeed not terminating for some weird reason… :/

More on Monday, test shall be done directly on site in front of the machine, in a regular Bash shell…

@Bastien Montagne (mont29) This kept wondering around in my mind, so I created a Virtual Box with Mint 17.2 and here are my findings:

  • Running from bash works.
  • Running via SSH does not work
  • BUT running via SSH works if the same user is logged on via desktop environment.

This gave me an idea, you won't believe: Force-terminating pulse-audio solves the problem. Yeah, for some reason it waits for a device shutdown I guess? Because the user is not logged on, pulse audio does not react.
Explains why this wasn't a problem on the other systems :D

I hope that helps. Maybe this bug will propagate to openal-soft.

Slight correction:

It only doesn't work, if there is a inactive mate-session running (User is logged on, but "switched user"). It works, if the user is not logged on at all (except for SSH) and if the user is logged on with an active session. I am guessing because for SSH-only pulseaudio is not started and openal uses a different device while for active session, puseaudio responds adequately.

I think for me this is good enough, there is no reason why I'd need to have an inactive session, hence if you want to close this as "won't fix", that is fine with me.

And if you're interested, here's a quick stack trace with gdb while it stalls:

(gdb) backtrace
#0  0x00007ffff771a66b in pthread_join (threadid=140737353905920, thread_return=0x7fffffffdeb8) at pthread_join.c:92
#1  0x0000000002adfc22 in ?? ()
#2  0x0000000002accb54 in ?? ()
#3  0x0000000002ab796d in alcDestroyContext ()
#4  0x0000000001e5f612 in AUD_OpenALDevice::~AUD_OpenALDevice() ()
#5  0x0000000001e5f659 in AUD_OpenALDevice::~AUD_OpenALDevice() ()
#6  0x0000000001e478a9 in AUD_exit ()
#7  0x00000000017eb100 in BKE_sound_exit ()
#8  0x00000000010620fd in WM_exit_ext ()
#9  0x00000000010624de in WM_exit ()
#10 0x0000000000ff1b68 in main ()
Bastien Montagne (mont29) raised the priority of this task from Needs Information from User to Confirmed, Medium.

Nice catch!

@Joerg Mueller (nexyon), not sure whether we consider this a bug in Blender or not? Will let you decide here. :)

Bastien Montagne (mont29) renamed this task from Blender doesn't quit after python script/render in background mode to Blender doesn't quit after python script/render in background mode (stuck trying to close OpenAL device).

Hmm, sounds like a problem of OpenAL/pulseaudio, so I guess there's nothing I can do here. It works fine for me, but then again I don't have pulseaudio even installed. ;-)

There is a workaround however, just use -noaudio and you should be fine.

@Joerg Mueller (nexyon)

just use -noaudio and you should be fine.

Oooh, nice! Thanks!

Tried it out to be 100% sure (not that there'd be anything left to still cause this issue) and can verify that blender quits normally when using -noaudio.
Thanks again everyone. :)

Cool will archive the report then, thanks for the report!