change hypercube systemd service type to get it in active state at start

[SohKa]

Hi !

I was doing some experiments with the hypercube.sh script and I noticed its systemd service never goes in active state. The reason is : because the service unit is of the oneshot type, the state is activating (start) during the execution (once it has successfully ran, it directly goes to inactive (dead)).

But I can not find a reason for this. No service needs to wait for it to finish its execution before being started (like the hypercube.sh depends on firstrun.service and secondrun.service) since it does the cube's setup until the end. Plus, since it provides a web server (SimpleHTTPServer), I think the hypercube.sh script isn't just a regular one-task shell script.

Thus, I think the type simple (as set in this PR) would be more convenient for this service.

I tested this change by reinstalling from scratch my lime2.

[SohKa]

A bit more context about my need :
In my custom script (so almost at the end of the hypercube.sh execution), I automated the move of the root (/) filesystem from the SD card to the SATA drive (if plugged). Before doing the rsync of the whole system, I want to make sure every non-essential applications are stopped.

So I created a systemd target unit to stop every services but the hypercube.service and the ssh.service ones (systemctl isolate hypercube.target). The problem is here. systemd is waiting the hypercube.service to be activated. But it never does because of the issue I explained in my first post. Changing the type of the systemd service hypercube.service from oneshot to simple would fix my problem.

[SohKa]

I realize my explanations are maybe a bit obscure (especially if one doesn't know about basic concept of systemd units). If you need clarifications, don't hesitate to ask ! :)

[HugoPoi]

I'm currently refactoring hypercube.sh and I notice this

https://github.com/labriqueinternet/build.labriqueinter.net/blob/ca5b450b424417418d8c8d80754553e267ff83c0/script/hypercube/hypercube.sh#L141-L146

which is part of your problem I think because we never know when the hypercube installation is done on systemd point of view.

So good fix would be to split the web log server in an other service type simple and have the installation step as oneshot without all the sleep crap.

[SohKa]

Indeed, independently of my issue, it would be nice that the web log server would have his own service.

If you implement this, I think this PR could be closed.