Thanks for your input @reinier_post , I don't think it's container related but more related to the packaged files and what "splunk status" does on it's first run. (I may have work around that can assist you) Thanks also @isoutamo, I have tried the "tty" fix and it made no difference to the deployment stopping at the "splunk status" step. What I have done as a workaround (read "hack") was to determine what this "splunk status" is doing in the /opt/splunkforwarder/ directory. I mentioned that I could manually run the command and it would prompt and subsequent runs of the command would execute without prompting. What changes? So I went about to capture the file time stamps before I manually ran the "splunk status" command: find . -exec ls -ld {} \; > /tmp/list_before_status.txt and after I'd manually run the command: find . -exec ls -ld {} \; > /tmp/list_after_status.txt I compared the lists in "WinMerge" ("diff" is a little harder to visualize) and here's what I established: (1) It deletes ./ftr (does that stand for "First Time Run" ? Is it a flag for "splunk status"?) (2) It creates in the /opt/splunkforwarder directory: var/log/splunk/migration.log.2023-07-07.16-47-57 (file) var/run (a bunch of emtpy folders) var/lib (a bunch of emtpy folders) var/spool (a bunch of emtpy folders) etc/apps/ta-inspire/metadata (it took a sniff of my app and created this directory) etc/system/local/migration.conf (file) My solution (yes, "hack") was to capture these files/directories and put them into my Docker build and to delete the "frt" directory. I created a tar achive: tar tf /tmp/Splunk905_things.tar \ var/log/splunk/migration.log.2023-07-07.16-47-57 \ var/run \ var/lib \ var/spool \ etc/apps/ta-inspire/metadata \ etc/system/local/migration.conf I extracted the tar archive file from the running container and saved to my docker build directory. In my Dockerfile I wanted to include steps Update the image (always good practice) Remove the "ftr" folder Create the files/directories that "splunk status" would do on first run Here it is: FROM splunk/universalforwarder:latest LABEL authors="nev" USER root:root COPY ./Splunk905_things.tar /tmp/Splunk905_things.tar RUN microdnf update -y \ && cd /opt/splunkforwarder \ && rm -rf ftr \ && tar xvf /tmp/Splunk905_things.tar I was able to build this image, deploy it and restart the container which deployed normally and began forwarding logs as expected. That is, it works !! Disclaimer, I have no idea what the first run of "splunk status" does when it's executed from the ansible playbook as part of the deployment of Splunkforwarder 9.0.5. I may have captured my situation but if might fall short for yours. Maybe it was only the "ftr" folder that was holding this up. I followed a hunch that 1st time it ("splunk status") had to prompt and 2nd time it didn't so why no make the execution look like the 2nd time for the deployment? In any instance, if you pass the options "--no-prompt --answer-yes" to a command, you don't want it stop and ask whether or not you want to migrate your brand new deployment. (bug?)
... View more
