Multiple instances/menubar icons

[mhamann]

Describe the bug
Over time, I seem to have accumulated multiple Alt-tab instances. I'm not sure where these all came from--I didn't do anything to launch them as far as I know. As seen below, multiple menubar icons are present as are multiple entries in Activity Monitor.

I'm not sure how to reproduce this, but I think it occurred within the last 24 hours. My machine's current uptime is roughly 7 days. I believe I've seen this before, but it's not consistent.

All of the running processes have a parent of launchd.

I apologize that this isn't a more helpful bug report.

I'm using version 6.46.0.

Screenshots / video

Steps to reproduce the bug

1. Use Alt-tab as normal
2. Unknown...

[lwouis]

If you double-click on AltTab multiple time, you will notice that it doesn't open multiple instances. Instead, it opens the Preferences window of the already-opened instance.

This leads me to think that you have multiple different versions of AltTab installed on your system. Because you said "Over time, I seem to have accumulated", I'm also guessing that it may be because you use homebrew to install/update AltTab? I could imagine homebrew installs the various versions in various locations on your disk, and if all have the "Launch at login" checkbox checked, then they all separately launch at login (macOS launchd is launching them, technically).

Did you use homebrew to install AltTab? If not, how do you update AltTab? Using the auto-update built into the app, or downloading new versions manually on the website maybe?

[mhamann]

I don't have AltTab installed via Homebrew and I can only find one copy of AltTab.app in Applications. I use the built-in updater to install updates.

$ brew info alt-tab
alt-tab: 6.46.1 (auto_updates)
https://github.com/lwouis/alt-tab-macos
Not installed
From: https://github.com/Homebrew/homebrew-cask/blob/HEAD/Casks/alt-tab.rb
==> Name
AltTab
==> Description
Enable Windows-like alt-tab
==> Artifacts
AltTab.app (App)
==> Analytics
install: 3,759 (30 days), 13,477 (90 days), 36,510 (365 days)

[lwouis]

@mhamann could you please run and share the results of this command?

ps auxwwwe | grep AltTab

It should tell us where the apps are launched from.

[mhamann]

I terminated all of the instances and restarted the process to get things working again, but when it occurs again I'll capture this additional info!

[lwouis]

I'm not going to release an update soon. So I'm afraid this issue may rot. What I can suggest is that you download an older version of AltTab here, you replace your current one with it. Then you open it and trigger the self-update.

That's kind of artificially getting an auto-update to happen. It may trigger the issue, then you can inspect as we discussed above.

[darthwalsh]

@mhamann could you please run and share the results of this command?

ps auxwwwe | grep AltTab

It should tell us where the apps are launched from.

@lwouis Not OP, but I've had the issue of having two AltTab instances a few times. Just now, after OS update, now I'm seeing:

ps auxwwwe | grep AltTab
walshca           1683   0.0  0.3 36616556  85136   ??  S    12:45PM   0:08.87 /Applications/AltTab.app/Contents/MacOS/AltTab USER=walshca SECURITYSESSIONID=186a7 COMMAND_MODE=unix2003 __CFBundleIdentifier=com.lwouis.alt-tab-macos PATH=/usr/bin:/bin:/usr/sbin:/sbin HOME=/Users/walshca SHELL=/usr/local/bin/pwsh LaunchInstanceID=02DACD4F-D096-48BA-8F4F-9F78DF04965E __CF_USER_TEXT_ENCODING=0x1F5:0x0:0x0 XPC_SERVICE_NAME=application.com.lwouis.alt-tab-macos.99453784.99453790 SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.Vsytr3rwMd/Listeners XPC_FLAGS=1 LOGNAME=walshca TMPDIR=/var/folders/qq/x85h5m0x4l9f33041hpnvq680000gn/T/
walshca           1639   0.0  0.2 36611644  76552   ??  S    12:45PM   0:07.88 /Applications/AltTab.app/Contents/MacOS/AltTab XPC_SERVICE_NAME=com.lwouis.alt-tab-macos SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.Vsytr3rwMd/Listeners PATH=/usr/bin:/bin:/usr/sbin:/sbin XPC_FLAGS=1 LOGNAME=walshca USER=walshca HOME=/Users/walshca SHELL=/usr/local/bin/pwsh TMPDIR=/var/folders/qq/x85h5m0x4l9f33041hpnvq680000gn/T/
walshca           8623   0.0  0.0 34271308   1012 s008  S+    1:51PM   0:00.01 /usr/bin/grep AltTab

The CLI args are very different, but one thing suspicious to me is XPC_SERVICE_NAME is com.lwouis.alt-tab-macos vs application.com.lwouis.alt-tab-macos.99453784.99453790. Could different AltTab versions have set up a different launchd?

~ launchctl print gui/501/com.lwouis.alt-tab-macos | grep path                              
        path = /Users/walshca/Library/LaunchAgents/com.lwouis.alt-tab-macos.plist

~ launchctl print gui/501/application.com.lwouis.alt-tab-macos.99453784.99453790
gui/501/application.com.lwouis.alt-tab-macos.99453784.99453790 = {
        active count = 4
        path = (submitted by runningboardd.269)
        state = running
        bundle id = com.lwouis.alt-tab-macos

        program = /Applications/AltTab.app/Contents/MacOS/AltTab
...

I'm out of my depth for what runningboardd is...

[lwouis]

@darthwalsh that's quite interesting and confusing as well. I googled runningboardd and it seems to be internal to Apple, thus undocumented.

Could you please share these info?

• Your AltTab version. If you upgraded recently, how did you upgrade and from which version to which version
• The contents of /Users/walshca/Library/LaunchAgents/com.lwouis.alt-tab-macos.plist

Thank you

[darthwalsh]

@lwouis I was on AltTab 6.46.1. I saw there was an update though, so I updated to 6.47.0 just now.

com.lwouis.alt-tab-macos.plist is:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Label</key>
	<string>com.lwouis.alt-tab-macos</string>
	<key>LimitLoadToSessionType</key>
	<string>Aqua</string>
	<key>Program</key>
	<string>/Applications/AltTab.app/Contents/MacOS/AltTab</string>
	<key>RunAtLoad</key>
	<true/>
</dict>
</plist>

(upgrading didn't change the plist)

[b-pfl]

I can confirm the issue of having 2 instances (but not more) from time to time as well. The way I can notice it is that once I press Alt+Tab the App window appears but starts flickering.

Once the issue appears again, I'll do a ps auxwwwe and will share the results.

I think I downloaded the first version from the Website and since then I use the auto-update procedures once an update is available.

[Neoconair]

My post #2510 has been closed & merged into this one but it only appeared after upgrading to macOS 13.3.1 using 6.56.0

Now happens on every startup.

[lwouis]

@Neoconair from what i've seen so far, my best guess is that there is a bug in macOS that affect only certain people who fall in a narrow path of being at version X and upgrading to version Y, while having a certain version of AltTab.

We can't reproduce it consistently, and people on the latest AltTab + macOS don't have this issue. Or have it then don't have it again after they fix it.

Nothing much we can do here unless someone has more data to help characterize the issue

[darthwalsh]

people on the latest AltTab + macOS don't have this issue. Or have it then don't have it again after they fix it.

@lwouis by "fix" do you mean the workaround of killing both AltTab processes, then launching the AltTab Application? I'm not seeing another fix on this thread.

• I've been consistently seeing the bug of 2 AltTab instances after reboot.
• brew (where AltTab is installed) is updating every day. (I'm on AltTab Version 6.58.0 now, even though I haven't manually updated since I last commented).
• I always install the latest macOS blessed by our IT (upgraded to macOS 13.4.1 today).

---

I'm wondering now if the com.lwouis.alt-tab-macos service is actually the unexpected process here here, and the application.com.lwouis.alt-tab-macos.133465628.133465634 service is expected:

When I search for some other brew apps I've installed, many have an application. prefix"

10275   0       application.com.lwouis.alt-tab-macos.133465628.133465634
3079    0       application.digital.twisted.noTunes.102655377.102655383
2478    0       application.com.googlecode.iterm2.117782967.117782973
3143    0       application.leits.MeetingBar.112503608.112503614

I'm seeing steam and karabiner also have services with the application. prefix, but they don't also have another service with the prefix.

-       -9      com.lwouis.alt-tab-macos
-       0       com.valvesoftware.steamclean
- 3295	-9	org.pqrs.karabiner.NotificationWindow
-	0	org.pqrs.karabiner.agent.karabiner_grabber
3046	0	org.pqrs.karabiner.karabiner_console_user_server
3062	0	org.pqrs.karabiner.karabiner_session_monitor
-	0	org.pqrs.karabiner.agent.karabiner_observer

---

Something I noticed last time I was debugging:

$ brew install alt-tab
Running `brew update --auto-update`...
...
==> Installing Cask alt-tab
==> Moving App 'AltTab.app' to '/Applications/AltTab.app'
🍺  alt-tab was successfully installed!

$ launchctl list | grep alt-tab

87851	0	application.com.lwouis.alt-tab-macos.133465628.133465634

$ ls /Users/walshca/Library/LaunchAgents/com.lwouis.alt-tab-macos.plist
/Users/walshca/Library/LaunchAgents/com.lwouis.alt-tab-macos.plist

$ ps auxwwwe | grep AltTab
walshca          87851   0.0  0.2 36594496  65964   ??  S     2:40PM   0:06.36 ... XPC_SERVICE_NAME=application.com.lwouis.alt-tab-macos.133465628.133465634 XPC_FLAGS=1

So, right after brew install alt-tab there was only a application.com.lwouis.alt-tab-macos.133465628.133465634 service loaded.

The file com.lwouis.alt-tab-macos.plist existed on disk, but the service hadn't been loaded yet. What caused com.lwouis.alt-tab-macos to be loaded?

[lwouis]

Hi @darthwalsh,

This is interesting.

Here is my setup:

• I've set AltTab to launch at login through its preferences. Then I've quit it. At this point, no AltTab instance is running.
• I've manually launched AltTab via the LaunchPad UI
• I've manually launched AltTab via Launchd using this command launchctl load -w ~/Library/LaunchAgents/com.lwouis.alt-tab-macos.plist
• At this point, I have 2 instances of AltTab running at once, even though they are from the same .app, and the app contains explicit code to ask the OS not to allow multiple instances. I guess that code only prevents instances initiated by the user, not Launchd.

Now comes the interesting part. Using launchctl commands, we can

~
$ launchctl list | grep alt-tab
63429	0	application.com.lwouis.alt-tab-macos.32215388.32215394
63613	0	com.lwouis.alt-tab-macos

~
$ launchctl print gui/$(id -u)/com.lwouis.alt-tab-macos | head -8      
gui/501/com.lwouis.alt-tab-macos = {
	active count = 4
	path = /Users/lwouis/Library/LaunchAgents/com.lwouis.alt-tab-macos.plist
	type = LaunchAgent
	state = running

	program = /Applications/AltTab.app/Contents/MacOS/AltTab
	inherited environment = {

~
$ launchctl print gui/$(id -u)/application.com.lwouis.alt-tab-macos.32215388.32215394 | head -8
gui/501/application.com.lwouis.alt-tab-macos.32215388.32215394 = {
	active count = 4
	path = (submitted by runningboardd.372)
	type = Submitted
	state = running
	bundle id = com.lwouis.alt-tab-macos

	program = /Applications/AltTab.app/Contents/MacOS/AltTab

So the application.com.lwouis.alt-tab-macos.*** is actually the instance from manually launching through the UI. Quitting the app indeed removes this entry from launchctl list.

Could you please show me what similar commands show in your case, when you have 2 instances running at the same time? I'm especially interested in the path and program lines from launchctl print.

Thank you

[b-pfl]

I can confirm the issue of having 2 instances (but not more) from time to time as well. The way I can notice it is that once I press Alt+Tab the App window appears but starts flickering.

Once the issue appears again, I'll do a ps auxwwwe and will share the results.

I think I downloaded the first version from the Website and since then I use the auto-update procedures once an update is available.

My current assumption is that the 2nd instance is related to a system restart. Could it be that the option to restart all applications (in MacOS) on restart is cause for this issue?

[lwouis]

One way to launch 2 AltTab instance at once, as we saw from #3550 (comment), is to:

Maybe because I checked inside app "Start at login" and also register this app as "Open at login" in General Setting?

I can't think of a reason why users may want multiple AltTab instances running. We could implement a check a launch, so AltTab refuses to launch if it detect another instance. However, this could have issues:

• How to detect other instances? We should be able to use the BundleID, I imagine. That shouls be safe
• What if the first instance launched is the "bad" one. Launched by something mecanism unknown to the user. Should we also check who the parent of the instance is? It seems hard to know what's legitimate and what's not. Users can have custom setups they enjoy. Maybe just blocking any instance after 1 is already running would be enough?

[darthwalsh]

How to detect other instances? What if the first instance launched is the "bad" one

In my experience: either try to take a named semaphore or an exclusive file lock (possibly those have the same underlying implementation on macOS). This avoids any race condition or needing to decide which instance is "bad."

As a first pass, printing log messages about parent process sounds useful, so the next time "[In-app feedback]" gets created we can start to see the root cause?

[lwouis]

In my experience: either try to take a named semaphore or an exclusive file lock (possibly those have the same underlying implementation on macOS). This avoids any race condition or needing to decide which instance is "bad."

I don't think we could implement something as simple as "first instance gets the spot; other instances will quit". Let's take the example I shared above: the user has checked the checkbox to get AltTab to launch at login. At the same time, they've added AltTab to their Login Items manually. Which one of those should we keep? Also should have the dance of both instance trying to launch, and the second fails, on every login? Or should we take more actions, and try to disable secondary launches root cause (e.g. remove the Login Items programmatically, or remove the LaunchAgent programmatically?

[Thomas1664]

I also encountered the flickering problem caused by multiple instances of AltTab. I did some digging and came across this SO article: https://stackoverflow.com/questions/74714844/how-to-use-named-object-in-macos-to-limit-app-instances

[lwouis]

Thank you @Thomas1664

As I stated above, the issue is not that we can't prevent secondary instances from launching. I think we could do that if we wanted. The issue is then if a user has a wrong setup, 2 instances would try to launch each time, and one would auto-close.

I think a proper solution would be to attack the root cause and disable either the Login Item, or the LaunchAgent, if we notice that both exist.

In the meantime, the best is probably to add logs to see where these instances are coming from.

@Allsochen has added a logging library on the branch we are working on. I think after we merge it, we should use it to add a new log on launch, showing the parent process / the origin of the launch.

Thank you

[milon27]

I'm not sure whether this affects anyone else, but I realized I had both checked the option to "Start at login" and added AltTab to my "Open at Login" Login Items in the General Settings. This resulted in the same problem. I've tested removing the latter and leaving the "Start at login" checked, which resulted in only one instance and no flicker. I don't remember if I manually added it to the Login Items or not.

this helps. but yes alt-tab itself added automatically in Open at Login. i did not manually add this.

[lwouis]

I'm going to address this in the next release. Specifically, I've added the following logic:

At launch, we look at Login Items. If there is an AltTab item listed there, it means that the user has added it manually. In that case, we remove it, and add AltTab as a LaunchAgent, which is the recommended way on recent macOS.

If we don't find a Login Item, they we launch as usual, and add a LaunchAgent if the user has toggled the preferences to do so.

This is not a complete fool-proof fix. Indeed, there are 3 limitations:

• The user can always add some other way to launch AltTab at login, which will make multiple instances happen (e.g. cron, launchagent, launchdemon, etc). Nothing we can do to avoid user shooting themselves in the foot like that
• On login, while we fix the situation by removing Login Item and having our source of truth be the LaunchAgent, we don't kill any process. This means that the user may still experience a double instance one last time. On the next login, it will be fixed.
• The only way to list Login Items is LSSharedFileListCreate as far as my research indicates. This API is deprecated since macOS 10.11. Apple hasn't provided any replacement, so we are forced to use it. We have seen crashes on Monterey in the past, hinting at this API. Hopefully it doesn't crash the app. It's deprecated but is not removed, so it is supposed to be safe to use.

Thank you

[perdomon]

I had a similar issue where I'd have two AltTab menu bar items on startup. Deleting one (or the wrong one) would prevent AltTab from working unless I had focus on the AltTab preferences window, which was strange. This command revealed my issue:

find / -name "AltTab.app" 2>/dev/null

It showed that I had somehow installed two separate instances of AltTab, even though only one was visible in the Applications folder:

/System/Volumes/Data/Applications/AltTab.app
/System/Volumes/Data/opt/homebrew/Caskroom/alt-tab/6.72.0/AltTab.app
/Applications/AltTab.app
/opt/homebrew/Caskroom/alt-tab/6.72.0/AltTab.app

I used brew uninstall alt-tab and rm -rf /Applications/AltTab.app to remove both instances, then installed the homebrew version with brew install --cask alt-tab and the issue was fixed. Hopefully, this saves someone the trouble of figuring it out themselves.