Skip to content

The Eclectic Light Company

Macs, painting, and more
Main navigation
  • Downloads
  • M1 & M2 Macs
  • Mac Problems
  • Mac articles
  • Art
  • Macs
  • Painting
hoakley May 22, 2018 Macs, Technology

Running at startup: when to use a Login Item or a LaunchAgent/LaunchDaemon

There are two popular ways of getting software to run whenever your Mac starts up: it can be installed as a Login Item, or as a LaunchAgent or LaunchDaemon. This article looks at the differences between these mechanisms, so that you can decide which to use in each case, understand what can go wrong with them, and how to fix them.

launchd

macOS brought together the functions of a disparate group of Unix tools, including (x)inetd, init, and watchdogd, in a single service manager launchd, which is controlled by launchctl. During startup, once the kernel is running and required kernel extensions have been loaded, launchd is run with the process ID of 1, and it remains running until your Mac shuts down again.

Before you have logged in, launchd runs services and other components which are specified in Property List files in the LaunchAgents and LaunchDaemons folders in /System/Library, and in /Library. Those in /System/Library are all part of macOS, owned by Apple, and protected by SIP, but those in /Library include many installed by third party products. As they’re run before the user logs in, they work for all users, so are global services.

Once you have logged in, launchd runs any services and other components specified in any LaunchAgents folders in ~/Library. Those are user-specific.

These Property List files contain keyed settings which determine what launchd does with what. Although they can contain many other key-value pairs, two most important ones are ProgramArguments (or Program), which tells launchd what to run, and RunAtLoad, which determines whether launchd should run the service or app whenever your Mac starts up and launchd loads those agents and services.

Other keys determine whether the agent/service should be kept running at all times; if that is set, if it crashes or is otherwise terminated, launchd will automatically start it up again. That is important for background services which apps rely on to function.

You can use this launchd mechanism to run a GUI app as a LaunchAgent if you wish. To run an app such as Bailiff, for example, you would set the ProgramArguments to load the executable code within that app, say at /Applications/Bailiff.app/Contents/MacOS/Bailiff. Note that this is not the top level of the app bundle, which would be at /Applications/Bailiff.app

Launchd is best suited to background services, which use it the most. You don’t need any tools beyond a Property List or text editor to craft its configuration files, although Lingon from Peter Borg makes them much more accessible. It’s also widely abused by malware, which often installs its own LaunchAgents and LaunchDaemons to ensure its persistence across reboots, and to perform services which it requires.

Apple defines a LaunchDaemon as a general background service, without any form of GUI. Specifically, LaunchDaemons are not allowed to connect to the macOS window server. LaunchAgents do have access to the GUI, and to other system features such as locating the current user’s Home folder, but generally have much more limited interfaces than do regular apps.

Uninstalling a LaunchAgent or LaunchDaemon is simply a matter of trashing its Property List from the appropriate folder – a task sometimes necessary when you have uninstalled an app which doesn’t clean up properly after itself. If software does need to install one or more Property Lists in any of these folders, then it should also provide an effective uninstaller to remove them when required.

Apple’s documentation on launchd is quite old now, but is still a valuable reference, as is TN2083.

Login Items

These are controlled quite differently, through LaunchServices rather than launchd, which runs later following startup. You can set any app, service, or other executable code to run at startup by adding the item to the list of Login Items in the Users & Groups pane in System Preferences.

bailiff05

Once added, LaunchServices puts them into its list of apps to launch at startup, which is also kept in a Property List file. In Sierra and earlier, that is located in ~/Library/Preferences/com.apple.loginitems.plist, but High Sierra has moved that, changed its extension, and the file structure, to ~/Library/Application Support/com.apple.backgroundtaskmanagementagent/backgrounditems.btm

The older Property List isn’t intended to be maintained directly by the user. For each Login Item, it gives an ‘alias’ which isn’t a normal macOS Bookmark, and some CustomItemProperties, which are also Base-64 encoded opaque data. The new format in High Sierra is even more opaque: although a Property List, it is now a keyed archive containing objects which are referenced by UUID, and unsuitable for manual editing.

There’s an easy way to add apps which are already in the Dock to the Login Items list: click and hold on their icon in the Dock until its menu pops up. In that, select Options, then the Open at Login command.

You can add and remove Login Items using a scripting language; for example, in AppleScript
tell application "System Events" to make login item at end with properties {path:"/Applications/MyApp.app", hidden:false}
adds MyApp.app as a Login Item,
tell application "System Events" to get the name of every login item
lists all Login Items, and
tell application "System Events" to delete login item "name"
removes the named Login Item from the current list.

Login Items are better suited to apps of any size which have significant user interfaces, and anything which a user wants to control easily. Many apps, such as menubar or ‘Status Bar’ apps, offer the user the option of installing them as a Login Item. Unfortunately, particularly when this is done for an app provided through the App Store, this turns out to be a complex development task which requires a helper app.

If you’re interested in understanding this in detail, this item on Stack Overflow considers some of the problems, this tutorial proposes one solution, and this is another tutorial account. Tomorrow I’ll be showing a much simpler way which works with apps which are not sandboxed (thus not intended for the App Store).

Sorting out LaunchServices problems is not easy. If you’re seeing weird things going on with your Login Items list, the best solution is usually to start from scratch by trashing the current file (located according to whether you’re running Sierra and earlier, or High Sierra), restarting, and setting up your Login Items again. Note that in some versions of macOS, until there is at least one Login Item, the settings file may not exist.

Just leave it running

The third and last way of opening an app when you next start up is simply to leave the app running when you shut down or restart. It does, of course, rely on you remembering to check that the app is running beforehand.

Share this:

  • Twitter
  • Facebook
  • Reddit
  • Pinterest
  • Email
  • Print

Like this:

Like Loading...

Related

Posted in Macs, Technology and tagged AppleScript, LaunchAgents, launchd, LaunchDaemons, LaunchServices, Login Item, property list, startup, Users & Groups. Bookmark the permalink.

5Comments

Add yours
  1. 1
    Joss on October 12, 2018 at 3:47 pm

    Is there a way to delay loading of a global LaunchDaemons until the user has logged in and the GUI has loaded? I’m currently struggling with this – https://github.com/JayBrown/Application-Launch-Monitor-ALM- – and it works fine if you manually load (or reload) it, while logged in, but during boot launchd starts the daemon and the NSWorkspace listener pretty early, too early, I believe, and it doesn’t work unless I unload & reload it.

    LikeLiked by 1 person

    • 2
      hoakley on October 12, 2018 at 3:53 pm

      I don’t know of any way of doing this directly. You could launch a background process which polls until a user is logged in and then runs it, but that would be elaborate.
      Could you not install it in ~/Library/LaunchAgents? That would of course be user-specific, but is guaranteed not to load until the user has logged in.
      Howard.

      LikeLike

      • 3
        Joss on October 12, 2018 at 4:12 pm

        User agent is not possible because it’s a security tool that needs to run as root:wheel. So your first idea is probably best: add a second helper daemon (root as well), which runs `who | grep “console”` in a loop until it prints a result, and only then will it load the main daemon.

        LikeLiked by 1 person

      • 4
        Joss on October 12, 2018 at 4:55 pm

        Works perfectly. Thanks for pointing me in the right direction! 🙂

        LikeLiked by 1 person

        • 5
          hoakley on October 12, 2018 at 5:39 pm

          Well done: that was quick!
          Howard.

          LikeLike

·Comments are closed.

Quick Links

  • Downloads
  • Mac Troubleshooting Summary
  • M1 & M2 Macs
  • Mac problem-solving
  • Painting topics
  • Painting
  • Long Reads

Search

Monthly archives

  • January 2023 (74)
  • December 2022 (74)
  • November 2022 (72)
  • October 2022 (76)
  • September 2022 (72)
  • August 2022 (75)
  • July 2022 (76)
  • June 2022 (73)
  • May 2022 (76)
  • April 2022 (71)
  • March 2022 (77)
  • February 2022 (68)
  • January 2022 (77)
  • December 2021 (75)
  • November 2021 (72)
  • October 2021 (75)
  • September 2021 (76)
  • August 2021 (75)
  • July 2021 (75)
  • June 2021 (71)
  • May 2021 (80)
  • April 2021 (79)
  • March 2021 (77)
  • February 2021 (75)
  • January 2021 (75)
  • December 2020 (77)
  • November 2020 (84)
  • October 2020 (81)
  • September 2020 (79)
  • August 2020 (103)
  • July 2020 (81)
  • June 2020 (78)
  • May 2020 (78)
  • April 2020 (81)
  • March 2020 (86)
  • February 2020 (77)
  • January 2020 (86)
  • December 2019 (82)
  • November 2019 (74)
  • October 2019 (89)
  • September 2019 (80)
  • August 2019 (91)
  • July 2019 (95)
  • June 2019 (88)
  • May 2019 (91)
  • April 2019 (79)
  • March 2019 (78)
  • February 2019 (71)
  • January 2019 (69)
  • December 2018 (79)
  • November 2018 (71)
  • October 2018 (78)
  • September 2018 (76)
  • August 2018 (78)
  • July 2018 (76)
  • June 2018 (77)
  • May 2018 (71)
  • April 2018 (67)
  • March 2018 (73)
  • February 2018 (67)
  • January 2018 (83)
  • December 2017 (94)
  • November 2017 (73)
  • October 2017 (86)
  • September 2017 (92)
  • August 2017 (69)
  • July 2017 (81)
  • June 2017 (76)
  • May 2017 (90)
  • April 2017 (76)
  • March 2017 (79)
  • February 2017 (65)
  • January 2017 (76)
  • December 2016 (75)
  • November 2016 (68)
  • October 2016 (76)
  • September 2016 (78)
  • August 2016 (70)
  • July 2016 (74)
  • June 2016 (66)
  • May 2016 (71)
  • April 2016 (67)
  • March 2016 (71)
  • February 2016 (68)
  • January 2016 (90)
  • December 2015 (96)
  • November 2015 (103)
  • October 2015 (119)
  • September 2015 (115)
  • August 2015 (117)
  • July 2015 (117)
  • June 2015 (105)
  • May 2015 (111)
  • April 2015 (119)
  • March 2015 (69)
  • February 2015 (54)
  • January 2015 (39)

Tags

APFS Apple AppleScript Apple silicon backup Big Sur Blake bug Catalina Consolation Console diagnosis Disk Utility Doré El Capitan extended attributes Finder firmware Gatekeeper Gérôme HFS+ High Sierra history of painting iCloud Impressionism iOS landscape LockRattler log logs M1 Mac Mac history macOS macOS 10.12 macOS 10.13 macOS 10.14 macOS 10.15 macOS 11 macOS 12 macOS 13 malware Mojave Monet Monterey Moreau MRT myth narrative OS X Ovid painting Pissarro Poussin privacy realism Renoir riddle Rubens Sargent scripting security Sierra SilentKnight SSD Swift symbolism Time Machine Turner update upgrade Ventura xattr Xcode XProtect

Statistics

  • 13,758,680 hits
Blog at WordPress.com.
Footer navigation
  • About & Contact
  • Macs
  • Painting
  • Language
  • Tech
  • Life
  • General
  • Downloads
  • Mac problem-solving
  • Extended attributes (xattrs)
  • Painting topics
  • Hieronymus Bosch
  • English language
  • LockRattler: 10.12 Sierra
  • LockRattler: 10.13 High Sierra
  • LockRattler: 10.11 El Capitan
  • Updates: El Capitan
  • Updates: Sierra, High Sierra, Mojave, Catalina, Big Sur
  • LockRattler: 10.14 Mojave
  • SilentKnight, silnite, LockRattler, SystHist & Scrub
  • DelightEd & Podofyllin
  • xattred, Metamer, Sandstrip & xattr tools
  • 32-bitCheck & ArchiChect
  • T2M2, Ulbow, Consolation and log utilities
  • Cirrus & Bailiff
  • Taccy, Signet, Precize, Alifix, UTIutility, Sparsity, alisma
  • Revisionist & DeepTools
  • Text Utilities: Nalaprop, Dystextia and others
  • PDF
  • Keychains & Permissions
  • LockRattler: 10.15 Catalina
  • Updates
  • Spundle, Cormorant, Stibium, Dintch, Fintch and cintch
  • Long Reads
  • Mac Troubleshooting Summary
  • LockRattler: 11.0 Big Sur
  • M1 & M2 Macs
  • Mints: a multifunction utility
  • LockRattler: 12.x Monterey
  • VisualLookUpTest
  • Virtualisation on Apple silicon
  • LockRattler: 13.x Ventura
Secondary navigation
  • Search

Post navigation

Plutarch’s Lives in Paint: 1b Romulus, to the founding of Rome
Plutarch’s Lives in Paint: 1b Romulus, from the rape of the Sabines

Begin typing your search above and press return to search. Press Esc to cancel.

  • Follow Following
    • The Eclectic Light Company
    • Join 3,127 other followers
    • Already have a WordPress.com account? Log in now.
    • The Eclectic Light Company
    • Customize
    • Follow Following
    • Sign up
    • Log in
    • Copy shortlink
    • Report this content
    • View post in Reader
    • Manage subscriptions
    • Collapse this bar
 

Loading Comments...
 

    %d bloggers like this: