[00:22] <hffgbbbffd> how can I trigger the cloud-init service to rerun as it never ran before? I tried clean then init then restarting the service, but that doesn't seem to do it
[00:30] <minimal> hffgbbbffd: are you trying to run the whole sequence manually? or trying to reset things so the next boot is treated as 1st boot?
[00:32] <hffgbbbffd> I'm currently troubleshooting why I get pam_systemd timeouts when any sudo commands are run from scripts via the cloud-init service. They only happen when cloud-init is run from systemd, so I'd like to run the whole sequence over and over to troubleshoot the pam timeouts specifically from the service?
[00:32] <hffgbbbffd> if I do something like `cloud-init -d init && cloud-init -d modules --mode final` it will run everything my current shell session and no pam timeouts occur so I'm trying to narrow it down to something in the service
[00:38] <hffgbbbffd> minimal ^
[00:42] <minimal> I haven't used cloud-init with systemd (my systems use openrc) but basically there's *4* cloud-init scripts run in sequence, cloud-init-local, cloud-init, cloud-config, and cloud-final
[00:43] <minimal> have you tried enabling cloud-init debugging to get more detail in the logfile?
[00:44] <minimal> s/scripts/stages/
[00:45] <hffgbbbffd> I think debugging is already turned on, but when it runs the script there is just a large gap of time spent in my custom script,
[00:45] <hffgbbbffd> 2022-01-29 22:43:56,585 - util.py[DEBUG]: Running command ['/var/lib/cloud/instance/scripts/part-001'] with allowed return codes [0] (shell=False, capture=False)
[00:45] <hffgbbbffd> 2022-01-29 22:56:29,210 - handlers.py[DEBUG]: finish: modules-final/config-scripts-user: SUCCESS: config-scripts-user ran successfully
[00:46] <hffgbbbffd> almost 10 minutes, now the script is filled with installation commands, but the pam logs show a timeout per command of like 25 seconds
[00:46] <hffgbbbffd> looks like the systemd script does this
[00:46] <hffgbbbffd> [Service]
[00:46] <hffgbbbffd> Type=oneshot
[00:46] <hffgbbbffd> ExecStart=/usr/bin/cloud-init init
[00:46] <hffgbbbffd> RemainAfterExit=yes
[00:46] <hffgbbbffd> TimeoutSec=0
[00:51] <hffgbbbffd> basically trying to test if something like this service is missing system-login or something before cloud-init runs, cause I added another service and it can sudo just fine
[00:52] <hffgbbbffd> hence why I want to run it from scratch on demand from the service by itself, is there a way to reset the data the cloud-init binary relies on?
[00:54] <minimal> a "cloud-init clean" should do that AFAIK
[01:00] <hffgbbbffd> ok I reproduced it via the systemd service doing something like this
[01:00] <hffgbbbffd>  rm -Rf /var/lib/cloud && cloud-init init && systemctl restart cloud-init
[01:00] <hffgbbbffd> and changing execstart=/usr/bin/cloud-init -d modules --mode final
[01:01] <hffgbbbffd> now the hard part I guess, why would cloud-init via systemd get pam timeouts but not via my root shell
[01:24] <minimal> hffgbbbffd: something needing a terminal device somehow?
=== mamercad7 is now known as mamercad
[17:56] <blackboxsw> falcojr: sorry just merged https://github.com/canonical/cloud-init/pull/1220 to order LXD datasource at end of list for Bionic. I'll watch for your reflected PRs on other Ubunut series branches 
[17:56] <ubottu> Pull 1220 in canonical/cloud-init "Move LXD to end of datasource_list" [Merged]
[18:02] <falcojr> blackboxsw: thanks I"ll get the rest of the branches up later today
[19:03] <henk> minimal: nah, don’t care enough
[19:28] <blackboxsw> Thanks james for the followup on schema-a-d just pushed final changes there.
[20:14] <falcojr> blackboxsw: rest of the LXD ds PRs are up
=== SirScott9 is now known as SirScott
=== VoliKoN00 is now known as VoliKoN0
[22:23] <blackboxsw> falcojr: thanks and merged.
[22:24] <blackboxsw> holmanb: +1 on better deprecation handling for cloud-config schema changes. Right now we have migration support for a few different modules, but I think it's worth us defining a process by which we officially deprecate old #cloud-config schema via both log warnings and CLI tooling as you said. Added a tracking item for our ongoign schema work for us to sort by 22.04 https://warthogs.atlassian.net/browse/SC-774
[22:28] <holmanb> @blackboxsw: Thanks, sounds good to me :)