| 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:22 |
|---|---|---|
| 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:30 |
| 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:32 |
| hffgbbbffd | minimal ^ | 00:38 |
| 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:42 |
| minimal | have you tried enabling cloud-init debugging to get more detail in the logfile? | 00:43 |
| minimal | s/scripts/stages/ | 00:44 |
| 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:45 |
| 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:46 |
| 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:51 |
| 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:52 |
| minimal | a "cloud-init clean" should do that AFAIK | 00:54 |
| 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:00 |
| hffgbbbffd | now the hard part I guess, why would cloud-init via systemd get pam timeouts but not via my root shell | 01:01 |
| minimal | hffgbbbffd: something needing a terminal device somehow? | 01:24 |
| === mamercad7 is now known as mamercad | ||
| 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] | 17:56 |
| falcojr | blackboxsw: thanks I"ll get the rest of the branches up later today | 18:02 |
| henk | minimal: nah, don’t care enough | 19:03 |
| blackboxsw | Thanks james for the followup on schema-a-d just pushed final changes there. | 19:28 |
| falcojr | blackboxsw: rest of the LXD ds PRs are up | 20:14 |
| === SirScott9 is now known as SirScott | ||
| === VoliKoN00 is now known as VoliKoN0 | ||
| blackboxsw | falcojr: thanks and merged. | 22:23 |
| 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:24 |
| holmanb | @blackboxsw: Thanks, sounds good to me :) | 22:28 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!