Cloud-init received SIGTERM and is thereby unable to install packages or running runcmd completely

[ubuntu-server-builder]

This bug was originally filed in Launchpad as LP: #1892902

Launchpad details

affected_projects = []
assignee = None
assignee_name = None
date_closed = None
date_created = 2020-08-25T17:55:52.328902+00:00
date_fix_committed = None
date_fix_released = None
id = 1892902
importance = undecided
is_complete = False
lp_url = https://bugs.launchpad.net/cloud-init/+bug/1892902
milestone = None
owner = carbrich
owner_name = Carbrich
private = False
status = triaged
submitter = carbrich
submitter_name = Carbrich
tags = []
duplicates = []

Launchpad user Carbrich(carbrich) wrote on 2020-08-25T17:55:52.328902+00:00

Fore some reason cloud-init failed to install package "SL". It receives a sigterm before trying to install package "SL" This only happens on CentOS 8. For all other packages I have the same issue. If I try to install packages within user-scrips "runcmd" I have the same issue. If I do a sleep or a ping within runcmd, I have the same issue.

If I remove /var/lib/cloud after a failed deployment and reboot the client, everything works fine. If i run the module with python the same way as cloud-init does, it works without exit 1.

It almost looks like some kind of race condition.

I packaged our base image with a daily build of cloud-init, to be sure it is not resolved in a later version of cloud-init. It has been tested with cloud-init 20.2+137.gc0450c02-1 and the behaviour is the same on cloud-init 18.5/19.4.

Our workflow; Image is getting build with packer and installed with all necessary items to run cloud-init.; Image is added to vCenter as a template; Foreman clones VM on vCenter; Machine boots, Vmware does the network configuration as described in cloud-init docs(Cloning on vCenter). Cloud-init installs puppet and registers client to puppet master.; In the background the image is imported in vCloud and more stuff happens for our monitoring etc..; For our CentOS 7 deployment street this workflow is working without any issues.

For more reading follow the link below, sorry for the mixed up data on the forum. I tried a lot! https://community.theforeman.org/t/cloud-init-does-not-install-puppet-but-runs-the-final-module-and-succeeds-according-cloud-init/20155/27

I also added cloud-init-1.tar.gz with the logs. The data is anonymized.

Your guys help will be welcome!

PS. Sometimes really sometimes it just works 1 out of 100 or so.

Cloud-config

---

#cloud-config hostname: test05 fqdn: test05 manage_etc_hosts: true users: {} packages:

• sl runcmd:
• touch /tmp/test

#cloud.cfg cloud_init_modules:

• bootcmd
• growpart

cloud_config_modules:

• runcmd
• timezone
• package-update-upgrade-install

cloud_final_modules:

• scripts-per-once
• scripts-per-boot
• scripts-per-instance
• scripts-user
• phone-home
• power_state_change
• final-message

system_info: distro: rhel paths: cloud_dir: /var/lib/cloud templates_dir: /etc/cloud/templates ssh_svcname: sshd

vim:syntax=yaml

/etc/cloud/cloud.cfg.d/01_network.cfg

---

network: config: disabled

10_foreman.cfg

cat /etc/cloud/cloud.cfg.d/10_foreman.cfg datasource_list: [NoCloud] datasource: NoCloud: seedfrom: http://foreman/userdata/

• &log_syslog | [handler_cloudLogHandler] class=handlers.SysLogHandler level=DEBUG formatter=simpleFormatter args=("/dev/log", handlers.SysLogHandler.LOG_USER)

/etc/cloud/cloud.cfg.d/05_logging.cfg

---

This yaml formated config file handles setting

logger information. The values that are necessary to be set

are seen at the bottom. The top '_log' are only used to remove

redundency in a syslog and fallback-to-file case.

The 'log_cfgs' entry defines a list of logger configs

Each entry in the list is tried, and the first one that

works is used. If a log_cfg list entry is an array, it will

be joined with '\n'.

_log:

• &log_base | [loggers] keys=root,cloudinit

  [handlers] keys=consoleHandler,cloudLogHandler

  [formatters] keys=simpleFormatter,arg0Formatter

  [logger_root] level=DEBUG handlers=consoleHandler,cloudLogHandler

  [logger_cloudinit] level=DEBUG qualname=cloudinit handlers= propagate=1

  [handler_consoleHandler] class=StreamHandler level=WARNING formatter=arg0Formatter args=(sys.stderr,)

  [formatter_arg0Formatter] format=%(asctime)s - %(filename)s[%(levelname)s]: %(message)s

  [formatter_simpleFormatter] format=[CLOUDINIT] %(filename)s[%(levelname)s]: %(message)s

• &log_file | [handler_cloudLogHandler] class=FileHandler level=DEBUG formatter=arg0Formatter args=('/var/log/cloud-init.log', 'a', 'UTF-8')

• &log_syslog | [handler_cloudLogHandler] class=handlers.SysLogHandler level=DEBUG formatter=simpleFormatter args=("/dev/log", handlers.SysLogHandler.LOG_USER)

log_cfgs:

Array entries in this list will be joined into a string

that defines the configuration.

If you want logs to go to syslog, uncomment the following line.

- [ *log_base, *log_syslog ]

The default behavior is to just log to a file.

This mechanism that does not depend on a system service to operate.

• [ *log_base, *log_file ]

A file path can also be used.

- /etc/log.conf

This tells cloud-init to redirect its stdout and stderr to

'tee -a /var/log/cloud-init-output.log' so the user can see output

there without needing to look on the console.

output: {all: '| tee -a /var/log/cloud-init-output.log'}

[ubuntu-server-builder]

Launchpad user Carbrich(carbrich) wrote on 2020-08-25T17:55:52.328902+00:00

Launchpad attachments: cloud init logs