0

Since switching from Kubuntu 20.04 to Ubuntu Studio 22.04 (both use KDE Plasma), I have had a strange cluster of issues. I'm wondering if they could be connected, but my main goal is to find a solution for issue #1. Anything else is icing on the cake.

I originally posted this as a much simpler question about issue #1, along with what I originally thought was the answer and a solution (which is still posted as my answer below... not sure if I should delete that).

The Issues

There are two strange things that are happening in my Ubuntu Studio install, but not always:

#1 - fluidsynth process sometimes starts automatically at boot. This really shouldn't happen. Fluidsynth is a synth and is the backend for QSynth and fluidsynth.dssi. This distro contains a lot of synths and there's no reason why this particular one should auto-start. Also, when fluidsynth starts in this way, I can't end the process in System Monitor - I have to do the ol' "killall -9 fluidsynth".

With the answer I initially posted below, I have since deleted the override file and reverted the WantedBy= variable back to multi-user.target. Neither the presence/absence of the override nor what I have that variable set to seem to make a difference. Neither causes the behaviour to always happen or to never happen.

#2 - sometimes, on boot, the cursor flashes a few times in the login box and then freezes and I can't log in, shut down, or restart. I have to go to tty and restart sddm.service and then everything works.

Possible Connections

There doesn't seem to be much consistency in what's happening. However, the two above phenomena seem connected. For example, just now, on booting, fluidsynth was auto-starting. It did this twice in a row. Then, on the third boot, I had the login-freeze issue. I restarted sddm.service, logged in, and fluidsynth did not autostart. Then I rebooted again, the login worked fine and fluidsynth didn't start. Everything seemed in order.

Another possible connection is that this might be more likely to happen after I've booted into Kubuntu on the same laptop, shut it down, and then booted into Ubuntu Studio. Before this latest round of auto-starts, I had just booted into Kubuntu. In Kubuntu, fluidsynth never auto-starts. The issue(s) also seem more likely to happen after certain system updates (as opposed to software updates).

Startup Programs

There is a fluidsynth.service in systemd. However, when I list in the terminal all systemd services, running or otherwise, including ones that are supposed to start at boot, fluidsynth doesn't show up in the lists. It also doesn't show up in the Ubuntu Studio settings for startup programs.

Other Possibly Relevant Info About My System

My distro uses a mix of ALSA, Pulseaudio, and Jack2 for sound. I can also see that there are some Pipewire processes in the System Monitor, but nothing "customer-facing" uses Pipewire (i.e. I don't, and can't, interact with it at all).

Info I've Tracked Down That Might Help With a Diagnosis

To try to get to the bottom of this (not really knowing what I'm doing, just following tips on the 'net), I found that the UID for fluidsynth process was 1278, so, in the terminal, tried the following (posted as a pic because I don't know how to paste the nesting)...

fluidsynth UID status

(The chart continued but I only copied to here to save space. Fludisynth doesn't connect to any of the remaining entries. Note that in the above, it is the default-GM soundfont that fluidsynth is loading. Fluidsynth needs a soundfont to be loaded before it can make any sounds. In that sf3 folder, there are several soundfont files, but for some reason this one is loading.

At the end of that output tree, this follows...)

fluidsynth UID status, ps

I also checked the system log for fluidsynth and got this...

system log

So with all this info, can anyone help me diagnose/solve my issue(s), or at least point me in the right direction?

Royan
  • 157

2 Answers2

1

This answer is an older post which I thought solved my issue, but later discovered that it doesn't. I will leave it here for now in case it can be in some way helpful. As it stands, I just removed Fluidsynth. Any proposed solutions I will try if I have the same issue when the next Ubuntu Studio LTS comes out.

I found an answer to my original question, as well as a solution (thanks in part to help from Muru in the comments).

The reason Fluidsynth was starting automatically at boot was that, unlike when I was using a Kubuntu 20.04 install with the Ubuntu Studio wrapper, this Ubuntu Studio 22.04 install for some reason has Fluidsynth set to do so.

In the file, /usr/lib/systemd/user/fluidsynth.service, under [Install], the WantedBy= variable was set to default.target, which triggers a start at boot. Kubuntu 20.04, on the other hand, had this set to multi-user.target and the process didn't auto-start.

I initially just changed this variable in the new install to match how it was set in Kubuntu, which did work, but Muru suggested that a future update could revert this back to the default. So, instead, I have done the following:

In the terminal...

systemctl edit --user fluidsynth.service

This creates a new folder in /home/user/.config/systemd/user called fluidsynth.service.d, and a new override file in this folder, and opens the latter for editing in the terminal. Under the line, "Anything between here and the comment below will become the new contents," I added...

[Install] 
WantedBy= 
WantedBy=multi-user.target

My text editor (which has been opened in the terminal) is Nano, so after adding the above three lines, I entered Ctrl+O to save the changes, accepted the file name offered to me, and then exited with Ctrl+X.

Now, this newly created override file in my /home folder does some kind of magic in the root folder which stops systemd from automatically starting fluidsynth at boot.

Royan
  • 157
  • 1
    Don't edit that file directly as your changes will be lost the next time the package is updated. Use systemctl edit --user fluidsynth.service instead – muru Dec 19 '22 at 02:00
  • Thanks. This is interesting: in preparing to follow the instructions in your link, I tried both "systemctl cat fluidsynth" and "systemctl status fluidsynth." Both came back with fluidsynth.service not being found, even though I can see the file in the appropriate root folder, and even after I start the process manually. Then I reverted the changes I made to the file to the default which seemed to trigger the auto-start and rebooted, and it no longer auto-starts. So... not sure whether to accept my own answer; it did solve my problem, but not in a very straightforward way. Any thoughts? – Royan Dec 20 '22 at 01:57
  • You need the --user option – muru Dec 20 '22 at 03:32
  • Oh, ok. It took me a while to wrap my head around how to apply the instructions you linked to to my situation... and also how to edit and save properly in Nano, which is what the terminal opened. I now have the fluidsynth.service.d folder with the override file in /home/.config/systemd/user, and upon reboot fluidsynth hasn't started. I'll wait a bit before editing my answer, as I'm pretty sure this auto-starting was intermittent (even though it seems like it should be always or never). Thanks! – Royan Dec 20 '22 at 23:20
  • I really think you just wanted sudo systemctl disable fluidsynth. The default Ubuntu install appears not to enable fluidsynth (at least I just installed fluidsynth, and it wasn't enabled). Then you would start fluidsynth either manually with systemctl --user start fluidsynth or automatically at logon with systemctl --user enable fluidsynth. Neither would require you to add the WantedBy=multi-user.target as multi-user.target has already been reached by the time you can login. – Auspex Feb 02 '24 at 02:22
  • Thanks, Auspex. I can't try this because my chosen "solution" was to remove Fluidsynth. The application I used it with - QSynth, the front-end for Fluidsynth - strangely doesn't seem to actually require Fluidsynth to be installed (???). However, I do clean installs of each LTS, so if I have the same problem when the next one comes out, I'll give this a shot. Cheers! – Royan Feb 06 '24 at 07:24
0

My FluidSynth started in somehow weird state during a boot. Just after the boot, it competed somehow with PulseAudio and both took around 12% of CPU time each (according program top) and drained my battery swiftly and easily. FluidSynth service was not visible in systemctl, so I think it is a bug.

I got rid of Alsa plugin FluidSynth by renaming and rebooting afterwards:

sudo mv /usr/lib/systemd/user/fluidsynth.service /usr/lib/systemd/user/fluidsynth.service_nevermore

FluidSynth program is still working as a standalone application - it is what I need most.

I know that it is a dirty workabout. :-)

xerostomus
  • 990
  • 9
  • 20
  • I uninstalled Fluidsynth altogether and found that QSynth still works. Like for you, that's what I needed most. – Royan Mar 01 '24 at 07:19