We have moved to a new Sailfish OS Forum. Please start new discussions there.
7

start-aliendalvik-preinit.sh

asked 2019-09-09 19:48:49 +0300

UweLabs gravatar image

updated 2019-09-09 19:59:41 +0300

SFOS 3.1.0.11.

systemctl status aliendalvik.service

shows:

...
ExecStartPre=/usr/bin/start-aliendalvik-preinit.sh (code=exited, status=203/EXEC)
...

Actually there is no file /usr/bin/start-aliendalvik-preinit.sh. Has this any consequence or is this just a "cosmetic" bug ? Best regards, Uwe.

Edit: In /lib/systemd/system/aliendalvik.service in block [Service] there is the line

ExecStartPre=-/usr/bin/start-aliendalvik-preinit.sh

Is this a bug?

edit retag flag offensive close delete

Comments

at least i have the impression that since the update starting of first android app takes much longer. this would be an explanation

Kekskopf ( 2019-09-09 21:52:50 +0300 )edit

1 Answer

Sort by » oldest newest most voted
3

answered 2019-09-10 19:06:56 +0300

adekker gravatar image

First of all it's not related to the SFOS version, but to AlienDalvik for Android 8.1. The dash sign in front of /usr/bin/start-aliendalvik-preinit.sh in the unit file means it is allowed to fail.

As long as it does not affect the functionality of AlienDalvik itself I would not call it a bug, but it would be better if the line was removed if it serves no purpose.

edit flag offensive delete publish link more

Comments

Thank you very much for your explanation. It seems I have overlooked that little dash. So I could delete that line. But the questions arises if the developers might had the intention to change this line to something else and have forgotten to do that... Best regards, Uwe.

UweLabs ( 2019-09-10 19:44:01 +0300 )edit

I think the answer above is plausible. Based on that, it makes sense that they would want to execute it if it exists, and not fail if it doesn't. The only consequence being that if the script legitimately fails, it wouldn't be noticed. So a wrapper may have technically been a better option. Another way would be to detect whether it's needed at build time. But then that would likely require separate packages for different situations, which would complicate things a lot when defining how dependencies work.

On the flip side, if it's something like indexing, or cleanup, maybe it's not considered important as to whether it succeeds or fails.

But more likely, it's intended to run-once (Eg to make sure directories are created) and delete itself on success. And this was simply a convenient way of achieving that without over-complicating things.

Another possibility is that it's future proofing for something in an up-coming version.

In any case, I'd leave it alone, unless there's a reason you want to mess with it?

ksandom ( 2019-09-11 10:32:13 +0300 )edit
1

This sounds very plausible. So I'll leave my hands off... Best regards, Uwe.

UweLabs ( 2019-09-11 15:41:30 +0300 )edit

Whoops, I hope I didn't put you off. I could have worded that last sentence better. I definitely encourage tinkering. :)

ksandom ( 2019-09-12 09:42:48 +0300 )edit
Login/Signup to Answer

Question tools

Follow
3 followers

Stats

Asked: 2019-09-09 19:48:49 +0300

Seen: 407 times

Last updated: Sep 10 '19