Crest [fork]

Your rating: None Average: 4.9 (16 votes)

Crest is a 'top/ps' like application. Forked from

As of version 1.8.1, Crest will no longer use the external 'ps' command, but gather this process info itself.


Filtered processes

The default view is apps only. But what defines an app? Crest simple used to filter names like "harbour-", "jolla-" or processes with dots. Lighthouse also has an app view, but filters app names found in /usr/share/applications.
Crest now also matches the desktop files in /usr/share/applications and ~/.local/share/applications, but also includes sailfish-qml apps/processes (which seems more accurate than the old method Crest used).

In "Show all processes" mode Crest does not show the processes that appear between brackets; processes that do not have an associated command line (mostly kernel threads and some system services). They do not display memory usage, but can use CPU power. Not showing these processes shortens the process list a lot.

If "Incl. no cmdline [top 60]" is actived, those processes are also shown. To shorten the list and prevent higher cpu load, the list is limited to the top 60 entries.


Crest shows the resident set size (RSS). It is less accurate than proportional set size (PSS), as PSS handles used shared memory use better. The downside of PSS is that you need to have privileged access to collect that info.

Colors used for procesname

nemo/defaultuser = Theme.secondaryColor
root = Theme.primaryColor
others (android, media, system etc.) = Theme.secondaryHighlightColor

License to kill

Running as nemo/defaultuser, you can only kill your own processes.
But when /usr/bin/sudo is located and does not ask for a password, it will use that when needed (assuming sudo is configured correctly, else it fails of course), so root and android processes can be terminated as well. Needless to say killing random processes can make your system unstable or even crash.


Sources on github

Application versions: 
File harbour-crest-1.8-2.aarch64.rpm123.57 KB07/12/2021 - 20:09
File harbour-crest-1.8-2.i486.rpm135.22 KB07/12/2021 - 20:09
File harbour-crest-1.8-2.armv7hl.rpm117.43 KB07/12/2021 - 20:09
File harbour-crest-1.8-3.aarch64.rpm123.5 KB07/12/2021 - 23:21
File harbour-crest-1.8-3.i486.rpm135.38 KB07/12/2021 - 23:21
File harbour-crest-1.8-3.armv7hl.rpm117.42 KB07/12/2021 - 23:21
File harbour-crest-1.9-1.aarch64.rpm123.95 KB12/12/2021 - 01:11
File harbour-crest-1.9-1.i486.rpm135.3 KB12/12/2021 - 01:11
File harbour-crest-1.9-1.armv7hl.rpm117.14 KB12/12/2021 - 01:11
File harbour-crest-1.9-2.aarch64.rpm123.85 KB19/12/2021 - 22:43
File harbour-crest-1.9-2.i486.rpm135.24 KB19/12/2021 - 22:43
File harbour-crest-1.9-2.armv7hl.rpm117.15 KB19/12/2021 - 22:43
File harbour-crest-1.9-3.aarch64.rpm124.04 KB09/03/2022 - 20:57
File harbour-crest-1.9-3.i486.rpm135.1 KB09/03/2022 - 20:57
File harbour-crest-1.9-3.armv7hl.rpm117.25 KB09/03/2022 - 20:57
File harbour-crest-1.10-1.aarch64.rpm108.84 KB04/03/2023 - 15:14
File harbour-crest-1.10-1.i486.rpm117.58 KB04/03/2023 - 15:14
File harbour-crest-1.10-1.armv7hl.rpm101.86 KB04/03/2023 - 15:14
File harbour-crest-1.11-2.i486.rpm129.59 KB19/04/2023 - 16:31
File harbour-crest-1.11-2.aarch64.rpm119.96 KB19/04/2023 - 16:35
File harbour-crest-1.11-2.armv7hl.rpm111.88 KB19/04/2023 - 16:35
File harbour-crest-1.12-1.aarch64.rpm119.96 KB03/05/2023 - 11:28
File harbour-crest-1.12-1.i486.rpm129.6 KB03/05/2023 - 11:28
File harbour-crest-1.12-1.armv7hl.rpm111.89 KB03/05/2023 - 11:28
  • 1.12.1 Hide search in pulley menu when already activated
  • 1.11.2 Fix swap used value on coverpage
  • 1.11.1 Some coverpage redesign
  • 1.10.1 SFOS 4.5 fix: show Android apps in apps view once again
  • 1.9.3 Add leading zero in decimal RSS MB size
  • 1.9.2 Should fix incidental premature closing after selecting action from contextmenu.
  • 1.9.1 On process details page
    • also display username if registered
    • again fill CPU time with calculated value instead of "00:00:00"
    • extra info regarding Group owner ID
  • 1.8-3 fixed screen refresh regression introduced in 1.8.1
  • 1.8-2 fix: CPU% needed to be multiplied by 10.
  • 1.8-1 Removed dependency of procs-ng by gathering process info by itself
  • 1.7-4 Tried to disable require procps-ng for SFOS < 4, so it should also update on older versions
  • 1.7-3 kill child processes after 2 seconds as a workaround for possible SFOS 4.2 hang issues
  • 1.7-2
    • replace busybox-symlinks-procps with procps-ng during installation
    • added aarch64 build
  • 1.7-1 Cover improvements:
    • do not update when inactive
    • added uptime in day/hours/minutes/seconds format
    • Some layout changes
  • 1.6-1 Added viewmode including no command processes
  • 1.5-1
    • Added remorse timer for process killing
    • Additional process detail page
  • 1.4-1
    • Added process search function
    • Do not show program path in portrait mode
    • Use colorscheme for various users
    • Sudo support
    • Dropped reversed sort ordering
    • Show pid in kill dialog
    • Change app detection


simosagi's picture

On my XA2 with SFOS 4.3 I'm not able to install the latest version 1.10.1.
version 1.9.3 works fine.

I tried in command line (pkcon install-local) and the message that I got is:
Fatal error: Subprocess failed. Error: RPM failed: error: unpacking of archive failed: cpio: Bad magic

Odd because I downloaded the package on my workstation and extracing the files from the rpm was successful.
Does it need a newer version of the rpm tools/libraries?

ade's picture
simosagi's picture

Ok thanks! That was my best guess on what was happening.
For next releases, could you set the package as SFOS 4.4+- only (so in Openrepos it won't be seen as update available for SFOS 4.3 and older) ?

ade's picture

But why not upgrade? I expect more and more package problems for you as developers start upgrading their toolchain. Not just the RPM format, but also linked library versions that get updated.

If you can't update, pinning packages is also an option I guess.

slava's picture

Your question can be turned around - why to upgrade the toolchain?

ade's picture

Good point, lets ask Jolla to stop updating components so we never need another toolchain.

slava's picture

Well, somehow I manage to build all my apps against SDK. Although I have to admit that a few (fairly trivial) tweaks have to be applied to use e.g. the new sharing API. And yes, respect for user's right to not update their devices does require some efforts from the developer, which not every developer is prepared to spare (sad but understandable).

ade's picture

Since you work for Jolla and you talk about "respect for user's right to not update" (which sounds about the same as "respect for the devolopers right to update" btw): why isn't a new rpm version build for older sailfish OS versions that supports zstd compression? That would show some real commitment to support the "users right not to update" from Jollas site.

slava's picture

Of course you can do whatever, it's your app and your users.

BTW I no longer work for Jolla and respecting user's right to not upgrade isn't something that was required from my by Jolla, it's just something that I think is a good and right thing to do. And yes, compatibility with multiple releases of Sailfish OS is a bit of a challenge, it does require some efforts and Jolla is periodically making it harder by removing and changing APIs and libraries without obvious reasons.

Sometimes developers upgrade their development environment just out of curiosity, without realizing that they are making their builds incompatible with earlier releases of Sailfish OS, I thought it could be the case. But if it's a conscious decision then so be it, it's your choice, I'm not here to tell you what to do.

lpr's picture

zstd compression might have benefits while complete system upgrade (smartphone needs less power) but for single rpm install like here (openrepos), it makes no sense at all (you'll block older SFOS versions with zstd while new 4.5 and for sure even next versions support older-toolchain xz-rpm )

library versions can be updated on older SFOS devices and toolchains ( or have a lot of examples)

btw: rpm-update for older SFOS versions would be great nonetheless

sdiconov's picture

I wholeheartedly support the request for backporting rpm. The new zstd compressed packages, including Crest became digital trash. 

I have a SFOS-4.0 based INOI tablet (There is no Android for this exact model and no SFOS upgrades beyond 4.0). I would still like to upgrade libs and apps without touching the kernel. The new rpm compression effectively breaks my device, while the new SFOS itself became buggy and incompatible with existing hardware. ...And no new SFOS-native tablets on the horizon.

ade's picture

Okay, this is the first example I hear from someone who can actually not upgrade due to technical reasons.
I'm trying to get an "official" Jolla response ( on how to deal with this, but for now I will replace the latest RPM's build without the new compression method. You will probably need to to a refesh for that to show up.

DrYak's picture

Since upgrading to SFOS, the android applications don't show up in the "Show only apps" view, I only see the SailfishOS native apps.

If I switch the view to "Show all processes", the android applications show up normally, so it's really some problem with the current filters used by Crest, not the process gathering itself (I guess some desktop files have changed since to the upgrade of AppSupport to android 11).

ade's picture

Confirmed. Will try to fix that this weekend.

ade's picture

Should be fixed in 1.10.1

DrYak's picture

it works !:

Thank you fir the fast response !

jolla4ever's picture

Your programme gives me tremendous insight into processes this OS uses, including the Android App Support. Many thanks!

SalfishOS, Sony Xperia 10 iii

olf's picture

Hi @ade,

triggered by the release comment "Tried to disable require procps-ng for SFOS < 4, so it should also update on older versions" for v1.7-4, I wondered why I still have v1.4-1 installed on SailfishOS 3.2.1.
Thus I started by checking the dependencies defined in the spec file (resulting in an unrelated mini-MR), but ultimately it simply seems to be compiled for newer SailfisOS releases.  A pkcon update harbour-crest results in Fatal error: nothing provides needed by harbour-crest-1.8-3.armv7hl

Thus, can you please set the SDK to compile for an older SFOS release (possibly the oldest available).

BTW, the issues at GitHub are switched off, you might switch them on (e.g., I would have preferred to report there).  But if that was a deliberate decision, never mind my personal preferences.


carmenfdezb's picture

Hi @ade! Crest last version doesn't work fluid for me on sfos 4.3. If I open it from Terminal:
[D] unknown:0 - Using Wayland-EGL
library "" not found
library "" not found
sudo: a password is required

It seems that sudo password is required and maybe this is the reason that it doesn't work fine.
Do you know how can I solve it? I use 'sudo' and I don't want to uninstall it.

ade's picture

I noticed the same slowdown on my Xperia XA2 Plus since SFOS 4.3. Some 'ps' info field retrievements seems to be the problem. Other devices I have do not slowdown, which is very strange.

Because of all the issues with 'ps', I am currently rewriting this part so it no longer needs 'ps'. Stay tuned for a few more days.

carmenfdezb's picture

Thanks for the update! It works perfectly :)

carmenfdezb's picture

Great! Thank you!

JacekJagosz's picture

Thank you so much for making it working agan, this is such a nice task manager!

JacekJagosz's picture

@ade Crest doesn't work for me either. I think it could be because I removed busybox-symlinks-bash and installed gnu-bash so patchmanager could work.
Could that be the source of the issue?

ade's picture

In case the 'ps' command does not finish it should now be terminated after 2 seconds to prevent this process causing a lock.

Still don't know what causes 'ps' to stall in some rare cases in SFOS 4.2, can't reproduce it from the commandline. Only thing I can think of is some kind of /proc/<pid> corruption.

If starting still does not work please reset the phone first to get rid of some previous 'ps' process or Crest instance. Or kill those manually. You can't use Crest for that at that moment ;-)

ade's picture

No, I don't think there is a relationship. It seems related, as I also seem to get no response every now and then when starting the app.
What I noticed is that the 'ps' command does not finish, so Crest can't continue. I have not found the exact cause of this, but I do have Crest running fine atm, with a small, non related change it seems.
I will see if it keep running ok and might upload that version.

NGC_Ollie's picture

On Crest is not starting anymore. No messages on commandline

ade's picture

It's still working here on 4.2.
Could it be that there is still some instance running in the background? Could you try a reboot first and if it does not help a reinstall of Crest?
If the problem still persists after that we will have to dig deeper.

pasik2's picture

After installing Android app support to my Xperia 10 II, Crest won't open anymore. Terminal output says:
[D] unknown 0 -Using Wayland-EGL
Library "" not found
Library "" not found

ade's picture

Can't say much about this as I do not have a 64bit SFOS version. Are those "not found" messages maybe just warnings that also pop up with other apps? And I do not see a direct link between Crest and Aliendalvik library files. There is no clear coredump/crash message? Is Crest the only app with issues after installing Android Support? Can other AArch64 users confirm this issue?