Exec/debug - Is it possible to use a shell other than bash?

[SansGuidon]

Hi,
I've packaged an minimalistic app based on Alpine, and I'm able to package it and make it run on my Cloudron but it seems impossible to debug it unless I install bash addition to the base alpine image.

My attempts to use cloudron exec or cloudron debug have both failed unless bash is present in the image.

Is there a way to run a different shell and then what might I be missing? The source code for box mostly reference bash as a default choice which is totally valid but I just want to know if it's obligatory or not, I couldn't find a clear answer in the source code nor in docs about the packaging requirements.

Thanks!

[girish]

For exec, you can do cloudron exec --tty sh . cloudron debug <cmd> . cmd needs to somehow "hang". If you have sleep in your Docker image, you can do cloudron debug sleep infinity.

There was some legacy commander parsing code in our CLI. Luckily, commander now supports variadic args and I have fixed our CLI and published a new version 5.12.0 . Can you check with that?

[SansGuidon]

Nice, the syntax cloudron exec --app <app> --tty sh works perfectly

[nebulon]

note that, there is very little benefit in packaging apps with a stripped down base image, as Cloudron will anyways will have the Cloudron baseimage on the system already, so if you base it from some other image, it actually increases the required disk space, while not having access to standard linux tooling within the app. Such alpine images do make sense if you have deployments where you deploy containers on various nodes, so each node can have very slim images, but this does not really apply to a Cloudron setup.

[SansGuidon]

If I understand you right, having the cloudron base image would reduce the total disk space used by all my docker images running on cloudron?
Because right now I'm observing the opposite with what I have checked using du and docker images, where each docker image takes on average 3GB and the total of docker images is 80GB on disk.
Based on your explanation, sharing the base image (2.2GB in size) would also save around 60GB disk space for my 28/29 images. Or maybe something is not right in my understanding.
Yet having a base image 50MB in size for a small app makes more sense to my taste than having a base image as big as 2+GB?
What do you think @nebulon ?

[nebulon]

Since stock unix tools like du are not working well with the virtualized layered filesystems docker uses, you have to use docker tooling like docker system df to get the real size for those.

[SansGuidon]

@nebulon said in Exec/debug - Is it possible to use a shell other than bash?:

Since stock unix tools like du are not working well with the virtualized layered filesystems docker uses, you have to use docker tooling like docker system df to get the real size for those.

Initially I've tried docker system df but this command is so expensive (https://github.com/moby/moby/issues/31719 / https://github.com/moby/moby/pull/31973 / https://github.com/moby/moby/issues/31951) I was just switching to df and du instead to save time.

After 10 minutes of patience, the command finally returns:

~# docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          28        27        14.65GB   2.21GB (15%)
Containers      44        29        0B        0B
Local Volumes   58        58        3.253GB   0B (0%)
Build Cache     0         0         0B        0B

As it show different information than df and du, I'm still unsure what information is about to be taken into account for considering disk full. It's all good in the table above, but will the os really be smart enough to read 15GB instead of 80GB?

[nebulon]

Those fileszstem operations are indeed expensive in combination with large disks, networked disks and the various virtually layered filesystems on top. This is also why Cloudron only calculates disk usage for apps and resources on a cron job. The filesystem itself (the one where you usually would have ext4) will show the correct usage information on a filesystem level. To add to the complexity here, docker image sizes are also reported in a way where there can be duplicated GBs if layers are shared.

[SansGuidon]

Thanks for the explanation.