# New appimaged: Optional daemon that registers AppImages with the system

**URL:** <https://discourse.appimage.org/t/new-appimaged-optional-daemon-that-registers-appimages-with-the-system/87>\
**Category:** Developers\
**Created:** [October 23, 2016, 6:01pm UTC](https://discourse.appimage.org/t/new-appimaged-optional-daemon-that-registers-appimages-with-the-system/87 "2016-10-23T18:01:36Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![probono](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/probono/32/81_2.png) [@probono](https://discourse.appimage.org/u/probono)\
**Post date:** [October 23, 2016, 6:01pm UTC](https://discourse.appimage.org/t/new-appimaged-optional-daemon-that-registers-appimages-with-the-system/87/1 "2016-10-23T18:01:36Z")

</div>

`appimaged` is an optional daemon that watches locations like `~/bin` and `~/Downloads` for AppImages and if it detects some, registers them with the system, so that they show up in the menu, have their icons show up, MIME types associated, etc. It also unregisters AppImages again from the system if they are deleted. If [firejail](https://github.com/netblue30/firejail) is installed, it runs the AppImages with it.

A precompiled version can be found in the last successful Travis CI build, you can get from [https://github.com/AppImage/AppImageKit/releases](https://github.com/AppImage/AppImageKit/releases).

Usage in a nutshell:

```auto
./appimaged

```

It will register the AppImages in with your system from the following places:

- $HOME/Downloads
- $HOME/bin
- /Applications
- /isodevice/Applications
- /opt
- /usr/local/bin

Run `appimaged -v` for increased verbosity.

**NOTE:** It may be necessary to restart (or `xkill`) dash, nautilus, to recognize new directories that didn’t exist prior to the first run of `appimaged`. Alternatively, it should be sufficient to log out of the session and log in again after having run appimaged once.

If you have `AppImageUpdate` on your `$PATH`, then it can also do this neat trick:

![screenshot from 2016-10-15 16-37-05](https://canada1.discourse-cdn.com/flex027/uploads/appimage/original/1X/82361002269bc111aa436fb0255db819d589c0ed.jpg)

Here is an easy way to get the latest AppImageUpdate onto your `$PATH`:

```auto
APP=AppImageUpdate
nodeFileName=$(wget -q "https://bintray.com/package/files/probono/AppImages/$APP?order=desc&sort=fileLastModified&basePath=&tab=files" -O - | grep -e '-x86_64.AppImage">' | cut -d '"' -f 6 | head -n 1)
wget -c "https://bintray.com/$nodeFileName" -O "$APP"
chmod a+x "$APP"
sudo mv "$APP" /usr/local/bin/

```

**NOTE: This works only with the new, squashfs-based type 2 AppImages so far.**

---

<div class="post-metadata">

**Author:** ![kodaxx](https://avatars.discourse-cdn.com/v4/letter/k/8e8cbc/32.png) [@kodaxx](https://discourse.appimage.org/u/kodaxx)\
**Post date:** [October 29, 2016, 1:23am UTC](https://discourse.appimage.org/t/new-appimaged-optional-daemon-that-registers-appimages-with-the-system/87/2 "2016-10-29T01:23:51Z")

</div>

Does this daemon automatically make AppImages executable? No more right-clicking and setting options?

Also, as for the update feature: does the upstream developer have the ability to set the location of future binaries? (So they can be kept up to date on our own servers?)

---

<div class="post-metadata">

**Author:** ![probono](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/probono/32/81_2.png) [@probono](https://discourse.appimage.org/u/probono)\
**Post date:** [October 29, 2016, 8:33am UTC](https://discourse.appimage.org/t/new-appimaged-optional-daemon-that-registers-appimages-with-the-system/87/3 "2016-10-29T08:33:28Z")

</div>

> Does this daemon automatically make AppImages executable? No more right-clicking and setting options?

Correct, no more right-clicking and setting options. The AppImage will run in a Firejail sandbox for which it is not necessary to mark it as executable. You can test this already now with type 2 AppImages. Possibly unsigned AppImages will run under tighter confinement (e.g., no write access, no network access) than signed AppImages, but this is not decided yet and I’d appreciate thoughts on this.

> Also, as for the update feature: does the upstream developer have the  
> ability to set the location of future binaries? (So they can be kept up  
> to date on our own servers?)

I don’t understand this idea. If you use AppImageUpdate, then the new updated version will end up in the same directory as the original one. You can decide, as an upstream developer, where to store the files for the update on your download server. I use Bintray, but you might use any HTTP server that can handle HTTP Range Requests (normally used for video streaming).

---

<div class="post-metadata">

**Author:** ![kodaxx](https://avatars.discourse-cdn.com/v4/letter/k/8e8cbc/32.png) [@kodaxx](https://discourse.appimage.org/u/kodaxx)\
**Post date:** [October 29, 2016, 4:32pm UTC](https://discourse.appimage.org/t/new-appimaged-optional-daemon-that-registers-appimages-with-the-system/87/4 "2016-10-29T16:32:13Z")

</div>

> [@probono](#):
>
> You can decide, as an upstream developer, where to store the files for the update on your download server. I use Bintray, but you might use any HTTP server that can handle HTTP Range Requests (normally used for video streaming).

This answers my question regarding that. I have a few ideas to begin an era where this is a widely accepted format. I will report back after I’ve worked on them a bit in concept.

---

<div class="post-metadata">

**Author:** ![probono](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/probono/32/81_2.png) [@probono](https://discourse.appimage.org/u/probono)\
**Post date:** [October 30, 2016, 7:10pm UTC](https://discourse.appimage.org/t/new-appimaged-optional-daemon-that-registers-appimages-with-the-system/87/5 "2016-10-30T19:10:59Z")

</div>

> [@kodaxx](#):
>
> I have a few ideas to begin an era where this is a widely accepted format. I will report back after I’ve worked on them a bit in concept.

Very cool! Looking forward to it 🙂

---

<div class="post-metadata">

**Author:** ![probono](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/probono/32/81_2.png) [@probono](https://discourse.appimage.org/u/probono)\
**Post date:** [November 5, 2016, 3:03pm UTC](https://discourse.appimage.org/t/new-appimaged-optional-daemon-that-registers-appimages-with-the-system/87/6 "2016-11-05T15:03:27Z")

</div>

This has now landed in [https://github.com/probonopd/AppImageKit](https://github.com/probonopd/AppImageKit), yay!

---

<div class="post-metadata">

**Author:** ![Royi](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/royi/32/150_2.png) [@Royi](https://discourse.appimage.org/u/Royi)\
**Post date:** [May 28, 2018, 5:59pm UTC](https://discourse.appimage.org/t/new-appimaged-optional-daemon-that-registers-appimages-with-the-system/87/7 "2018-05-28T17:59:22Z")

</div>

Is there a way to run this service on demand?  
Namely instead of background service I run it, it scans, updates what needs to be updated and close itself.

---

<div class="post-metadata">

**Author:** ![probono](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/probono/32/81_2.png) [@probono](https://discourse.appimage.org/u/probono)\
**Post date:** [May 30, 2018, 5:48am UTC](https://discourse.appimage.org/t/new-appimaged-optional-daemon-that-registers-appimages-with-the-system/87/8 "2018-05-30T05:48:05Z")

</div>

`appimaged` checks the filesystem for changes, and acts whenever it detects a change. What would we gain by making it quit itself? In this case, some other process (`systemd`?) would need to check for the filesystem changes, and invoke our code to do the AppImage system integration when being called. Instead of running a background service, we would have an executable that would get called by some other background service.

Actually, interesting thought. I have opened [https://github.com/AppImage/appimaged/issues/8](https://github.com/AppImage/appimaged/issues/8) for it. More investigation needed.

---

<div class="post-metadata">

**Author:** ![Royi](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/royi/32/150_2.png) [@Royi](https://discourse.appimage.org/u/Royi)\
**Post date:** [May 30, 2018, 6:01am UTC](https://discourse.appimage.org/t/new-appimaged-optional-daemon-that-registers-appimages-with-the-system/87/9 "2018-05-30T06:01:26Z")

</div>

The whole idea of using AppImage style applications is keeping the system as on its first day to run.  
I don’t want more processes or anything in the background which changes the system.

This is why I like the PortableApps concept.

---

<div class="post-metadata">

**Author:** ![probono](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/probono/32/81_2.png) [@probono](https://discourse.appimage.org/u/probono)\
**Post date:** [May 30, 2018, 6:11am UTC](https://discourse.appimage.org/t/new-appimaged-optional-daemon-that-registers-appimages-with-the-system/87/10 "2018-05-30T06:11:45Z")

</div>

> [@Royi](#):
>
> The whole idea of using AppImage style applications is keeping the system as on its first day to run.  
> I don’t want more processes or anything in the background which changes the system.

I think you are confusing a couple of things:

- **Running a per-user background process vs. “system privileges”.** When you run a per-user daemon (background process) it has no more privileges than an application running in the “system tray”
- **Portable applications vs. “leaving no traces”.** The fact that an application is “porable” (i.e., can run without the need for installation, can run from different locations in the file system) does not mean that the application can “leave no traces”. For this you need either _sandboxing_ (which can limit functionality), or a system that “forgets” its state on each reboot. I, too, like the concept of “keeping the system as on its first day”, but I am using Live ISOs booted by SystemImageKit for this purpose - every boot gives me a clean system

---

<div class="post-metadata">

**Author:** ![Royi](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/royi/32/150_2.png) [@Royi](https://discourse.appimage.org/u/Royi)\
**Post date:** [May 30, 2018, 6:30am UTC](https://discourse.appimage.org/t/new-appimaged-optional-daemon-that-registers-appimages-with-the-system/87/11 "2018-05-30T06:30:37Z")

</div>

Well, we can always inspire for the closest we can get.  
For me Portable which leaves no trail means:

1. Requires no special privileges - Built In into AppImage.
2. Writes its configuration data into the folder the program resides in (Built In into AppImage under the assumption the application uses `$HOME` system environment variable to set the location of writing configuration and application data).

Deamon for me is like background processes in Windows.  
I don’t like that.  
I prefer well shown program in the System Tray.  
Only viruses and system services should hide themselves (From different reasons) from the user.  
Pay attention that I don’t mean it can’t be a Daemon, I mean it should be visible to the user in the places he looks for programs - Taskbar / System Tray. Not in the processes menu to stop it.

---

<div class="post-metadata">

**Author:** ![probono](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/probono/32/81_2.png) [@probono](https://discourse.appimage.org/u/probono)\
**Post date:** [May 30, 2018, 6:45am UTC](https://discourse.appimage.org/t/new-appimaged-optional-daemon-that-registers-appimages-with-the-system/87/12 "2018-05-30T06:45:06Z")

</div>

> [@Royi](#):
>
> Deamon for me is like background processes in Windows.  
> I don’t like that.  
> I prefer well shown program in the System Tray.  
> Only viruses and system services should hide themselves (From different reasons) from the user.  
> Pay attention that I don’t mean it can’t be a Daemon, I mean it should be visible to the user in the places he looks for programs - Taskbar / System Tray. Not in the processes menu to stop it.

Just for fun, start a “new” Linux installation, open a terminal, type `ps ax` and be amazed at how many “background processes” are running… it will be an eye-opener.

> [@Royi](#):
>
> Only viruses and system services should hide themselves (From different reasons) from the user.

Isn’t `appimaged` something like a “system service” (only that it doesn’t come with the system in most cases)?

---

<div class="post-metadata">

**Author:** ![Royi](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/royi/32/150_2.png) [@Royi](https://discourse.appimage.org/u/Royi)\
**Post date:** [May 30, 2018, 6:56am UTC](https://discourse.appimage.org/t/new-appimaged-optional-daemon-that-registers-appimages-with-the-system/87/13 "2018-05-30T06:56:52Z")

</div>

> [@probono](#):
>
> > [@Royi](#):
> >
> > Deamon for me is like background processes in Windows.  
> > I don’t like that.  
> > I prefer well shown program in the System Tray.  
> > Only viruses and system services should hide themselves (From different reasons) from the user.  
> > Pay attention that I don’t mean it can’t be a Daemon, I mean it should be visible to the user in the places he looks for programs - Taskbar / System Tray. Not in the processes menu to stop it.
> 
> Just for fun, start a “new” Linux installation, open a terminal, type `ps ax` and be amazed at how many “background processes” are running… it will be an eye-opener.

Well, those are what I agreed to when I chose the distribution.  
What I don’t want is to add another one.  
Especially if it is something I have hard time interacting with since it doesn’t have System Tray icon.

> [@probono](#):
>
> > [@Royi](#):
> >
> > Only viruses and system services should hide themselves (From different reasons) from the user.
> 
> Isn’t `appimaged` something like a “system service” (only that it doesn’t come with the system in most cases)?

That’s the point.  
I don’t want it to act as a System Service.  
I want it to act as a background application which the user can interact with and configure using System Tray icon.