zinit issues

[despiegk]

• zinit log, should also be possible without waiting
• zinit list gives weird error if zinit is not started yet, it should still list or tell that init needs to happen
• zinit can get started multiple times, it should check its not started yet and if it is , just don't do anything

could not shutdown

basezinitredis: zinit shutdown zinit: INFO (zinit::zinit) shutting down zinit: INFO (zinit::zinit) service 'redis' is scheduled for a shutdown basezinitredis: zinit: ERROR (zinit::app::api) failed to execute shutdown: EPERM: Operation not permitted

I had to remove it with a hard kill

[muhamadazmy]

zinit is built to run as a process manager to replace systemd. Hence it need to run as pid (init process). There are other ways to run it as a normal process (in debugging mode) in that case you are actively doing development on it and know exactly what you are doing.

So zinit can run mainly as follows:

• PID 1 (how it runs in zos)
• PID 1 inside a container (mainly flists already uses it) this is done using a special flag (zinit init --container)
  • in that mode shutting down only stops all processes and does not try to actually shutdown the system (with kernel sys-rq)

Also running any command like zinit logs or other commands, calls the PID 1 over a unix socket to execute this command. hence you can't run it unless zinit init is actually running! so all other zinit commands are just an api call to the main process.

This means:

• zinit log won't work without zinit running, because if there are no zinit, means there are no processes and if there are no processes, there are no logs. zinit keep all processes logs in a fixed size ringbuffer, we never write them to disk.
  • (in zos we use vecotr to attack to the ringbuffer, and push all logs to vector aggregation sever)
• zinit list also need to have zinit already working otherwise it won't be able to list what services are monitored and their statuses
• zinit can be indeed started multiple times in debug mode. (for development) and in that case you need to give them different unix sockets paths otherwise they will override the socket and hence older started processes won't be reachable anymore with the zinit command

[despiegk]

this can be done more logical in my opinion

• to run something in debug mode should not impact how its done in development, its not logical for users it can run multiple times
• I had lots of issues to try and get it to work in container, will try the option
• some of the returns is simply not good enough, it should say e.g. zinit not running, ...

[muhamadazmy]

We can for sure improve the errors reporting always

[xmonader]

the issue for error reporting https://github.com/threefoldtech/zinit/pull/48