Cannot update apps in bulk with "am -u", the process is stuck on second app. To reproduce: run echo $?, result should be "0" (correct), not "1"

[ivan-hc]

Recap: @aljustiet have this issue

I checked the /usr/local/bin/am using ls -l, and it turns out that it's symlink to /opt/am/APP-MANAGER.

So the installation is correct

I ran this command (am -u), and I got this output:

1.mp4

Questions and answers

May it be that it is updating something and you need to wait?

No, the process finishes.

let do another test, remove or comment the line1058, the one containing only wait and try am -u --apps again

It still finishes with 1, which makes topgrade fail the am.

@aljustiet just curious, have you got appimagelauncher installed on your system?
I ask because it conflicts with AM and other AppImage managers https:/ivan-hc/AM?tab=readme-ov-file#failed-to-open-squashfs-image

Yes, I have it installed. Should I remove it?

I said yes, "remove it, reboot and retry", and then @aljustiet said

I removed it using pacman and deleted leftovers in ~/.local/share/applications, then rebooted, but still having the same behavior.

NOTE: the issue does not appear in AppMan and try to remove/reinstall AM

https://files.catbox.moe/4fx5jd.mp4

this is a video of the user running am -u and then echo $?, correct result should be 0, not 1:

4fx5jd.mp4

Originally posted by @ivan-hc in topgrade-rs/topgrade#906 (comment)

[ivan-hc]

@aljustiet have you tried with a virtual machine, docker/podman/distrobox, a fresh installation or another distro?

I'm sure that there is some configurations somewhere that prevent the apps to be updated in bulk.

As you said, if you specify the name of the app(s) they are updated fithout issues... am I wrong?

Also, if you execute the AM-updater directly, no issue at all IIRC

[ivan-hc]

Still originally posted by me, a way to reproduce the issue is to comment the line in APP-MANAGER containing only the command wait

simplescreenrecorder-2024-09-27_21.03.29.mkv.mp4

I can reproduce the issue... so it si probable that @aljustiet have a problem with the wait command!

When I asked, this was the answer:

Uhm... interesting

I can reproduce the issue... you have a problem with the wait command!

Mine still exits with 1.
I don't have an alias with wait, btw.

I mean, have you installed Arch only recently as a fresh installation or is it a long time installation on your PC?
I ask because you may have touched something in the time that breaks wait or a related process.

I've been using for about 8 months.

so I asked to @aljustiet to share some files from the HOME

zshrc.txt bashrc.txt profile.txt bash_profile.txt

I'm unable to download the bashrc

I have seen a lot of stuff in the zshrc file, while .profile is really different from mine.

The zshrc file also contain several aliases and export PATH=

So I asked @Samueru-sama to check the filse, and him said

@ivan-hc I'm not sure that the shell config files have anything to do here given that appman doesn't have the issue.

I'm not sure, but from what I've seen, the process stops on wait, and the user-shared files have a lot of additional and custom configurations. It's likely that some parameter is conflicting.

On a fresh system install, the problem should not recur.

---

Fun fact, I was pushed again to recap this issue because the last comment, that quoted what we said about AppImageLauncher

Should I remove it? I use it when there isn't appimage that I want in the AM repos

remove it and reboot, then try again.
In my experience, many users had issues when AppImageLauncher is installed, as you can see from the issues linked in the throubleshot I linked above.
Also, AppImageLauncher is no more developed from 2 years, if you need a tool that does the same thing, use GearLever (flatpak) or the --launcher option available in AM (yes, AM can do also this).

But it doesn't work. I launched the electrum-ltc AppImage using it; it created the file in ~/.local/bin, but it isn't desktop, and because of that, it's usable only in dmenu mode. But I use rofi, and it doesn't appear there.

so here appear another issue: the option --launcher, the one that does what AIL and GearLever already do, in SHELL, does not work correctly. The binary in $PATH is created, not the .desktop file, so it is not extracted.

This lets me thinking that there is something else in the system that manages AppImages.

I suspect for a running daemon or library left installed, also after @aljustiet have removed AppImageLauncher.

I have already an issue about #988

But if AppImageLauncher can be the issue... what about AppimageD? Or other similar tools and scripts?

This is all related to AppImages.

---

Now we have two issues:

• the user have something in background that manages appimages, a daemon? A library? A script? A mallware?
• update stops when touching the wait command, that is a command built into SHELL.

A fresh system installation should solve both. I don't know what come out from AUR in the 8 months the user have Arch Linux installed.

If I had Arch Linux, I would avoid to "abuse" of the AUR.

I close this issue for now.

@aljustiet for any news, contact me here.

[aljustiet]

@aljustiet have you tried with a virtual machine, docker/podman/distrobox, a fresh installation or another distro?

I'm sure that there is some configurations somewhere that prevent the apps to be updated in bulk.

As you said, if you specify the name of the app(s) they are updated fithout issues... am I wrong?

Also, if you execute the AM-updater directly, no issue at all IIRC

Yes, if I update the AppImages directly using am -u appimage, it finishes with exit code 0.
The /usr/local/bin/am is just a symlink to /opt/am/APP-MANAGER, and because of it, using both results in the same issue, finishing with exit code 1.

[aljustiet]

I just switched to AppMan because solving the issue with AM had been taking lots of time.