Kopano Core stopped supporting daemonized bg-process - why?
-
All, I recognized Kopano Core Community Edition 8.7.82 since ~June’19 stopped supporting background processes via daemonize / start-stop-daemon.
Unlike before and still in Supported 8.7.5 Kopano core services like kopano-server, spooler, dagent donot detach and have to be forced with -b(ackground) switch.
Reference: https://linux.die.net/man/1/daemonize & http://man7.org/linux/man-pages/man8/start-stop-daemon.8.htmlAlso, for dagent the -d(eamon) switch has been removed. Any reason why?? Anyone considered how painful this impact can be changing core behaviour?
Note I’m using daemonize / start-stop-daemon init-d scripts since 2016 for controlling services in Docker container for Kopano4s since systemd is not well married with docker.
I know Kopano stopped support for init.d scripts also not rolling out cfg-files as by decision systemd is default (https://forum.kopano.io/topic/1448/no-config-files-created-during-install)
As a consequence I have to test and maintain the init.d scripts since Kopano is no longer doing this (while others like postfix package maintainers still do support init.d).I also know Kopano Docker recently released is using dockerize (https://kopano.com/blog/building-docker-containers-for-kopano/) solving the issue their way.
So why this change? Could you please consider supporting expected behaviour with daemonize for the rest of the world?
-TosoBoso -
Hi @TosoBoso,
@TosoBoso said in Kopano Core stopped supporting daemonized bg-process - why?:
ince ~June’19 stopped supporting background processes via daemonize / start-stop-daemon
are you referring to https://jira.kopano.io/browse/KC-1428?
@TosoBoso said in Kopano Core stopped supporting daemonized bg-process - why?:
Kopano Docker recently released is using dockerize […] solving the issue their way.
No, that is actually not what dockerize is doing (not sure if it is even capable doing so). The mentioned container images use dumb-init for this (see https://github.com/zokradonh/kopano-docker/blob/master/core/Dockerfile#L68), which then starts a “simple” bash script which configures
and starts the individual services.The reason for the above linked ticket was to get rid of home made daemonisation, simply because todays distributions simply offer better ways in doing so (via for example systemd, dumb-init, …).
-
THX for quick reply Felix.
So yes it is related to https://jira.kopano.io/browse/KC-1428
Nice of “getting rind of the crap” better if to consider impact which is beyong BSD and when there is alternative plus one knows; well never mind that is what community nightly is for.So short time I can work-around this with start-stop-daemon -b(ackground) and already did so.
Next mid term I will consider to switch to dumb-init (https://github.com/Yelp/dumb-init) if it is superiour,Quick question what’s the difference between dumb-init and tini (https://github.com/krallin/tini) which comes native in Docker by using the --init switch at docker run? Both can handle init like process and signal handling for PID 1.
Can dumb-init do more aka bringing a process without the daemonize featuers (“old crap”) into the background?
-TosoBoso -
@TosoBoso said in Kopano Core stopped supporting daemonized bg-process - why?:
better if to consider impact which is beyong BSD and when there is alternative plus one knows; well never mind that is what community nightly is for.
I must say I fail to see what your are exactly complaining about.
@TosoBoso said in Kopano Core stopped supporting daemonized bg-process - why?:
Quick question what’s the difference between dumb-init and tini
They are quite alike. See https://gist.github.com/StevenACoffman/41fee08e8782b411a4a26b9700ad7af5#dumb-init-or-tini for a more detailed comparison.
-
Hi Felix,
I was complaining about the change removing daemonized being so fundamental it could have been announced better and considered in more details than found on KC-1428.
As we had discussion on init.d dependencies before I hoped of replies or early warning - in a perfect world way - instead I learned the hard way on community release and had to test and recode.The challange of best suited service control remains as Tiniy is drop in for dumb-init and does not resolve spawning non-root process and controlling multi-process.
Looking at this one: https://ahmet.im/blog/minimal-init-process-for-containers/ there is supervisord and s6-overlay, while the latter looks best solution and I will migrate to it.
Until then Tini combined with init.d scripts that spwan and control non-root processes appears to be pragmatically fine.
-TosoBoso -
@TosoBoso said in Kopano Core stopped supporting daemonized bg-process - why?:
As we had discussion on init.d dependencies before I hoped of replies or early warning
Just because I have told you in the past that relying on our init script in a Docker container is a bad idea does not mean I am always thinking about you when we plan to make a change to program startup.
@TosoBoso said in Kopano Core stopped supporting daemonized bg-process - why?:
instead I learned the hard way on community release
Building a product/app based on our nightly packages comes with the additional burden of having to monitor both our ticket tracker and our git repository (from the git commits you will also see related tickets) and doing testing/verification on your own. They do not offer the level of stability to issue six month warnings for installation impacting changes, this level of service is something we are aiming for in our supported releases.
And this is also exactly the reason why had asked you to switch to our supported releases for your app.
@TosoBoso said in Kopano Core stopped supporting daemonized bg-process - why?:
there is supervisord and s6-overlay, while the latter looks best solution and I will migrate to it.
Before redoing large parts of your current Docker image, please consider again to switch to https://github.com/zokradonh/kopano-docker as your base. In these containers the init situation is long resolved and with the recent Docker update Synology now offers a recent enough docker-compose as well.
PS: another small rant.
@TosoBoso said in Kopano Core stopped supporting daemonized bg-process - why?:
I hoped of replies or early warning - in a perfect world way
This “perfect world way” communication is a two way street. Instead of ranting to your Synology buddies about settings not found in our documentation (which were a large part of the 8.7 announcement btw) please consider reaching out to us with text suggestions or at least notices.
-
Felix,
it’s time to stop renting.
I recognized the change late and wanted to make transparent that it might impact others as well.
When I say perfect world it is wish list mode and I know comms are two way street so if you feel offended it never was my intension.
You asked me why I replied honestly and this was not meant as any rent. I outlined I recognized it on the community builds and thats what the beta is for.
To emphasise Kopano4s is switched to Stable as discussed and advised by you. The Beta is available for downgrade path primarily and testing.
For init system I’m not yet decided and I’m happy to consider parts of the Kopano package to which I had a look at already.
PS: one reason not yet using kopano-docker as a base is passing all env incl. sensitive data via the env. Instead docker secrets should be used e.g. the postgres package is doing it. Happy to elaborate and give input to zokradonh/kopano-docker
-TosoBoso -
Felix, one more thing:
Kopano4s is using multistaged build do ensure no leakage of sensitive data like SNR while zokradonh-kopano-docker is not afIk.
So on the one hand you remind me on advise to split Synology package into Stable and Beta, which BTW was released 1 month ago and on the other you advise to use the zokradonh image which does not (yet?) support multistaged build.
This is a bit of contradiction. Never mind I’m not intended to be picky or offending, just outlining the dilema.
I’m planning to merge the both pacages gradually equally by best of both worlds the multi-stage build should be considered in zokradonh-kopano-docker
-TosoBoso -
@TosoBoso said in Kopano Core stopped supporting daemonized bg-process - why?:
passing all env incl. sensitive data via the env.
Yes, I would rather see that as a benefit, though. since this way users don’t need to care for the actual configuration files. For the runtime this also isn’t an issue as the variables in question are unset before the final command run.
@TosoBoso said in Kopano Core stopped supporting daemonized bg-process - why?:
ensure no leakage of sensitive data like SNR while zokradonh-kopano-docker is not afIk.
Indeed and there is a large warning about this in the readme. Fortunately this is no issue for me, since I do not have to rely on a password to access our repository and for the case someone builds their own images then they can also use their own registry for these. In your case you could for example rely on images that we publish into our own registry.
Instead of trying to solve this with a multi-stage build I would rather see a solution in build time secrets. There is an issue for this as https://github.com/zokradonh/kopano-docker/issues/75, but I have not looked to deep into it. Contributions are welcome.
-
@TosoBoso said in Kopano Core stopped supporting daemonized bg-process - why?:
Also, for dagent the -d(eamon) switch has been removed. Any reason why?? Anyone considered how painful this impact can be changing core behaviour?
https://forum.kopano.io/topic/2512/socket-permissions-issues-with-kopano-server-build-8-7-81-162/4
-
@jengelh THX for making the linkage.
So I was not alone with my surprise and pain on the changes in the community build regarding removal old daemonize and some switches changes impacting init.d scripts. To be fair it was in the realease notes and community build is like sneak preview, not production.
I will watch out for the sockets permissions carefully, if needed add a chmod into the init.d scirpts.
As I’m working in Docker container I’m considering replacing the init.d start-stop-daemon -b by su-exec (https://github.com/ncopa/su-exec) triggered by tiny; I will NOT consider using &.
-TosoBoso
