Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

SOLVED

Getting error in pipeline, during build image

Avatar

Level 8

Getting the error under build image in the pipeline execution.

Ran the local cloud validator and it does not show any error:

shaileshbassi_0-1656996967719.png

 

Error:

 

2022/07/04 15:04:24 /tmp/dispatcher/unzippedConfiguration: unable to find any farm in 'conf.dispatcher.d/enabled_farms'
The command '/bin/sh -c AZCOPY="/usr/bin/azcopy" VALIDATOR_BINARY="/usr/bin/dispatcher-configuration-validator" HTTPD_BINARY="/usr/sbin/httpd" DISPATCHER_CONFIGURATION_LOCATION=$dispatcherConfigurationLocation DISPATCHER_CONFIGURATION_DESTINATION=$dispatcherConfigurationDestination DISPATCHER_IMAGE=$dispatcherImage RUN_MODE=$runmode ./validateDispatcherConfiguration.sh' returned a non-zero code: 2
2022/07/04 15:04:24 Container failed during run: validate-dispatcher. No retries remaining.
failed to run step ID: validate-dispatcher: exit status 2

 

I have checked the farm file as well and there is the entry within it. PFB:

 

#
# This is the default publish farm definition for the dispatcher module. 
#
# DO NOT EDIT this file, your changes will have no impact on your deployment.
#
# Instead create a copy in the folder conf.dispatcher.d/available_farms and edit the copy.
# Finally, change to the directory conf.dispatcher.d/enabled_farms, remove the symbolic
# link for default_farm.any and create a symbolic link to your copy.
#

/publishfarm {
	# client headers which should be passed through to the render instances
	# (feature supported since dispatcher build 2.6.3.5222)
	/clientheaders {
		$include "../clientheaders/clientheaders.any"
	}
	# hostname globbing for farm selection (virtual domain addressing)
	/virtualhosts {
		$include "../virtualhosts/virtualhosts.any"
	}
	# the load will be balanced among these render instances
	/renders {
		$include "../renders/default_renders.any"
	}
	# only handle the requests in the following acl. default is 'none'
	# the glob pattern is matched against the first request line
	/filter {
		$include "../filters/filters.any"
	}
	# if the package is installed on publishers to generate a list of all content with a vanityurl attached
	# this section will auto-allow the items to bypass the normal dispatcher filters
	# Reference: https://docs.adobe.com/docs/en/dispatcher/disp-config.html#Enabling%20Access%20to%20Vanity%20URLs%20-%20/vanity_urls
	# /vanity_urls {
	#	/url    "/libs/granite/dispatcher/content/vanityUrls.html"
	#	/file   "/tmp/vanity_urls"
	#	/delay  300
	# }
	# allow propagation of replication posts (should seldomly be used)
	/propagateSyndPost "0"
	# the cache is used to store requests from the renders for faster delivery
	# for a second time.
	/cache {
		# The cacheroot must be equal to the document root of the webserver
		/docroot "${DOCROOT}"
		# sets the level upto which files named ".stat" will be created in the
		# document root of the webserver. when an activation request for some
		# handle is received, only files within the same subtree are affected
		# by the invalidation.
		/statfileslevel "2"
		# caches also authorized data
		/allowAuthorized "0"
		# Flag indicating whether the dispatcher should serve stale content if
		# no remote server is available.
		/serveStaleOnError "1"
		# the rules define, which pages should be cached. please note that
		# - only GET requests are cached
		# - only requests with an extension are cached
		# - only requests without query parameters ( ? ) are cached
		# - only unauthorized pages are cached unless allowUnauthorized is set to 1
		/rules {
			$include "../cache/rules.any"
		}
		# the invalidate section defines those pages which are 'invalidated' after
		# any activation. please note that, the activated page itself and all 
		# related documents are flushed on an modification. for example: if the 
		# page /foo/bar is activated, all /foo/bar.* files are removed from the
		# cache.
		/invalidate {
			/0000 {
				/glob "*"
				/type "deny"
			}
			/0001 {
				/glob "*.html"
				/type "allow"
			}
			# to ensure that AEM forms HTMLs are not auto-invalidated due to invalidation of any other resource. It is supposed to be deleted only after its own activation.
			/0002
			{
				/glob "/content/forms/**/*.html"
				/type "deny"
			}
		}
		/allowedClients {
			$include "../cache/default_invalidate.any"
		}
		# The ignoreUrlParams section contains query string parameter names that
		# should be ignored when determining whether some request's output can be
		# cached or delivered from cache.
		# In this example configuration, the "q" parameter will be ignored.
		# /ignoreUrlParams {
		#	/0001 { /glob "*" /type "deny" }
		#	/0002 { /glob "q" /type "allow" }
		# }

		# Cache response headers next to a cached file. On the first request to
		# an uncached resource, all headers matching one of the values found here
		# are stored in a separate file, next to the cache file. On subsequent
		# requests to the cached resource, the stored headers are added to the
		# response.
		# Note, that file globbing characters are not allowed here.
		/headers {
			"Cache-Control"
			"Content-Disposition"
			"Content-Type"
			"Expires"
			"Last-Modified"
			"X-Content-Type-Options"
		}
		# A grace period defines the number of seconds a stale, auto-invalidated
		# resource may still be served from the cache after the last activation
		# occurring. Auto-invalidated resources are invalidated by any activation,
		# when their path matches the /invalidate section above. This setting
		# can be used in a setup, where a batch of activations would otherwise
		# repeatedly invalidate the entire cache.
		/gracePeriod "2"

		# Enable TTL evaluates the response headers from the backend, and if they
		# contain a Cache-Control max-age or Expires date, an auxiliary, empty file
		# next to the cache file is created, with modification time equal to the
		# expiry date. When the cache file is requested past the modification time
		# it is automatically re-requested from the backend.
		/enableTTL "1"
	}
}

 

Any suggestions?

Thanks 

1 Accepted Solution

Avatar

Correct answer by
Level 8

Thanks for the response @Gucci-Paull-108. The symlink issue got fixed with teh Wins Subsytem.
But the build is still failing, but no error seen in the buildimage logs.

@jalaja @Gucci-Paull-108 Can you help here, what could have gone wrong. PFB for the buildimage log snippet

 

Successfully built 427b7d8f291c
Successfully tagged cmpl0va80ctrg0build0prd.azurecr.io/dispatcher-validation:ca24wfq
2022/07/06 11:38:32 Successfully executed container: validate-dispatcher
2022/07/06 11:38:32 Step ID: create-dockerfile marked as successful (elapsed time in seconds: 0.564543)
2022/07/06 11:38:32 Step ID: prefetch-images marked as successful (elapsed time in seconds: 3.623359)
2022/07/06 11:38:32 Populating digests for step ID: prefetch-images...
2022/07/06 11:38:33 Successfully populated digests for step ID: prefetch-images
2022/07/06 11:38:33 Step ID: validate-dispatcher marked as successful (elapsed time in seconds: 18.040090)
2022/07/06 11:38:33 Populating digests for step ID: validate-dispatcher...
2022/07/06 11:38:34 Successfully populated digests for step ID: validate-dispatcher
2022/07/06 11:38:34 The following dependencies were found:
2022/07/06 11:38:34 
- image:
    registry: cmpl0va80ctrg0build0prd.azurecr.io
    repository: preload
    tag: ca24wfq
  runtime-dependency:
    registry: cmpl0va80ctrg0build0prd.azurecr.io
    repository: aem-ethos/dispatcher-publish
    tag: 2.0.104
    digest: sha256:efcf9d49375278eeb3c7ef61b4a762b0fca796770d4905c2c622938fb3d9b80d
  git: {}
- image:
    registry: cmpl0va80ctrg0build0prd.azurecr.io
    repository: dispatcher-validation
    tag: ca24wfq
  runtime-dependency:
    registry: cmpl0va80ctrg0build0prd.azurecr.io
    repository: aem-ethos/dispatcher-publish
    tag: 2.0.104
    digest: sha256:efcf9d49375278eeb3c7ef61b4a762b0fca796770d4905c2c622938fb3d9b80d
  git: {}

Run ID: ca24wfq was successful after 28s

 

Thanks

View solution in original post

7 Replies

Avatar

Level 6

unable to find any farm in conf.dispatcher.d/enabled_farms

 

Your enabled farms should be located in the mentioned subfolder.

file included (…) must be named: …

There are two sections in your farm configuration that must include a
specific file: /renders and /allowedClients in the /cache section. Those
sections must look as follows:

 

/renders {
    $include "../renders/default_renders.any"
}

and:

/allowedClients {
    $include "../cache/default_invalidate.any"
}

Refer for more information it has complete information about this issue:

 

https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/implementing/conten... 

Avatar

Level 8

@tusharbias I checked about the points mentioned in the thread above. Everything is already there as per the documentation.

Thanks 

Avatar

Employee

@shaileshbassi Could you please try below steps to resolve the dispatcher error 'unable to find any farm in 'conf.dispatcher.d/enabled_farms':
1. On the project directory, go to folder /dispatcher/src/conf.dispatcher.d/available_farms/ and locate a file called default.farm.
2. Delete the content in default.farm at location /dispatchersrc/conf.dispatcher.d/enabled_farms/ and replace with '../available_farms/default.farm'.

Run the pipeline again.

Avatar

Level 8

@jalaja I have already executed the below steps: 

  1. Delete the file under "/dispatchersrc/conf.dispatcher.d/enabled_farms/"
  2. Ran the command, which create the symlink for the file
mklink "<file-location>\dispatcher\src\conf.dispatcher.d\enabled_farms\default.farm" "<file-location>\dispatcher\src\conf.dispatcher.d\available_farms\default.farm"

And then ran the pipeline.

Right now, what I could sense from some of the links that it creates the problems which the symlinks are created from the windows machine. Is that true?

 

Thanks

 

Avatar

Employee

For knowledge share, a symbolic link only works in a *nix based file system. The link gets committed back to Source Control. To create this type of link on a MS Windows O/S, you need to use the Wins Subsystem for Linux add-on for Wins v10 [0]. Wins shortcuts/links do not function in the Dispatcher container, and are not supported in the GIT repository.

 

[0] https://docs.microsoft.com/en-us/windows/wsl/install-win10

Avatar

Correct answer by
Level 8

Thanks for the response @Gucci-Paull-108. The symlink issue got fixed with teh Wins Subsytem.
But the build is still failing, but no error seen in the buildimage logs.

@jalaja @Gucci-Paull-108 Can you help here, what could have gone wrong. PFB for the buildimage log snippet

 

Successfully built 427b7d8f291c
Successfully tagged cmpl0va80ctrg0build0prd.azurecr.io/dispatcher-validation:ca24wfq
2022/07/06 11:38:32 Successfully executed container: validate-dispatcher
2022/07/06 11:38:32 Step ID: create-dockerfile marked as successful (elapsed time in seconds: 0.564543)
2022/07/06 11:38:32 Step ID: prefetch-images marked as successful (elapsed time in seconds: 3.623359)
2022/07/06 11:38:32 Populating digests for step ID: prefetch-images...
2022/07/06 11:38:33 Successfully populated digests for step ID: prefetch-images
2022/07/06 11:38:33 Step ID: validate-dispatcher marked as successful (elapsed time in seconds: 18.040090)
2022/07/06 11:38:33 Populating digests for step ID: validate-dispatcher...
2022/07/06 11:38:34 Successfully populated digests for step ID: validate-dispatcher
2022/07/06 11:38:34 The following dependencies were found:
2022/07/06 11:38:34 
- image:
    registry: cmpl0va80ctrg0build0prd.azurecr.io
    repository: preload
    tag: ca24wfq
  runtime-dependency:
    registry: cmpl0va80ctrg0build0prd.azurecr.io
    repository: aem-ethos/dispatcher-publish
    tag: 2.0.104
    digest: sha256:efcf9d49375278eeb3c7ef61b4a762b0fca796770d4905c2c622938fb3d9b80d
  git: {}
- image:
    registry: cmpl0va80ctrg0build0prd.azurecr.io
    repository: dispatcher-validation
    tag: ca24wfq
  runtime-dependency:
    registry: cmpl0va80ctrg0build0prd.azurecr.io
    repository: aem-ethos/dispatcher-publish
    tag: 2.0.104
    digest: sha256:efcf9d49375278eeb3c7ef61b4a762b0fca796770d4905c2c622938fb3d9b80d
  git: {}

Run ID: ca24wfq was successful after 28s

 

Thanks

Avatar

Employee

Log a support case with us because a few other customers have reported this today too. Don't forget to include this forum thread URL in description field.