stopping jack makes it an unkillable process, destroys htop

[urlwolf]

I have the following problem.
Stopping jack makes it an unkillable process. qjackctl\cadence will complain that jack cannot be stopped. Since I wanted to suspend, I went ahead and did a:

Code: Select all

pkill -KILL jackdbus

This not only does not stop jack; it makes it take 100% of a CPU. And it destroys htop:typing htop will give you an empty window. Top works, but still the process jackdbus is unkillable. I have to reboot.

What am I doing wrong ?

I'm a bit bothered by the lack of relayability of anything jack-related. Turning it on and off is as risky as playing with knifes. Since it doesn't like to be suspended, I don't know what to do.

Since I started doing linux audio, my uptime is measured in hrs, not days anymore

[hebjuzeb]

Turning it on and off is as risky as playing with knifes.

OMG, doubled over laughing, nice analogy. Wish I could help but all I can offer is moral support: the other day I reinstalled Windows from scratch and reinstalled all my software, and the drivers, then spent hours tweaking the services to disable potential problems, and I did it with a smile on my face 'cause I knew when it was done, Reaper would work and I'd never have to look at another JACK crash-log. At the risk of getting banned from the forum, I suggest you do the same. Cheers.

[gazpacho]

Two tips for killing stubborn procesess:
With top pres k , put the process number and when asked write yes.

To find out what goes on, look at all processes in a treelike graph with (leave qith q ):

Code: Select all

ps auxf | less  

Find the process number and do a:

Code: Select all

kill -9 process_number

If that doesnt kill it, try as root the preceding command with sudo , and if it doesnt, better reboot. Watch if what you kill respawns again.

[urlwolf]

All that is what I did. Process is unkillable, only reboot helps.
Scared me straight.

[Thad E Ginathom]

Signal numbers. I don't remember them all, but the most useful are 15 and 9.

kill -15 is handled by the process itself, and that should include exiting gracefully.

kill -9 is unstoppable: it is pulling the rug out from under a process's feet.

(except on the few occasions when it isn't)

[urlwolf]

I repeat, kill -9 was the first thing I did.
This is a smell. something is horribly wrong.
I'll stop sacrificing time. Linux audio: you are fired. (I still use linux for my day-to-day work though)

[j_e_f_f_g]

Jack is horrible. The fact that it was (ill-)designed to work across process boundaries, on an OS that implements per-process address spaces, has resulted in a framework that is convoluted and fragile. It's the wrong approach to software integration. The proper approach is of course a well-designed plugin architecture. Linux audio will not get better until:

1) Folks making music software that operates best as a plugin, release the software as an LV2 plugin.
2) All host software supports LV2 plugins.
3) All host software returns to supporting ALSA directly. Jack-only support is a major mistake.

[urlwolf]

If LMMS:
- Had undo (how can you not have this in 2013?? Makes it useless for me)
- supported LV2

We'd be half-way there. I cannot make it work with alsa, but it should be possible.

[dednikko]

If LMMS:
- Had undo (how can you not have this in 2013?? Makes it useless for me)
- supported LV2

Seconded! Who can we inspire/pay to do this? Any devs willing to dive into LMMS with the focus on these tasks?

Maybe there should be a bounty system for these types of tasks.

[TheSafePlaces]

[...]Wish I could help but all I can offer is moral support: the other day I reinstalled Windows from scratch and reinstalled all my software, and the drivers, then spent hours tweaking the services to disable potential problems, and I did it with a smile on my face 'cause I knew when it was done, Reaper would work and I'd never have to look at another JACK crash-log. At the risk of getting banned from the forum, I suggest you do the same. Cheers.

I repeat, kill -9 was the first thing I did.
This is a smell. something is horribly wrong.
I'll stop sacrificing time. Linux audio: you are fired. (I still use linux for my day-to-day work though)

In over seven months of Linux pro-audio and general purpose use and in trying out two audio distros, the journey has not exactly been a cakewalk, but hey. Apparently people use Linux and JACK to make shit-tons of music, and good music (far, far, FAR too many links to be posted here). If I was having problems, I assumed it was either a screwup on my part or some screwup in my Linux install. Turns out...it always was. I asked around on forums/IRC, got help, problem solved, back to work as usual. Sometimes devs are involved, and no dearth of help there either (a big thumbs up to GMaq, falktx, rncbc, nilsge).

GMaq said something to this effect in the AVLinux manual, no OS is without flaws, not Windows, not Mac, not Linux. It irked me when I first read it (back then I was more like "Linux rox all else sux"), but now I realize...that statement really works both ways. Go back to Windows for audio or what not...and I hope you find a flawless experience there. Hope.

PS - JACK never gave me grief, not on AVLinux and not on KXStudio (and on KX I've set things to autostart JACK on startup, and thus JACK is always on, music-making or not). Not with ANY program. The only time it did was when I was setting it up the very first time, while simultaneously learning the ropes of pro audio and pro audio on Linux. After that initial setup, there's been no trouble ever. And that same line applies to my overall Linux experience.
PPS - What distro are you using?

[Thad E Ginathom]

In over seven months of Linux pro-audio and general purpose use and in trying out two audio distros, the journey has not exactly been a cakewalk, but hey. Apparently people use Linux and JACK to make shit-tons of music, and good music (far, far, FAR too many links to be posted here). If I was having problems, I assumed it was either a screwup on my part or some screwup in my Linux install. Turns out...it always was. I asked around on forums/IRC, got help, problem solved, back to work as usual. Sometimes devs are involved, and no dearth of help there either (a big thumbs up to GMaq, falktx, rncbc, nilsge).

Those guys have done amazing stuff, as developers making stuff work, and also helping others to get things working

Jack gave me grief at first, before I found KXStudio. All I wanted to do was listen to music and do some simple recording and editing work digitising vinyl using a Firewire device. I got more xruns than music. Just like the old vodka adverts, then I discovered KXS.

To be honest, it might have been jack, it might have FFADO, it might have been some other corner of either the PC architecture or the Linux audio big picture giving me grief, I don't know, but it wasn't fun, and if I had been trying to make music, I think my creativity would have just died! Probably, I spent more time screaming at the basic Linux support (or lack of it without tinkering) for Firewire audio than I did shouting about jack.

If it wasn't for Firewire, though, I would never have met jack, and I would never have met KXStudio. I'd have just been using ALSA/PulseAudio, as would any typical "consumer" user who just plays music and occasionally dabbles in a very little recording. Despite the early months of frustration (and it didn't help that I was already loaded with frustration from a previous PC that had a bad attack of the DPC latency problem) I am, on the whole, really delighted that I have met jack. This Audio Connection Kit is just brilliant, and the intuitive ease of making those connections in KXS's Catia is breakthrough stuff.

Is it entirely glitch free? No, but I'd put the glitch rating at under 1%, and it mostly consists of not being able to auto start jack, and that appears to be a FFADO problem, not a jack problem. Frankly, a couple of extra clicks with the mouse is a small price to pay for something that, otherwise, 99.5% of the time just works.

In the future, I intend to keep my firewire device for recording, and buy a DAC/Head-phone amp, because I want hifi headphone listening, which I do not get with my Audiofire2 --- but I will not be abandoning jack/Cadence/Catia, because it is just too good.

This is not to say that nobody has genuine problems, and, in the face of those problems, it doesn't really help to read that stuff is just fine for someone else. It's just to say that it can be just fine.

[tatch]

If LMMS:
- Had undo (how can you not have this in 2013?? Makes it useless for me)
- supported LV2

Seconded! Who can we inspire/pay to do this? Any devs willing to dive into LMMS with the focus on these tasks?

Maybe there should be a bounty system for these types of tasks.

sites like this http://www.freedomsponsors.org/ may be what you're thinking of. idk how many people/audio devs actually look at them though

[raboof]

Stopping jack makes it an unkillable process.

Indeed that should never happen. We should find out what exactly is causing this (and fix it).

Exactly which version of JACK are you using?

qjackctl\cadence will complain that jack cannot be stopped.

I wonder when/why it does that?

Since I wanted to suspend, I went ahead and did a:

Code: Select all

pkill -KILL jackdbus

This not only does not stop jack; it makes it take 100% of a CPU. And it destroys htop:typing htop will give you an empty window.

Interesting

Top works, but still the process jackdbus is unkillable. I have to reboot.

Can you show the output of 'ps aux | grep jack'? In particular I'd be interested in seeing as which USER jack is running, what the process's STAT is (is it Zombified?). I guess we'd also want to see with which RT parameters it's running (scheduling type and priority).