"Albert has not been terminated properly" message on Startup

[Glint-Eye]

Note that this is a general notification that something went wrong in the former run. To find out what happened see the logs. Use journalctl -t albert.desktop if the crash happened while using an instance that has been autostarted by your session manager otherwise run it in terminal and see stdout. Use albert -d to find issues or Q_LOGGING_RULES='*=true' albert to include Qt internal details.

Original post:

#### Description On startup with autostart activated I get the following Popup: "Albert has not been terminated properly. Please check your crash reports and report an issue" I don't know where the crash reports are beeing saved. It started happening for me with installing 0.22.10. I am now on 0.22.12. #### Source xUbuntu 22.04 Repository on Pop OS 22.4 #### Debug output ``` [debg:albert] Albert version: 0.22.12 [debg:albert] Build date: Oct 3 2023 20:29:39 [debg:albert] Qt version: 6.2.4 [debg:albert] Build ABI: x86_64-little_endian-lp64 [debg:albert] Arch (build/current): x86_64/x86_64 [debg:albert] Kernel (type/version): linux/6.5.4-76060504-generic [debg:albert] OS: Pop!_OS 22.04 LTS [debg:albert] OS (type/version): pop/22.04 [debg:albert] Platform name: xcb [debg:albert] Binary location: /usr/bin/albert [debg:albert] Current dir: **** [debg:albert] Font: Fira Sans Semi-Light,11,-1,5,400,0,0,0,0,0,0,0,0,0,0,1 [debg:albert] Language: English [debg:albert] Locale: en_US [debg:albert] $LANG: en_US.UTF-8 [debg:albert] $QT_QPA_PLATFORMTHEME: [debg:albert] $PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin [debg:albert] $PWD: **** [debg:albert] $SHELL: /bin/bash [debg:albert] $XDG_SESSION_TYPE: x11 [debg:albert] $XDG_CURRENT_DESKTOP: pop:GNOME [debg:albert] $DESKTOP_SESSION: pop [debg:albert] $XDG_SESSION_DESKTOP: pop [debg:albert] Icon theme: Pop [warn:albert] Albert has not been terminated properly. Please check your crash reports and report an issue. [debg:albert] Checking for a running instance… [info:albert] There is another instance of albert running. ```

[Glint-Eye]

@Glint-Eye i understand that this may be frustrating, but the only proper solution is to terminate a session correctly. Killing the Xserver under the feet of a GUI application is problematic for every app. This problem affects every Qt app not only albert. Besides the annoying notification this also results in further issues (e.g. albertlauncher/plugins#122).

Hey no worries. I can live with that. It feels like Pop OS is kind of in a limbo state right now, anyways. Until System76 releases their own DE superceding Gnome. So I'd just attribute it to that =)

[tomporter518]

Pulling and building latest (0.22.14), still produces the error upon login (Gnome 44/Fedora 38). Shutdowns/restarts are done via Albert's plugin, i.e. gnome-session-quit --power-off or --reboot.

[ManuelSchneid3r]

@tomporter518 eww, this gives me the impression that the bug may stem from somewhere else. Is this problem 100% reproducible? I'd appreciate if you could disable all plugins and try again to exclude the possibilitiy that any plugin could be the source of the crash on termination (but then again some of the posts above state that a manual termination of albert is always fine).

[tomporter518]

I can try that but yes, manual termination always deletes the socket file. I'm wondering if there is a 'crash' at all (as I've not seen any evidence). Could it just be a race condition such that Albert isn't given the time to 'clean up' before exit?

[tomporter518]

OK, disabling all plugins and restarting via Gnome's tray option (since the system plugin was also disabled) allowed a clean start. Only one data point though. Reverting my config, and restarting the same way, produced the warning/error again. If I can, I will try to isolate which plugin(s) might be the culprit but that's going to take a fair number of restarts. And it could still be a race that having fewer plugins allows Albert to quit, cleanly. A thing to note is that even when manually restarting and then moving the cursor over the tray, there is a spinner for some number of seconds.

[tomporter518]

I have not done an exhaustive set of testing, but it doesn't seem consistent on any one plugin (or I haven't hit the right combo). I do see this in the log when it seems to leave the socket file behind: 20:29:48 WARN QHotkeyPrivate destroyed with registered shortcuts!

[ManuelSchneid3r]

Obviously we need more meaningful logs. Anything printed directly to stdout/stderr will not go through Qt logging and thus not persist on disk after reboot. Can anybody please run albert like this in a terminal, reboot and post the files in a pastebin?:

albert -d > albert.out.txt 2> albert.err.txt

I am not sure though if the terminal and shell make problems while termination. probably they suffer the same problem if systemd sends sigterm to all processes (still assuming that the session thing is the root cause). I cant tell, we'll have to see.

[tomporter518]

I pulled the socket commit, built and tried this last night. The err file is empty. No errors are apparent in the out file, as it only contained:

16:27:51 [info:albert] Hotkey set to Alt+Space
16:27:51 [info:chromium] 40 bookmarks indexed.
16:27:51 [info:terminal] Indexing $PATH.
16:27:51 [info:apps] Desktop file skipped: '/usr/share/applications/albert.desktop' overwritten in '/usr/local/share/applications/albert.desktop'
16:27:51 [info:files] Indexing /home/tomporter/Documents
16:27:51 [info:files] Indexing /home/tomporter/Music
16:27:51 [info:files] Indexing /home/tomporter/Videos
16:27:51 [info:albert] Plugin chromium shadowed: /usr/lib64/albert/libchromium.so
16:27:51 [info:albert] Plugin hash shadowed: /usr/lib64/albert/libhash.so
16:27:51 [info:albert] Plugin terminal shadowed: /usr/lib64/albert/libterminal.so
16:27:51 [info:albert] Plugin ssh shadowed: /usr/lib64/albert/libssh.so
16:27:51 [info:albert] Plugin docs shadowed: /usr/lib64/albert/libdocs.so
16:27:51 [info:albert] Plugin applications_xdg shadowed: /usr/lib64/albert/libapplications_xdg.so
16:27:51 [info:albert] Plugin urlhandler shadowed: /usr/lib64/albert/liburlhandler.so
16:27:51 [info:albert] Plugin template shadowed: /usr/lib64/albert/libtemplate.so
16:27:51 [info:albert] Plugin python shadowed: /usr/lib64/albert/libpython.so
16:27:51 [info:albert] Plugin snippets shadowed: /usr/lib64/albert/libsnippets.so
16:27:51 [info:albert] Plugin debug shadowed: /usr/lib64/albert/libdebug.so
16:27:51 [info:albert] Plugin websearch shadowed: /usr/lib64/albert/libwebsearch.so
16:27:51 [info:albert] Plugin files shadowed: /usr/lib64/albert/libfiles.so
16:27:51 [info:albert] Plugin calculator_muparser shadowed: /usr/lib64/albert/libcalculator_muparser.so
16:27:51 [info:albert] Plugin clipboard shadowed: /usr/lib64/albert/libclipboard.so
16:27:51 [info:albert] Plugin qmlboxmodel shadowed: /usr/lib64/albert/libqmlboxmodel.so
16:27:51 [info:albert] Plugin calculator_qalculate shadowed: /usr/lib64/albert/libcalculator_qalculate.so
16:27:51 [info:albert] Plugin system shadowed: /usr/lib64/albert/libsystem.so
16:27:51 [info:albert] Plugin datetime shadowed: /usr/lib64/albert/libdatetime.so
16:27:51 [info:albert] Plugin widgetsboxmodel shadowed: /usr/lib64/albert/libwidgetsboxmodel.so
16:27:51 [info:files] Indexing /home/tomporter/Pictures
16:28:00 [info:apps] Desktop file skipped: '/usr/share/applications/albert.desktop' overwritten in '/usr/local/share/applications/albert.desktop'
16:28:00 [info:apps] Desktop file skipped: '/usr/share/applications/albert.desktop' overwritten in '/usr/local/share/applications/albert.desktop'
20:00:48 [info:albert] Detached process started successfully. PID: 49229 QList(/bin/sh, -c, gnome-session-quit --power-off)

I have seen this in my journal before, however:

Oct 13 19:57:02 zane albert.desktop[3517]: ICE default IO error handler doing an exit(), pid = 3517, errno = 2
Oct 13 19:57:02 zane albert.desktop[3517]: 19:57:02 [warn:QHotkey] QHotkeyPrivate destroyed with registered shortcuts!

[ManuelSchneid3r]

ICE default IO error handler doing an exit(), pid = 3517, errno = 2

well, seems to be the mentioned bug.

[bgottschall]

I'm still in favor of not annoying albert users with a QT bug that is unknown if and when it will be resolved. Instead of interfering with boot sequences by giving a popup, you could output that in the normal logs to blame it for other issues raised. Currently, I also just delete the erroneous file before albert starts, which I guess is not what you intended.

[ManuelSchneid3r]

As said it's not really a Qt bug. They just could handle it better. I blame desktop environments, especially if they don't shutdown a session properly if their session tools are used. But of course I don't want to annoy users. We're moving atm. I'll add a button to avoid this message soon. In the meantime you could post a bug at your DE issue tracker.

[jgg1971]

I am experiencing this too in Albert 0.22.14, under Linux Mint Debian Edition 6 with Cinnamon. As some people have stated in another thread, there is a side effect: the information kept in the "Files" plugin disappears. The directory tree where the search must be performed is "forgotten" and I have to re-define it. Needless to say, prior to upgrading LMDE 5 to 6, everything worked fine.

[skelly37]

Does the issue need help? I would gladly help if this would speed up the fix

[ManuelSchneid3r]

@skelly37 sure help is always appreciated, but note that this is one of the most toughest issues so far. The issue may stem from several sources and because this issue only appears on shutdown getting logs is quite difficult.

[skelly37]

From what I have seen, the app dies with errno 11, which is SEGV that has no signal handlers registered.

I can try experimenting with some "nice" exit on SEGV but it does not sound like a great idea in general.

The error message is caused by a broken socket, which is good in general, but I think that we could use some better directory. How about using /tmp? It is cleared upon shutdown, in contrary to the ~/.cache/albert. The pop-up will remain there if you areusing your PC casually. On the other hand, you will get no errors related to the previous session (which is most likely not reproducible anyway).

[ManuelSchneid3r]

Segfaults should not be handled but actually fixed.

Why do you think it stems from a broken socket?

The socket is closed on regular teardown. Removing it from the outside just removes the hint that something went wrong and is therefore nor proper solution.

[skelly37]

Segfaults should not be handled but actually fixed.

Correct, that is why I said it is not a great idea. Segfaults can also happen by invalid shutdown that cannot be fixed from the app side, though.

Why do you think it stems from a broken socket?

Well, because the app is force-killed by the OS, it cannot close the socket correctly and it results in a broken socket left behind. And the message we see is caused exactly by invalidated socket.

The socket is closed on regular teardown. Removing it from the outside just removes the hint that something went wrong and is therefore nor proper solution.

How about some toggle to disable this pop-up? The socket will remain in ~/.cache/albert, the pop-up will appear by default but it would be simply possible to say I do not care about previous errors, just give me my launcher back

[ManuelSchneid3r]

I mean did you just read the above or do have reasons for your suspicion? Like logs etc

Segfaults can also happen by invalid shutdown

No (assuming you are talking of a system shutdown), if this is the issue above, the qt ICE error calls exit() which should not result in a segfault. However the left over socket indicates any crash. That's why I am curious why you think there has been a segfault. There are possibly other issues we indeed can fix.

The improper shutdown of a session is a thing desktop environments have to fix or users have to stop using shutdown/reboot cli tools.

[skelly37]

I mean did you just read the above or do have reasons for your suspicion? Like logs etc

Segfaults can also happen by invalid shutdown

No (assuming you are talking of a system shutdown), if this is the issue above, the qt ICE error calls exit() which should not result in a segfault. However the left over socket indicates any crash. That's why I am curious why you think there has been a segfault. There are possibly other issues we indeed can fix.

The improper shutdown of a session is a thing desktop environments have to fix or users have to stop using shutdown/reboot cli tools.

My reasoning for SEGV is that I have got errno 11 in my logs

ICE default IO error handler doing an exit(), pid = 9616, errno = 11
23:12:37 [warn:QHotkey] QHotkeyPrivate destroyed with registered shortcuts!

But now I see that the error above was 2, so seems like a false lead

[ManuelSchneid3r]

Can you all please post the version of your desktop environment and if this bug is appearing if you use the session tools to quit the session? I am trying to get a table of desktop environments to consider and track the issues (we should report there).

[javism]

I can confirm this issue in Linux Mint 21.2 (Ubuntu) both in Cinnamon (5.8.4+victoria) and Mate (1.26.0-1)

[cbanack]

Yup, I've seen this error dialog every morning for a couple weeks, each time I boot into Linux.

I'm Pop!OS_22.04 (the latest LTS) with vanilla Gnome 42.9 running in X11 mode.

Happens if I just logout of Gnome and log back in, or if I fully shutdown and reboot. I can use the Gnome menu to do the shutdown or logoff, or I can use the shutdown or logout commands in Albert. Still happens every time.

[JStyle21]

I"m on Arch with KDE, same here, error has been happening for weeks now on every boot.

[ManuelSchneid3r]

@JStyle21 how do you reboot?

[JStyle21]

@ManuelSchneid3r Mostly i have a shortcut for the poweroff command and then i just poweron the computer But if i need to restart i usually use the KDE Plasma reboot option

[ManuelSchneid3r]

@JStyle21 does it really happen when you use the KDE logout tools? reboot does not shutdown a session properly.

[JStyle21]

@ManuelSchneid3r Just tested, it doesn't

I use the shortcut i mentioned most of the time, i changed it from poweroff to qdbus org.kde.ksmserver /KSMServer logout 0 2 -1

But i consider this a workaround not a fix, this is an application level problem not an OS so at the very least you should be able to suppress warning messages if needed, no one wants them in the foreground like that.

[ManuelSchneid3r]

Don't use cli reboot. It is not intended to quit x sessions.

This is neither a workaround nor a fix. It is the proper usage of the cli to end a kde session (at least until xorg or systemd care about each other's mechanisms).

This is not an application level issue. Not even a toolkit level issue. Simply killing the Xserver is not an option if you want to end your session.

Obviously the process tree should be hierarchical and the processes terminated bottom up. But I'd rather let a committee of systemd, desktop environment and toolkit devs decide on what is the correct way to go.

From the app dev point of view I can't do anything but teach users how to use their system correctly.

[JStyle21]

I appreciate your perspective, but I must respectfully disagree. While it's true that there might not always be a clear right or wrong in the context of system operations, it is crucial for application developers to consider the user experience and provide solutions that are intuitive and user-friendly.

It's worth noting that no other application, including earlier versions of this one, has encountered a similar issue. Currently, the system logs are inundated with warnings, errors, and other messages. If these messages don't present critical obstacles to the user interface, then they should be confined to the log files.

While it is beneficial to educate users about proper system usage, it is equally critical to design applications that proactively mitigate the risk of users encountering such issues. The absence of problems in other applications or earlier versions does not inherently validate the current approach. As technology evolves, so do user expectations, and it is imperative for software to adapt accordingly.

As a developer, even though systemic changes may be on the horizon, you have the capacity to enhance the user experience by making your application more user-friendly and resilient. The objective is not to assign blame to system dependencies but to take ownership of the user experience and ensure that your application seamlessly operates within the broader technology ecosystem.

[douglasthiel]

Can you all please post the version of your desktop environment and if this bug is appearing if you use the session tools to quit the session? I am trying to get a table of desktop environments to consider and track the issues (we should report there).

System Details Report

---

Report details

• Date generated: 2023-11-09 12:48:02

Hardware Information:

• Hardware Model: Apple Inc. Macmini7,1
• Memory: 16.0 GiB
• Processor: Intel® Core™ i7-4578U × 4
• Graphics: Intel® Iris® Graphics 5100 (HSW GT3)
• Disk Capacity: 1.0 TB

Software Information:

• Firmware Version: 481.0.0.0.0
• OS Name: Fedora Linux 39 (Workstation Edition)
• OS Build: (null)
• OS Type: 64-bit
• GNOME Version: 45.1
• Windowing System: Wayland
• Kernel Version: Linux 6.5.10-300.fc39.x86_64

[graue70]

Can you all please post the version of your desktop environment and if this bug is appearing if you use the session tools to quit the session?

Can you please explain what you mean by session tools? You're previous comments seem to suggest that I can circumvent the error message by behaving differently. If that's the case, I don't know how.

[ManuelSchneid3r]

Still debugging. I guess I am on the track now. Atm I suspect it to be some qt quirks with dynamic library (un)loading at teardown (i.e. still runtime).

@graue70 I just assumed that this stems from the usage of systemd to shut down the system. But atm I don't know for sure if it causes this issue. What I do know for sure is that it skips session shutdown scripts. So I can say it is generally not a good idea.

[KingofHubGit]

I have seen three commits to resolve this problem. When will the fixed version be?

[ManuelSchneid3r]

I appreciate your perspective, but I must respectfully disagree. While it's true that there might not always be a clear right or wrong in the context of system operations, it is crucial for application developers to consider the user experience and provide solutions that are intuitive and user-friendly.

Sure but i cant help. This issue is there and extremely hard to track. Why would I not want to give a intuitive an user-friendly solution if I could?

It's worth noting that no other application, including earlier versions of this one, has encountered a similar issue. Currently, the system logs are inundated with warnings, errors, and other messages. If these messages don't present critical obstacles to the user interface, then they should be confined to the log files.

This problem has been there for a long time (#197). I just recently made the warning visible because it is a problem if settings are not saved. And yes, I also wonder why other applications like e.g. CopyQ dont suffer this issue (or do they just accept crashes?).

As a developer, even though systemic changes may be on the horizon, you have the capacity to enhance the user experience by making your application more user-friendly and resilient. The objective is not to assign blame to system dependencies but to take ownership of the user experience and ensure that your application seamlessly operates within the broader technology ecosystem.

I totally agree with that, but as said, there is no solution yet. I spent tons of hours finding this issue, no luck yet. I dont like strategies like that:

[ManuelSchneid3r]

I have seen three commits to resolve this problem. When will the fixed version be?

Which commits? The root issue (ICE error) is not solved yet.

[ManuelSchneid3r]

Can you please explain what you mean by session tools?

using the session tools. something like that:

[ManuelSchneid3r]

This issue is cluttered but has some important information. I opened a new issue https://github.com/albertlauncher/albert/issues/1333 which is only about the ICE error. Please watch it.

[JStyle21]

I appreciate your perspective, but I must respectfully disagree. While it's true that there might not always be a clear right or wrong in the context of system operations, it is crucial for application developers to consider the user experience and provide solutions that are intuitive and user-friendly.

Sure but i cant help. This issue is there and extremely hard to track. Why would I not want to give a intuitive an user-friendly solution if I could?

Just to clarify, I never meant to suggest that you're not interested in an intuitive solution.

It's worth noting that no other application, including earlier versions of this one, has encountered a similar issue. Currently, the system logs are inundated with warnings, errors, and other messages. If these messages don't present critical obstacles to the user interface, then they should be confined to the log files.

This problem has been there for a long time (#197). I just recently made the warning visible because it is a problem if settings are not saved. And yes, I also wonder why other applications like e.g. CopyQ dont suffer this issue (or do they just accept crashes?).

Thanks for highlighting the history of issue #197 and your recent decision to make the warning visible. Exploring how other applications handle similar challenges could provide valuable insights.

Since you've mentioned CopyQ, how about we ask them to reply here and share their insights?

As a developer, even though systemic changes may be on the horizon, you have the capacity to enhance the user experience by making your application more user-friendly and resilient. The objective is not to assign blame to system dependencies but to take ownership of the user experience and ensure that your application seamlessly operates within the broader technology ecosystem.

I totally agree with that, but as said, there is no solution yet. I spent tons of hours finding this issue, no luck yet. I dont like strategies like that:

I understand your POV now and the difficulties you're facing and I appreciate the time and effort you've invested. Also the the meme in on point :)

[ManuelSchneid3r]

Do you guys still experience this issue? In 0.23 I changed the core structure that may be related to this issue.

[AdamPS]

I've not seen this problem recently thanks