github.com/mmcquillan/packer@v1.1.1-0.20171009221028-c85cf0483a5d/website/source/docs/other/debugging.html.md (about) 1 --- 2 description: | 3 Packer strives to be stable and bug-free, but issues inevitably arise where 4 certain things may not work entirely correctly, or may not appear to work 5 correctly. 6 layout: docs 7 page_title: 'Debugging - Other' 8 sidebar_current: 'docs-other-debugging' 9 --- 10 11 # Debugging Packer Builds 12 13 For remote builds with cloud providers like Amazon Web Services AMIs, debugging 14 a Packer build can be eased greatly with `packer build -debug`. This disables 15 parallelization and enables debug mode. 16 17 Debug mode informs the builders that they should output debugging information. 18 The exact behavior of debug mode is left to the builder. In general, builders 19 usually will stop between each step, waiting for keyboard input before 20 continuing. This will allow you to inspect state and so on. 21 22 In debug mode once the remote instance is instantiated, Packer will emit to the 23 current directory an ephemeral private ssh key as a .pem file. Using that you 24 can `ssh -i <key.pem>` into the remote build instance and see what is going on 25 for debugging. The key will only be emitted for cloud-based builders. The 26 ephemeral key will be deleted at the end of the packer run during cleanup. 27 28 For a local builder, the SSH session initiated will be visible in the detail 29 provided when `PACKER_LOG=1` environment variable is set prior to a build, 30 and you can connect to the local machine using the userid and password defined 31 in the kickstart or preseed associated with initialzing the local VM. 32 33 ### Windows 34 35 As of Packer 0.8.1 the default WinRM communicator will emit the password for a 36 Remote Desktop Connection into your instance. This happens following the several 37 minute pause as the instance is booted. Note a .pem key is still created for 38 securely transmitting the password. Packer automatically decrypts the password 39 for you in debug mode. 40 41 ## Debugging Packer 42 43 Issues occasionally arise where certain things may not work entirely correctly, 44 or may not appear to work correctly. In these cases, it is sometimes helpful to 45 see more details about what Packer is actually doing. 46 47 Packer has detailed logs which can be enabled by setting the `PACKER_LOG` 48 environmental variable to any value but `""` (empty string) and `"0"` like this 49 `PACKER_LOG=1 packer build <config.json>`. This will cause detailed logs to 50 appear on stderr. The logs contain log messages from Packer as well as any 51 plugins that are being used. Log messages from plugins are prefixed by their 52 application name. 53 54 Note that because Packer is highly parallelized, log messages sometimes appear 55 out of order, especially with respect to plugins. In this case, it is important 56 to pay attention to the timestamp of the log messages to determine order. 57 58 In addition to simply enabling the log, you can set `PACKER_LOG_PATH` in order 59 to force the log to always go to a specific file when logging is enabled. Note 60 that even when `PACKER_LOG_PATH` is set, `PACKER_LOG` must be set in order for 61 any logging to be enabled. 62 63 ### Debugging Packer in Powershell/Windows 64 65 In Windows you can set the detailed logs environmental variable `PACKER_LOG` or 66 the log variable `PACKER_LOG_PATH` using powershell environment variables. For 67 example: 68 69 ``` powershell 70 $env:PACKER_LOG=1 71 $env:PACKER_LOG_PATH="packerlog.txt" 72 ``` 73 74 If you find a bug with Packer, please include the detailed log by using a 75 service such as [gist](https://gist.github.com). 76 77 ## Issues Installing Ubuntu Packages 78 79 Issues may arise using and building Ubuntu AMIs where common packages that 80 *should* be installed from Ubuntu's Main repository are not found during a 81 provisioner step: 82 83 amazon-ebs: No candidate version found for build-essential 84 amazon-ebs: No candidate version found for build-essential 85 86 This, obviously can cause problems where a build is unable to finish 87 successfully as the proper packages cannot be provisioned correctly. The problem 88 arises when cloud-init has not finished fully running on the source AMI by the 89 time that packer starts any provisioning steps. 90 91 Adding the following provisioner to the packer template, allows for the 92 cloud-init process to fully finish before packer starts provisioning the source 93 AMI. 94 95 ``` json 96 { 97 "type": "shell", 98 "inline": [ 99 "while [ ! -f /var/lib/cloud/instance/boot-finished ]; do echo 'Waiting for cloud-init...'; sleep 1; done" 100 ] 101 } 102 ``` 103 104 ## Issues when using numerous Builders/Provisioners/Post-Processors 105 106 Packer uses a separate process for each builder, provisioner, post-processor, 107 and plugin. In certain cases, if you have too many of these, you can run out of 108 [file descriptors](https://en.wikipedia.org/wiki/File_descriptor). This results 109 in an error that might look like 110 111 ``` text 112 error initializing provisioner 'powershell': fork/exec /files/go/bin/packer: 113 too many open files 114 ``` 115 116 On Unix systems, you can check what your file descriptor limit is with `ulimit -Sn`. You should check with your OS vendor on how to raise this limit. 117 118 ## Issues when using long temp directory 119 120 Packer uses unix sockets internally, which are created inside the default 121 directory for temporary files. Some operating systems place a limit on the 122 length of the socket name, usually between 80 and 110 characters. If you get an 123 error like this (for any builder, not just docker): 124 125 ``` text 126 Failed to initialize build 'docker': error initializing builder 'docker': plugin exited before we could connect 127 ``` 128 129 you should try setting your temp directory to something shorter. This can be 130 done through the `TMPDIR` environment variable.