Public bug reported: output of cloud-init-local.service can get lost in systemd. The result is that there is no output in /var/log/cloud-init.log from cloud-init-local.service.
There is some information in https://code.launchpad.net/~harlowja/cloud-init/+git/cloud-init/+merge/301729 about how this occurrs and how it used to work. copying part of that here: Cloud-init's logging basically employed a "try syslog and fallback to direct log to file". The proposed "just log to a file" is definitely dramatically simpler and advantageous in some cases. The way the "try syslog and fallback" works (or worked) on Ubuntu up until systemd was: a.) cloud-init init --local 1. read logging config, 2. attempt to log to syslog ([ *log_base, *log_syslog ]) 3. that fail, so it log to file directly b.) cloud-init init 1.) rsyslog would have /dev/log up functional at this point 2.) cloud-init logging config read and ends up logging to syslog Systemd changed some things in teh way /dev/log was handled, and the above no longer worked well. Additionally, cloud-init installs a file /etc/rsyslog.d/21-cloudinit.conf which tells rsyslog to redirect messages generated by cloud-init to /var/log/cloud-init.log The value of doing this in this way was that we use syslog, so if the user had configured the system to log remotely, cloud-init's logs would go to that remote system as they desired. If we directly log to a file, then cloud-init's log messages will not without further configuration go to syslog. One other thing to be aware of is that cloud-init can itself configure rsyslog through cloudinit/config/cc_rsyslog.py . So, the user could provide in user-data some rsyslog configuration, and then the system's syslog (including cloud-init messages) would start goign to that remote server as soon as they realistically could. ** Affects: cloud-init Importance: Medium Status: Fix Committed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1643990 Title: cloud-init-local.service messages not written to /var/log/cloud- init.log in systemd Status in cloud-init: Fix Committed Bug description: output of cloud-init-local.service can get lost in systemd. The result is that there is no output in /var/log/cloud-init.log from cloud-init-local.service. There is some information in https://code.launchpad.net/~harlowja/cloud-init/+git/cloud-init/+merge/301729 about how this occurrs and how it used to work. copying part of that here: Cloud-init's logging basically employed a "try syslog and fallback to direct log to file". The proposed "just log to a file" is definitely dramatically simpler and advantageous in some cases. The way the "try syslog and fallback" works (or worked) on Ubuntu up until systemd was: a.) cloud-init init --local 1. read logging config, 2. attempt to log to syslog ([ *log_base, *log_syslog ]) 3. that fail, so it log to file directly b.) cloud-init init 1.) rsyslog would have /dev/log up functional at this point 2.) cloud-init logging config read and ends up logging to syslog Systemd changed some things in teh way /dev/log was handled, and the above no longer worked well. Additionally, cloud-init installs a file /etc/rsyslog.d/21-cloudinit.conf which tells rsyslog to redirect messages generated by cloud-init to /var/log/cloud-init.log The value of doing this in this way was that we use syslog, so if the user had configured the system to log remotely, cloud-init's logs would go to that remote system as they desired. If we directly log to a file, then cloud-init's log messages will not without further configuration go to syslog. One other thing to be aware of is that cloud-init can itself configure rsyslog through cloudinit/config/cc_rsyslog.py . So, the user could provide in user-data some rsyslog configuration, and then the system's syslog (including cloud-init messages) would start goign to that remote server as soon as they realistically could. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1643990/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
