You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I try to spawn an acme subsystem, however this is not going well in a container without booting on /usr/sbin/init.
The reason is that the spawn command is going to try to start the container. However, after reading
I understand that this should not happen. For some reasons this work perfectly well with pki-ca image and the spawning of the CA container without systemd service. But the argument is not working in the case of the acme.cfg. So this looks more like a bug. Could you confirm me if it is a bug? If yes I can look to do a PR for fixing it.
INFO: Using default realm configuration
INFO: Using default database configuration
INFO: Using default realm configuration
1
Please check pkispawn logs in /var/log/pkispawn.log
################################################################################################################################################################
Echo current process PID
System has not been booted with systemd as init system (PID 1). Can't operate. File "/usr/lib/python3.13/site-packages/pki/server/deployment/__init__.py", line 5874, in spawn ^^^^^^^^^^Loading deployment configuration from /conf/acme/acme.cfg.Please check pkispawn logs in /var/log/pkispawn.log self.spawn_acme() self.instance.start( max_wait=self.startup_timeout, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib64/python3.13/subprocess.py", line 419, in check_call File "/usr/lib/python3.13/site-packages/pki/server/deployment/__init__.py", line 5594, in spawn_acme ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ timeout=self.request_timeout) File "/usr/lib/python3.13/site-packages/pki/server/__init__.py", line 455, in start File "/usr/lib64/python3.13/subprocess.py", line 419, in check_callINFO: Using default metadata configuration ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib64/python3.13/subprocess.py", line 419, in check_callInstallation log: /var/log/pkispawn.log deployer.spawn() ~~~~~~~~~~~~~~~^^ max_wait=self.startup_timeout, self.instance.start( File "/usr/lib/python3.13/site-packages/pki/server/pkispawn.py", line 594, in main ~~~~~~~~~~~~~~~^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^################################################################################Installing ACME into /var/lib/pki/pki-tomcat.################################################################################################################################################################################################################################################Echo current process PIDFailed to connect to system scope bus via local transport: Host is down################################################################################INFO: Using default realm configurationINFO: Using default issuer configurationEcho current process PIDERROR: CalledProcessError: Command '['systemctl', 'start', '[email protected]']' returned non-zero exit status 1.Failed to connect to system scope bus via local transport: Host is downSpawn ACME component
The text was updated successfully, but these errors were encountered:
Hi,
I try to spawn an acme subsystem, however this is not going well in a container without booting on /usr/sbin/init.
The reason is that the spawn command is going to try to start the container. However, after reading
pki/base/server/python/pki/server/deployment/scriptlets/finalization.py
Line 67 in 0a88a9b
I understand that this should not happen. For some reasons this work perfectly well with pki-ca image and the spawning of the CA container without systemd service. But the argument is not working in the case of the acme.cfg. So this looks more like a bug. Could you confirm me if it is a bug? If yes I can look to do a PR for fixing it.
acme.cfg
spawn.log
The text was updated successfully, but these errors were encountered: