Crest is a 'top/ps' like application. Forked from https://openrepos.net/content/miska/crest
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.
nemo/defaultuser = Theme.secondaryColor
root = Theme.primaryColor
others (android, media, system etc.) = Theme.secondaryHighlightColor
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
Comments
simosagi
Tue, 2023/02/21 - 15:39
Permalink
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
Tue, 2023/02/21 - 16:05
Permalink
See my remark on the Jolla forum: https://forum.sailfishos.org/t/q-4-5-will-switch-rpm-compression-what-do...
simosagi
Tue, 2023/02/21 - 18:03
Permalink
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
Tue, 2023/02/21 - 18:35
Permalink
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
Thu, 2023/02/23 - 01:36
Permalink
Your question can be turned around - why to upgrade the toolchain?
ade
Thu, 2023/02/23 - 01:46
Permalink
Good point, lets ask Jolla to stop updating components so we never need another toolchain.
slava
Fri, 2023/02/24 - 03:51
Permalink
Well, somehow I manage to build all my apps against 2.0.0.10 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
Fri, 2023/02/24 - 10:40
Permalink
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
Sat, 2023/02/25 - 17:55
Permalink
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
Sat, 2023/02/25 - 16:45
Permalink
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 ( https://openrepos.net/user/7598/programs or https://openrepos.net/user/8039/programs have a lot of examples)
btw: rpm-update for older SFOS versions would be great nonetheless
sdiconov
Fri, 2023/03/03 - 12:08
Permalink
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
Sat, 2023/03/04 - 15:17
Permalink
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 (https://forum.sailfishos.org/t/whats-jollas-view-on-how-to-deal-with-the...) 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
Fri, 2023/02/10 - 04:53
Permalink
Since upgrading to SFOS 4.5.0.16, 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
Fri, 2023/02/10 - 10:21
Permalink
Confirmed. Will try to fix that this weekend.
ade
Fri, 2023/02/10 - 21:20
Permalink
Should be fixed in 1.10.1
DrYak
Sun, 2023/02/12 - 02:32
Permalink
it works !:
Thank you fir the fast response !
jolla4ever
Thu, 2022/10/20 - 01:02
Permalink
Your programme gives me tremendous insight into processes this OS uses, including the Android App Support. Many thanks!
SalfishOS 4.4.0.72, Sony Xperia 10 iii
olf
Sun, 2021/12/12 - 02:21
Permalink
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 lbstdc++.so.6(GLIBCXX_3.4.21) 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.
Cheers!
carmenfdezb
Mon, 2021/12/06 - 12:41
Permalink
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 "libGLESv2_adreno.so" not found
library "eglSubDriverAndroid.so" 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
Mon, 2021/12/06 - 12:48
Permalink
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
Tue, 2021/12/07 - 00:08
Permalink
Thanks for the update! It works perfectly :)
carmenfdezb
Mon, 2021/12/06 - 13:02
Permalink
Great! Thank you!
JacekJagosz
Sat, 2021/10/09 - 22:46
Permalink
Thank you so much for making it working agan, this is such a nice task manager!
JacekJagosz
Mon, 2021/10/04 - 13:26
Permalink
@ade Crest doesn't work for me either. I think it could be because I removed
busybox-symlinks-bash
and installedgnu-bash
so patchmanager could work.Could that be the source of the issue?
ade
Sat, 2021/10/09 - 12:13
Permalink
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
Mon, 2021/10/04 - 14:00
Permalink
No, I don't think there is a relationship. It seems 4.2.0.21 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
Mon, 2021/09/20 - 19:47
Permalink
On 4.2.0.21 Crest is not starting anymore. No messages on commandline
ade
Mon, 2021/09/20 - 20:43
Permalink
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
Thu, 2021/05/27 - 21:38
Permalink
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 "libGLESv2_adreno.so" not found
Library "eglSubDriverAndroid.so" not found
ade
Thu, 2021/05/27 - 22:16
Permalink
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?
Pages