トラブルシューティング方法
Automation Suite ではログが生成されるので、インストール エラーをトラブルシューティングする必要がある場合は、いつでもこのログを検索できます。インストール中に発生する問題の詳細はすべて、install-uipath.sh
スクリプトを含むディレクトリに保存されたログ ファイルで確認できます。インストーラーを実行するたびに、install-$(date +'%Y-%m-%dT%H_%M_%S').log
の命名規則に則った新しいログ ファイルが生成されます。このログ ファイルは、インストールに関連する問題が発生した際にはいつでも確認できます。
If you want to troubleshoot post-installation errors, use the Support Bundle tool.
インストール時にサービスをトラブルシューティングする方法
クラスター サーバー ノードの 1 つで次の手順を実行します。
- Kubernetes へのアクセス権を取得します。
on server nodes:
export KUBECONFIG="/etc/rancher/rke2/rke2.yaml"
export PATH="$PATH:/usr/local/bin:/var/lib/rancher/rke2/bin"
on agent nodes:
export KUBECONFIG="/var/lib/rancher/rke2/agent/kubelet.kubeconfig"
export PATH="$PATH:/usr/local/bin:/var/lib/rancher/rke2/bin"
# To validate, execute the following command which should not return an error:
kubectl get nodes
- 次のコマンドを使用して、ArgoCD パスワードを取得します。
kubectl get secrets/argocd-admin-password -n argocd --template '{{ .data.password }}' | base64 -d
-
ArgoCD に接続します。
a.https://alm.<fqdn>/:443
に移動します。
b.admin
をユーザー名として使用し、手順 2 で取得したパスワードを使用してログインします。 -
次のように UiPath サービス アプリケーションを見つけます。
a. ArgoCD の検索バーで「uipath
」と入力します。
b. 次に、カードをクリックして UiPath アプリケーションを開きます。
c. 次のエラーを確認します。
Application was not synced due to a failed job/pod
d. 上記のエラーが存在する場合は、以下の手順を実行します。
e. 赤いひびの入ったハート型のアイコンを探して、同期されていないコンポーネントを見つけます (下図を参照)。
f. 右端のコンポーネント (通常はポッド) を開いて、[ログ] タブをクリックします。[ログ] には、ポッド障害の原因を示すエラー メッセージが含まれます。
g. 未解決の設定の問題を解決したら、ホーム ページに戻り、UiPath アプリケーションの [同期] ボタンをクリックします。
クラスターをアンインストールする方法
クラスターで実行されている Kubernetes に固有の問題が発生した場合は、rke2 クラスターを直接アンインストールできます。
- インストール プロファイルに応じて、次のいずれかのコマンドを実行します。
1.1.オンライン設定では、次のスクリプトをクラスターの各ノードで管理者特権 (つまり、sudo
) で実行します。これによりノードがアンインストールされます。
function remove_rke2_entry_from_exclude() {
local current_exclude_list new_exclude_list
YUM_CONF_FILE=$1
if [[ ! -s "${YUM_CONF_FILE}" ]];
then
# File is empty
return
fi
current_exclude_list=$(grep 'exclude=' "${YUM_CONF_FILE}" | tail -1)
if echo "$current_exclude_list" | grep -q 'rke2-*';
then
if [[ -w ${YUM_CONF_FILE} ]];
then
new_exclude_list=$(printf '%s\n' "${current_exclude_list//rke2-* /}")
new_exclude_list=$(printf '%s\n' "${new_exclude_list//rke2-*,/}")
new_exclude_list=$(printf '%s\n' "${new_exclude_list//rke2-\*/}")
sed -i "/exclude=.*rke2-\*/d" "${YUM_CONF_FILE}"
echo "${new_exclude_list}" >> "${YUM_CONF_FILE}"
else
error "${YUM_CONF_FILE} file is readonly and contains rke2-* under package exclusion. Please remove the entry for AS to work."
fi
fi
}
function enable_rke2_package_upgrade() {
remove_rke2_entry_from_exclude /etc/dnf/dnf.conf
remove_rke2_entry_from_exclude /etc/yum.conf
}
enable_rke2_package_upgrade
service_exists() {
local n=$1
if [[ $(systemctl list-units --all -t service --full --no-legend "$n.service" | cut -f1 -d' ') == $n.service ]]; then
return 0
else
return 1
fi
}
if service_exists rke2-server; then
systemctl stop rke2-server
systemctl disable rke2-server
fi
if service_exists rke2-agent; then
systemctl stop rke2-agent
systemctl disable rke2-agent
fi
if [ -e /usr/bin/rke2-killall.sh ]
then
echo "Running rke2-killall.sh"
/usr/bin/rke2-killall.sh > /dev/null
else
echo "File not found: rke2-killall.sh"
fi
if [ -e /usr/bin/rke2-uninstall.sh ]
then
echo "Running rke2-uninstall.sh"
/usr/bin/rke2-uninstall.sh > /dev/null
else
echo "File not found: rke2-uninstall.sh"
fi
crontab -l > backupcron
sed -i '/backupjob/d' backupcron > /dev/null
crontab backupcron > /dev/null
rm -rf backupcron > /dev/null
rm -rfv /usr/bin/backupjob > /dev/null
rm -rfv /etc/rancher/ > /dev/null
rm -rfv /var/lib/rook/ > /dev/null
rm -rfv /var/lib/longhorn/ > /dev/null
rm -rfv /var/lib/rancher/rke2/server/db/* > /dev/null
umount -l -f /var/lib/rancher/rke2/server/db > /dev/null 2>&1 || true
rm -rfv /var/lib/rancher/* > /dev/null
umount -l -f /var/lib/rancher
rm -rfv /var/lib/rancher/* > /dev/null
while ! rm -rfv /var/lib/kubelet/* > /dev/null; do
findmnt --list --submounts -n -o TARGET --target /var/lib/kubelet | grep '/var/lib/kubelet/plugins' | xargs -r umount -f -l
sleep 5
done
umount -l -f /var/lib/kubelet
rm -rfv /var/lib/kubelet/* > /dev/null
rm -rfv /datadisk/* > /dev/null
umount -l -f /datadisk
rm -rfv /datadisk/* > /dev/null
rm -rfv ~/.uipath/* > /dev/null
mount /var/lib/rancher
mkdir -p /var/lib/rancher/rke2/server/db/ && mount -a
rm -rfv /var/lib/rancher/rke2/server/db/* > /dev/null
echo "Uninstall RKE complete."
1.2 オフライン設定では、次のスクリプトをクラスターの各ノードで管理者特権 (つまり、sudo
) で実行します。これによりノードがアンインストールされます。
function remove_rke2_entry_from_exclude() {
local current_exclude_list new_exclude_list
YUM_CONF_FILE=$1
if [[ ! -s "${YUM_CONF_FILE}" ]];
then
# File is empty
return
fi
current_exclude_list=$(grep 'exclude=' "${YUM_CONF_FILE}" | tail -1)
if echo "$current_exclude_list" | grep -q 'rke2-*';
then
if [[ -w ${YUM_CONF_FILE} ]];
then
new_exclude_list=$(printf '%s\n' "${current_exclude_list//rke2-* /}")
new_exclude_list=$(printf '%s\n' "${new_exclude_list//rke2-*,/}")
new_exclude_list=$(printf '%s\n' "${new_exclude_list//rke2-\*/}")
sed -i "/exclude=.*rke2-\*/d" "${YUM_CONF_FILE}"
echo "${new_exclude_list}" >> "${YUM_CONF_FILE}"
else
error "${YUM_CONF_FILE} file is readonly and contains rke2-* under package exclusion. Please remove the entry for AS to work."
fi
fi
}
function enable_rke2_package_upgrade() {
remove_rke2_entry_from_exclude /etc/dnf/dnf.conf
remove_rke2_entry_from_exclude /etc/yum.conf
}
enable_rke2_package_upgrade
service_exists() {
local n=$1
if [[ $(systemctl list-units --all -t service --full --no-legend "$n.service" | cut -f1 -d' ') == $n.service ]]; then
return 0
else
return 1
fi
}
if service_exists rke2-server; then
systemctl stop rke2-server
systemctl disable rke2-server
fi
if service_exists rke2-agent; then
systemctl stop rke2-agent
systemctl disable rke2-agent
fi
if [ -e /usr/local/bin/rke2-killall.sh ]
then
echo "Running rke2-killall.sh"
/usr/local/bin/rke2-killall.sh > /dev/null
else
echo "File not found: rke2-killall.sh"
fi
if [ -e /usr/local/bin/rke2-uninstall.sh ]
then
echo "Running rke2-uninstall.sh"
/usr/local/bin/rke2-uninstall.sh > /dev/null
else
echo "File not found: rke2-uninstall.sh"
fi
crontab -l > backupcron
sed -i '/backupjob/d' backupcron > /dev/null
crontab backupcron > /dev/null
rm -rf backupcron > /dev/null
rm -rfv /usr/bin/backupjob > /dev/null
rm -rfv /etc/rancher/ > /dev/null
rm -rfv /var/lib/rook/ > /dev/null
rm -rfv /var/lib/longhorn/ > /dev/null
rm -rfv /var/lib/rancher/rke2/server/db/* > /dev/null
umount -l -f /var/lib/rancher/rke2/server/db > /dev/null 2>&1 || true
rm -rfv /var/lib/rancher/* > /dev/null
umount -l -f /var/lib/rancher
rm -rfv /var/lib/rancher/* > /dev/null
while ! rm -rfv /var/lib/kubelet/* > /dev/null; do
findmnt --list --submounts -n -o TARGET --target /var/lib/kubelet | grep '/var/lib/kubelet/plugins' | xargs -r umount -f -l
sleep 5
done
umount -l -f /var/lib/kubelet
rm -rfv /var/lib/kubelet/* > /dev/null
rm -rfv /datadisk/* > /dev/null
umount -l -f /datadisk
rm -rfv /datadisk/* > /dev/null
rm -rfv ~/.uipath/* > /dev/null
mount /var/lib/rancher
mkdir -p /var/lib/rancher/rke2/server/db/ && mount -a
rm -rfv /var/lib/rancher/rke2/server/db/* > /dev/null
echo "Uninstall RKE complete."
- Clean up the OSD disk:
for osddisk in $(find /dev/uipath/ceph -maxdepth 1 -mindepth 1 -type l); do
devName=$(basename "${osddisk}")
devPath="/dev/${devName}"
sgdisk --zap-all "${devPath}"
dd if=/dev/zero of="${devPath}" bs=1M count=100 oflag=direct,dsync
blkdiscard "${devPath}"
done
ls /dev/mapper/ceph-* | xargs -I% -- dmsetup remove %
rm -rf /dev/ceph-*
rm -rf /etc/udev/rules.d/99-ceph-raw-osd.rules
3, Reboot the node after uninstall.
重要
ノードの 1 つをクラスターからアンインストールする場合は、
kubectl delete node <node_name>
コマンドを実行する必要があります。これにより、クラスターからノードが削除されます。
オフライン成果物をクリーンアップしてディスク領域を改善する方法
オフライン インストールを実行する場合、一般に、使用されるオフライン成果物により、大きなディスク サイズが必要になります。
インストールが完了したら、これらのローカル成果物を削除できます。削除できなかった場合、クラスター操作時に不要なディスク容量の圧迫が発生する可能性があります。
次のコマンドを使用して、インストールが実行されたプライマリ サーバーでクリーンアップを実行できます。
- 次のコマンドを使用して、podman によってローカル コンテナー ストレージに読み込まれたすべてのイメージを削除します。
podman image rm -af
- 次に、フラグ
--offline-tmp-folder
で使用された一時オフライン フォルダーを削除します。このパラメーターの既定値は/tmp
です。
rm -rf /path/to/temp/folder
一般的な問題
RHEL 8.4 OS でオフライン インストールを実行できない
説明
RHEL 8.4 をインストールして、podman を必要とするオフライン インストールを実行する場合、次の問題が発生する可能性があります。これらの問題は、podman および一緒にインストールされる OS に固有の問題です。以下の 2 つを参照してください。
潜在的な問題
- クラスターに以下の両方をインストールすることはできない
podman-1.0.0-8.git921f98f.module+el8.3.0+10171+12421f43.x86_64
podman-3.0.1-6.module+el8.4.0+10607+f4da7515.x86_64
- パッケージ
cockpit-podman-29-2.module+el8.4.0+10607+f4da7515.noarch
にはpodman
>=1.3.0
が必要であるが、どのプロバイダーもインストールできない - ジョブの最適な候補をインストールできない
- インストール済みパッケージ
cockpit-podman-29-2.module+el8.4.0+10607+f4da7515.noarch
に関する問題
潜在的な問題
- パッケージ
podman-3.0.1-6.module+el8.4.0+10607+f4da7515.x86_64
にはcontainernetworking-plugins
>=0.8.1-1
が必要であるが、どのプロバイダーもインストールできない - 以下の両方をインストールすることはできない
containernetworking-plugins-0.7.4-4.git9ebe139.module+el8.3.0+10171+12421f43.x86_64
containernetworking-plugins-0.9.1-1.module+el8.4.0+10607+f4da7515.x86_64
- パッケージ
podman-catatonit-3.0.1-6.module+el8.4.0+10607+f4da7515.x86_64
にはpodman
=3.0.1-6.module+el8.4.0+10607+f4da7515
が必要であるが、どのプロバイダーもインストールできない - ジョブの最適な候補をインストールできない
- インストール済みパッケージ
podman-catatonit-3.0.1-6.module+el8.4.0+10607+f4da7515.x86_64
に関する問題
(コマンド ラインに--allowerasing
を追加して競合するパッケージを置き換えるか、--skip-broken
を追加してアンインストール可能なパッケージをスキップするか、--nobest
を追加して最適な候補パッケージ以外を使用します)
解決策
podman
の現在のバージョンを削除して、Automation Suite が必要なバージョンをインストールできるようにする必要があります。
-
yum remove podman
コマンドを使用して、podman の現在のバージョンを削除します。 -
現在のバージョンを削除した後、インストーラーを再実行すると、正しいバージョンがインストールされます。
バイナリがないため、オフライン インストールが失敗する
説明
オフライン インストール時に、ファブリック ステージで、次のエラー メッセージが表示されて実行が失敗します。
Error: overlay: can't stat program "/usr/bin/fuse-overlayfs": stat /usr/bin/fuse-overlayfs: no such file or directory
解決策
podman
設定 /etc/containers/storage.conf
から、mount_program
キーを含む行を削除する必要があります。
コメント アウトするのではなく、行を削除してください。
サンドボックス イメージを取得できない
説明
次のサンドボックス イメージを取得しようとすると、特定のエラー メッセージが表示されることがあります。index.docker.io/rancher/pause3.2
これは、オフライン インストールで発生します。
解決策
rke2-server
または rke2-agent
(ポッドがスケジュールされているマシンがサーバーかエージェントかによって異なります) を再起動します。
ポッドがスケジュールされているノードを確認するには、kubectl -n <namespace> get pods -o wide
を実行します。
# If machine is a Master node
systemctl restart rke2-server
# If machine is an Agent Node
systemctl restart rke2-agent
SQL 接続文字列の検証エラー
説明
次のような、接続文字列に関連するエラーが表示されることがあります。
Sqlcmd: Error: Microsoft Driver 17 for SQL Server :
Server—tcp : <connection string>
Login failed for user
このエラーは、すべての資格情報が正しい場合でも表示されます。接続文字列の検証に失敗しました。
解決策
接続文字列が次の構造を持つことを確認します。
Server=<Sql server host name>;User Id=<user_name for sql server>;Password=<Password>;Initial Catalog=<database name>;Persist Security Info=False;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;Max Pool Size=100;
注:
User Id
は大文字と小文字を区別します。
ポッドが ArgoCD UI に表示されない
説明
ArgoCD UI にポッドが表示されず、アプリケーションおよび対応するデプロイのみが表示されることがあります。詳しくは、次の画像をご覧ください。

いずれかのデプロイをクリックすると、Unable to load data: EOF
というエラーが表示されます。

解決策
この問題を修正するには、ArgoCD 名前空間からすべての Redis レプリカを削除して、再び戻ってくるのを待ちます。
kubectl -n argocd delete pod argocd-redis-ha-server-0 argocd-redis-ha-server-1 argocd-redis-ha-server-2
# Wait for all 3 pods to come back up
kubectl -n argocd get pods | grep argocd-redis-ha-server
オフライン インストールでの証明書の問題
説明
証明書が不明な機関によって署名されているというエラーが表示されることがあります。
Error: failed to do request: Head "https://sfdev1778654-9f843b23-lb.westeurope.cloudapp.azure.com:30071/v2/helm/audit-service/blobs/sha256:09bffbc520ff000b834fe1a654acd089889b09d22d5cf1129b0edf2d76554892": x509: certificate signed by unknown authority
解決策
rootCA とサーバー証明書の両方が、マシンの信頼されたストアに格納されている必要があります。
調べるには、次のコマンドを実行します。
[root@server0 ~]# find /etc/pki/ca-trust/source{,/anchors} -maxdepth 1 -not -type d -exec ls -1 {} +
/etc/pki/ca-trust/source/anchors/rootCA.crt
/etc/pki/ca-trust/source/anchors/server.crt
指定した証明書が、これらのコマンドの出力に含まれている必要があります。
または、次のコマンドを実行します。
[root@server0 ~]# openssl x509 -in /etc/pki/ca-trust/source/anchors/server.crt -text -noout
出力のサブジェクトの別名に完全修飾ドメイン名があることを確認します。
X509v3 Subject Alternative Name:
DNS:sfdev1778654-9f843b23-lb.westeurope.cloudapp.azure.com
次のように CA 証明書を更新できます。
[root@server0 ~]# update-ca-trust
バンドルのダウンロード中のエラー
説明
ドキュメントに、バンドルをダウンロードするオプションとして wget
が表示されています。サイズが大きいため、接続が中断され、回復しない可能性があります。
解決策
One way to mitigate this could be to switch to a different download tool, such as azcopy
(more information here). Run these commands, while updating the bundle URL to match the desired version/bundle combination.
wget https://aka.ms/downloadazcopy-v10-linux -O azcopy.tar.gz
tar -xvf ./azcopy.tar.gz
azcopy_linux_amd64_10.11.0/azcopy copy https://download.uipath.com/service-fabric/0.0.23-private4/sf-0.0.23-private4.tar.gz /var/tmp/sf.tar.gz --from-to BlobLocal
Longhorn エラー
Rook Ceph または Looker ポッドが Init ステートでスタックする
説明
ポッドに PVC をアタッチするのに必要なボリュームがないために、ノードの再起動時に問題が発生すると、Looker または Rook Ceph ポッドが Init ステートでスタックすることがあります。
次のコマンドを実行して、問題が本当に Longhorn に関連しているかを確認します。
kubectl get events -A -o json | jq -r '.items[] | select(.message != null) | select(.message | contains("cannot get resource \"volumeattachments\" in API group \"storage.k8s.io\""))'
Longhorn に関連している場合、このコマンドは問題の影響を受けるポッド名のリストを返します。コマンドから何も返されない場合、問題の原因は別にあります。
解決策
前のコマンドから空でない出力が返された場合は、次のスクリプトを実行して、問題のあるポッドを修正します。
#!/bin/bash
function wait_till_rollout() {
local namespace=$1
local object_type=$2
local deploy=$3
local try=0
local maxtry=2
local status="notready"
while [[ ${status} == "notready" ]] && (( try != maxtry )) ; do
kubectl -n "$namespace" rollout status "$deploy" -w --timeout=600s;
# shellcheck disable=SC2181
if [[ "$?" -ne 0 ]];
then
status="notready"
try=$((try+1))
else
status="ready"
fi
done
if [[ $status == "notready" ]]; then
echo "$deploy of type $object_type failed in namespace $namespace. Plz re-run the script once again to verify that it's not a transient issue !!!"
exit 1
fi
}
function fix_pv_deployments() {
for pod_name in $(kubectl get events -A -o json | jq -r '.items[] | select(.message | contains("cannot get resource \"volumeattachments\" in API group \"storage.k8s.io\"")) | select(.involvedObject.kind == "Pod") | .involvedObject.name + "/" + .involvedObject.namespace' | sort | uniq)
do
POD_NAME=$(echo "${pod_name}" | cut -d '/' -f1)
NS=$(echo "${pod_name}" | cut -d '/' -f2)
controller_data=$(kubectl -n "${NS}" get po "${POD_NAME}" -o json | jq -r '[.metadata.ownerReferences[] | select(.controller==true)][0] | .kind + "=" + .name')
[[ $controller_data == "" ]] && error "Error: Could not determine owner for pod: ${POD_NAME}" && exit 1
CONTROLLER_KIND=$(echo "${controller_data}" | cut -d'=' -f1)
CONTROLLER_NAME=$(echo "${controller_data}" | cut -d'=' -f2)
if [[ $CONTROLLER_KIND == "ReplicaSet" ]]
then
controller_data=$(kubectl -n "${NS}" get "${CONTROLLER_KIND}" "${CONTROLLER_NAME}" -o json | jq -r '[.metadata.ownerReferences[] | select(.controller==true)][0] | .kind + "=" + .name')
CONTROLLER_KIND=$(echo "${controller_data}" | cut -d'=' -f1)
CONTROLLER_NAME=$(echo "${controller_data}" | cut -d'=' -f2)
replicas=$(kubectl -n "${NS}" get "$CONTROLLER_KIND" "$CONTROLLER_NAME" -o json | jq -r '.status.replicas')
unavailable_replicas=$(kubectl -n "${NS}" get "$CONTROLLER_KIND" "$CONTROLLER_NAME" -o json | jq -r '.status.unavailableReplicas')
if [ -n "$unavailable_replicas" ]; then
available_replicas=$((replicas - unavailable_replicas))
if [ $available_replicas -eq 0 ]; then
kubectl -n "$NS" scale "$CONTROLLER_KIND" "$CONTROLLER_NAME" --replicas=0
sleep 15
kubectl -n "$NS" scale "$CONTROLLER_KIND" "$CONTROLLER_NAME" --replicas="$replicas"
deployment_name="$CONTROLLER_KIND/$CONTROLLER_NAME"
wait_till_rollout "$NS" "deploy" "$deployment_name"
fi
fi
fi
done
}
fix_pv_deployments
StatefulSet ボリューム アタッチ エラー
RabbitMQ または cattle-monitoring-system 内のポッドや、その他の StatefulSet ポッドが init ステートでスタックしています。
説明
ノードの電源障害時やアップグレード時に問題が発生すると、ポッドに PVC をアタッチするのに必要なボリュームがないために、RabbitMQ または cattle-monitoring-system 内のポッドが init ステートでスタックすることがあります。
次のコマンドを実行して、問題が本当に StatefulSet ボリュームのアタッチに関連しているかを確認します。
kubectl -n <namespace> describe pod <pod-name> | grep "cannot get resource \"volumeattachments\" in API group \" storage.k8s.io\""
StatefulSet ボリュームのアタッチに関連している場合、エラー メッセージが表示されます。
解決策
この問題を修正するには、ノードを再起動します。
永続ボリュームを作成できない
説明
Longhorn は正常にインストールされますが、永続ボリュームを作成できません。
解決策
コマンド lsmod | grep <module_name>
を使用して、カーネル モジュールがクラスターに正常に読み込まれているかどうかを確認します。
<module_name>
を以下の各カーネル モジュールに置き換えます。
libiscsi_tcp
libiscsi
iscsi_tcp
scsi_transport_iscsi
欠落しているモジュールを読み込みます。
rke2-coredns-rke2-coredns-autoscaler ポッドが CrashLoopBackOff になる
説明
ノードの再起動後に、rke2-coredns-rke2-coredns-autoscaler が CrashLoopBackOff になることがあります。このことは、Automation Suite に影響しません。
解決策
次のコマンドを使用して、CrashLoopBackOff
になっている rke2-coredns-rke2-coredns-autoscaler ポッドを削除します。kubectl delete pod <pod name> -n kube-system
Redis プローブの障害
説明
ノード ID ファイルが存在しない場合、Redis プローブは失敗することがあります。これは、ポッドがまだブートストラップされていない場合に発生する可能性があります。
この問題を自動的に修正するリカバリー ジョブがあります。このジョブの実行時には、以下の手順を実行しないでください。
Redis Enterprise クラスターが半数以上のノードとの接続を失うと (ノードのエラーまたはネットワーク分断により)、クラスターはクライアント接続への応答を停止します。ポッドも、クラスターへの再参加に失敗します。
解決策
- 次のコマンドを使用して、Redis クラスターとデータベースを削除します。
kubectl delete redb -n redis-system redis-cluster-db --force --grace-period=0 &
kubectl delete rec -n redis-system redis-cluster --force --grace-period=0 &
kubectl patch redb -n redis-system redis-cluster-db --type=json -p '[{"op":"remove","path":"/metadata/finalizers","value":"finalizer.redisenterprisedatabases.app.redislabs.com"}]'
kubectl patch rec redis-cluster -n redis-system --type=json -p '[{"op":"remove","path":"/metadata/finalizers","value":"redbfinalizer.redisenterpriseclusters.app.redislabs.com"}]'
kubectl delete job redis-cluster-db-job -n redis-system
- ArgoCD UI に移動して、redis-cluster アプリケーションを同期します。
RKE2 サーバーの起動に失敗する
説明
サーバーを起動できません。RKE2 が適切に起動しない理由は複数あり、通常はログで確認できます。
解決策
次のコマンドを使用してログを確認します。
journalctl -u rke2-server
考えられる理由 (ログに基づく): クラスター内のラーナー メンバーの数が多すぎる。
Too many etcd servers are added to the cluster, and there are two learner nodes trying to be promoted. More information here: Runtime reconfiguration.
次の手順を実行します。
- 通常の状況では、十分に時間がある場合、ノードはフル メンバーになるはずです。
- アンインストール/再インストールのサイクルを試行できます。
Alternatively, this could be caused by a networking problem. Ensure you have configured the machine to enable the necessary ports.
停止されたノードに対してノードのドレインが行われない
説明
クラスター内でノードが停止し、15 分後に対応するポッドが利用可能なノードに再スケジュールされない場合は、次のスクリプトを実行して手動でノードのドレインを行います。
#!/bin/sh
KUBECTL="/usr/local/bin/kubectl"
# Get only nodes which are not drained yet
NOT_READY_NODES=$($KUBECTL get nodes | grep -P 'NotReady(?!,SchedulingDisabled)' | awk '{print $1}' | xargs echo)
# Get only nodes which are still drained
READY_NODES=$($KUBECTL get nodes | grep '\sReady,SchedulingDisabled' | awk '{print $1}' | xargs echo)
echo "Unready nodes that are undrained: $NOT_READY_NODES"
echo "Ready nodes: $READY_NODES"
for node in $NOT_READY_NODES; do
echo "Node $node not drained yet, draining..."
$KUBECTL drain --ignore-daemonsets --force --delete-emptydir-data $node
echo "Done"
done;
for node in $READY_NODES; do
echo "Node $node still drained, uncordoning..."
$KUBECTL uncordon $node
echo "Done"
done;
Istio ログを有効化する
Istio をデバッグするには、ログを有効化する必要があります。そのためには、以下の手順を実行します。
- 次のコマンドを実行して、
istio-ingressgateway
ポッドを見つけます。ゲートウェイ ポッド名をコピーします。istio-ingressgateway-r4mbx
のようになります。
kubectl -n istio-system get pods
- 次のコマンドを実行して、ゲートウェイ ポッド シェルを開きます。
kubectl exec -it -n istio-system istio-ingressgateway-r4mbx bash
- 次のコマンドを実行して、デバッグ レベルのログを有効化します。
curl -X POST http://localhost:15000/logging?level=debug
- サーバー ノードから次のコマンドを実行します。
istioctl_bin=$(find /var/lib/rancher/rke2/ -name "istioctl" -type f -perm -u+x -print -quit)
if [[ -n ${istioctl_bin} ]]
then
echo "istioctl bin found"
kubectl -n istio-system get cm istio-installer-base -o go-template='{{ index .data "istio-base.yaml" }}' > istio-base.yaml
kubectl -n istio-system get cm istio-installer-overlay -o go-template='{{ index .data "overlay-config.yaml" }}' > overlay-config.yaml
${istioctl_bin} -i istio-system install -y -f istio-base.yaml -f overlay-config.yaml --set meshConfig.accessLogFile=/dev/stdout --set meshConfig.accessLogEncoding=JSON
else
echo "istioctl bin not found"
fi
UiPath 名前空間でシークレットが見つからない
説明
サービスのインストールに失敗し、kubectl -n uipath get pods
のチェックで失敗したポッドが返された場合は、以下の手順を実行します。
解決策
kubectl -n uipath describe pod <pod-name>
を確認して、見つからないシークレットを探します。- シークレットが見つからない場合は、資格情報マネージャー ジョブのログを探して、失敗したかどうかを確認します。
- 資格情報マネージャー ジョブが失敗し、
kubectl get pods -n rook-ceph|grep rook-ceph-tool
が複数のポッドを返す場合は、次の操作を実行します。
a. 実行されていないrook-ceph-tool
を削除します。
b. ArgoCD UI に移動して、sfcore
アプリケーションを同期します。
c. ジョブが完了したら、資格情報マネージャー ジョブのログですべてのシークレットが作成されているかどうかを確認します。
d.uipath
アプリケーションを同期します。
移行後にログインできない
説明
この問題は、スタンドアロン製品から Automation Suite への移行に影響することがあります。次のエラー メッセージが表示され、ログインできなくなります。Cannot find client details
解決策
この問題を修正するには、まず uipath
アプリを再同期してから、ArgoCD で platform
アプリを同期する必要があります。
ArgoCD へのログインに失敗した
説明
管理者パスワードを使用している場合に ArgoCD へのログイン、またはインストーラーが失敗することがあります。次のエラー メッセージが表示されます。

解決策
この問題を修正するには、パスワードを入力し、bcrypt のパスワードを作成して、次のセクションで説明するコマンドを実行します。
password="<enter_your_password>"
bcryptPassword=<generate bcrypt password using link https://www.browserling.com/tools/bcrypt >
# Enter your bcrypt password and run below command
kubectl -n argocd patch secret argocd-secret \
-p '{"stringData": {
"admin.password": "<enter you bcryptPassword here>",
"admin.passwordMtime": "'$(date +%FT%T%Z)'"
}}'
# Run below commands
argocdInitialAdminSecretPresent=$(kubectl -n argocd get secret argocd-initial-admin-secret --ignore-not-found )
if [[ -n ${argocdInitialAdminSecretPresent} ]]; then
echo "Start updating argocd-initial-admin-secret"
kubectl -n argocd patch secret argocd-initial-admin-secret \
-p "{
\"stringData\": {
\"password\": \"$password\"
}
}"
fi
argocAdminSecretName=$(kubectl -n argocd get secret argocd-admin-password --ignore-not-found )
if [[ -n ${argocAdminSecretName} ]]; then
echo "Start updating argocd-admin-password"
kubectl -n argocd patch secret argocd-admin-password \
-p "{
\"stringData\": {
\"password\": \"$password\"
}
}"
fi
初期インストール後、ArgoCD アプリが Progressing ステートになる
説明
クラスターのステートが helm リポジトリで定義されているステートから逸脱している場合、 argocd
はステートを同期しようとし、毎分照合が行われます。この問題が発生すると、ArgoCD アプリは Progressing ステートになります。
解決策
これは、ArgoCD の予期される動作であり、アプリケーションには一切影響しません。
Automation Suite で backlog_wait_time
を 1 に設定する必要がある
backlog_wait_time
を 1 に設定する必要がある説明
backlog_wait_time
が 1
に設定されていない場合、監査イベントにより、不安定性 (システムのフリーズ) が生じることがあります。
For more details, see this issue description.
解決策
Automation Suite requires backlog_wait_time to be set 1
エラー メッセージが表示されてインストーラーが失敗した場合は、次の手順を実行して backlog_wait_time
を 1
に設定します。
/etc/audit/rules.d/audit.rules
ファイルに--backlog_wait_time 1
を追加して、backlog_wait_time
を1
に設定します。- ノードを再起動します。
- ノードで
sudo auditctl -s | grep "backlog_wait_time"
を実行して、auditctl
のbacklog_wait_time
値が1
に設定されているかどうかを確認します。
ObjectStore PVC のサイズを変更できない
説明
この問題は、次のエラー メッセージが表示されて objectstore resize-pvc
操作が失敗した場合に発生します。
Failed resizing the PVC: <pvc name> in namespace: rook-ceph, ROLLING BACK
解決策
この問題を修正するには、次の手順に従います。
- 次のスクリプトを手動で実行します。
#!/bin/sh
ROOK_CEPH_OSD_PREPARE=$(kubectl -n rook-ceph get pods | grep rook-ceph-osd-prepare-set | awk '{print $1}')
if [[ -n ${ROOK_CEPH_OSD_PREPARE} ]]; then
for pod in ${ROOK_CEPH_OSD_PREPARE}; do
echo "Start deleting rook ceph osd pod $pod .."
kubectl -n rook-ceph delete pod $pod
echo "Done"
done;
fi
objectstore resize-pvc
コマンドを再実行します。
PVC resize does not heal Ceph
説明
If Ceph is unhealthy due to out-of-storage issues, Objectstore PVC resize does not heal it.
解決策
To speed up the Ceph recovery in a non-HA cluster, run the following command:
function set_ceph_pool_config_non_ha() {
# Return if HA
[[ "$(kubectl -n rook-ceph get cephobjectstore rook-ceph -o jsonpath='{.spec.dataPool.replicated.size}')" -eq 1 ]] || return
# Set pool size and min_size
kubectl -n "rook-ceph" exec deploy/rook-ceph-tools – ceph osd pool set "device_health_metrics" "size" "1" --yes-i-really-mean-it || true
kubectl -n "rook-ceph" exec deploy/rook-ceph-tools – ceph osd pool set "device_health_metrics" "min_size" "1" --yes-i-really-mean-it || true
}
object-store (rook-ceph) にデータをアップロード/ダウンロードできない

説明
この問題は、配置グループ (PG) の不整合のために、object-store のステートが degraded ステートになっている場合に発生する可能性があります。
次のコマンドを実行して、問題が本当に rook-ceph の PG の不整合に関連しているかを確認します。
export KUBECONFIG=/etc/rancher/rke2/rke2.yaml PATH=$PATH:/var/lib/rancher/rke2/bin
ROOK_CEPH_TOOLS=$(kubectl -n rook-ceph get pods | grep rook-ceph-tools)
kubectl -n rook-ceph exec -it $ROOK_CEPH_TOOLS -- ceph status
問題が rook-ceph の PG の不整合に関連している場合は、出力に次のメッセージが含まれます。

....
....
Possible data damage: X pgs inconsistent
....
....
X active+clean+inconsistent
....
....
解決策
不整合な PG を修復するには、次の手順を実行します。
- rook-ceph ツールを実行します。
kubectl -n rook-ceph exec -it $ROOK_CEPH_TOOLS -- sh
- rook-ceph のガベージ コレクター プロセスをトリガーします。プロセスが完了するまで待ちます。
radosgw-admin gc process
active+clean+inconsistent
PG のリストを見つけます。
ceph health detail
# output of this command be like
# ....
# pg <pg-id> is active+clean+inconsistent, acting ..
# pg <pg-id> is active+clean+inconsistent, acting ..
# ....
#
- 詳細スクラブを一度に 1 つの PG でトリガーします。PG のサイズによっては、このコマンドの実行に数分かかります。
ceph pg deep-scrub <pg-id>
- スクラブのステータスを確認します。
ceph -w | grep <pg-id>
- PG のスクラブのステータスを確認します。PG のスクラブに成功すると、PG のステータスは
active+clean+inconsistent
になります。
ceph health detail | grep <pg-id>
- PG を修復します。
ceph pg repair <pg-id>
- PG の修復ステータスを確認します。PG が正常に修復された場合、その PG の ID は
active+clean+inconsistent
リストから削除されます。
ceph health detail | grep <pg-id>
- 残りの不整合な PG で手順 3 から 8 を繰り返します。
証明書の更新後のエラー
説明
この問題は、証明書の更新手順が内部で失敗した場合に発生します。Automation Suite または Orchestrator にアクセスできないことがあります。
Error

解決策
- 任意のサーバー ノードから、以下のコマンドを実行します。
export KUBECONFIG=/etc/rancher/rke2/rke2.yaml
export PATH=$PATH:/var/lib/rancher/rke2/bin
kubectl -n uipath rollout restart deployments
- 上記のコマンドが成功するまで待機してから、以下のコマンドを実行して前のコマンドのステータスを確認します。
deployments=$(kubectl -n uipath get deployment -o name)
for i in $deployments;
do
kubectl -n uipath rollout status "$i" -w --timeout=600s;
if [[ "$?" -ne 0 ]];
then
echo "$i deployment failed in namespace uipath."
fi
done
echo "All deployments are succeeded in namespace uipath"
上記のコマンドの実行が完了したら、Automation Suite や Orchestrator にアクセスできます。
Unexpected inconsistency; run fsck manually
Automation Suite のインストールまたはアップグレード中にポッドが PVC ポッドにマウントできない場合、次のエラー メッセージが表示されます。
UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY

回復の手順
上記のエラーが発生する場合は、次の回復手順に従います。
- 次のコマンドを実行して、システムに SSH 接続します。
ssh <user>@<node-ip>
- PVC のイベントをチェックし、この問題がファイル エラーによる PVC のマウント エラーに関連していることを確認します。このためには、以下のコマンドを実行します。
export KUBECONFIG=/etc/rancher/rke2/rke2.yaml PATH=$PATH:/var/lib/rancher/rke2/bin:/usr/local/bin
kubectl get events -n mongodb
kubectl get events -n longhorn-system
- イベントに示されている PVC ボリュームを確認し、
fsck
コマンドを実行します。
fsck -a <pvc-volume-name>
Eg - fsck -a /dev/longhorn/pvc-5abe3c8f-7422-44da-9132-92be5641150a
- 失敗した MongoDB ポッドを削除して、PVC に適切にマウントします。
kubectl delete pod <pod-name> -n mongodb
Mongo pods in CrashLoopBackOff or pending PVC provisioning after deletion
The Mongo pods might get stuck in a cashback loop due to a corrupt PVC. The most probable cause of this issue is an unclean shutdown.
When experiencing this issue, the logs show the following:
Common point must be at least stable timestamp
{"t":{"$date":"2022-05-18T09:37:55.053+00:00"},"s":"W", "c":"STORAGE", "id":22271, "ctx":"initandlisten","msg":"Detected unclean shutdown - Lock file is not empty","attr":{"lockFile":"/data/mongod.lock"}}
['currentState.Running' = false]
['currentState.IsVCRedistCorrect' = true]
['desiredState.ProcessType' != mongos ('desiredState.ProcessType' = mongod)]
回復の手順
- Delete the failing pod. If this solution does not work, continue to the next steps.
kubectl delete pod <pod-name> -n mongodb
- Get the name of the corrupt PVC for the failing pods.
kubectl -n mongodb get pvc
- Delete the PVC.
kubectl -n mongodb delete pvc <pvc-name>
-
At this point, the PVC should be auto-synced, and the pod should experience no issues anymore. If auto-provisioning does not happen, you need to perform the operation manually by taking the following steps.
-
Get the PVC YAML for a healthy node.
kubectl -n mongodb get pvc <pvc-name> -o yaml > pvc.yaml
- Edit the name and remove
uuids/pvc-ids
from the YAML.
- Remove the volume name and UID, and rename the PVC to the deleted PVC name.

- Apply the PVC.
kubectl -n mongodb apply pvc.yaml
- The PVC should be provisioned and attached to the PVC for the pod, and the pod should no longer experience any issues. If the pod does not resync, then delete it.
MongoDB pod fails to upgrade from 4.4.4-ent to 5.0.7-ent
説明
When upgrading from Automation Suite 2021.10 to 2022.10, the MongoDB pod is stuck is rolling update and cannot move from version 4.4.4-ent to 5.0.7-ent. Only one pod is available, and it is failing the readiness check.
解決策
To check the MongoDB Agent logs, run the following command:
kubectl get pods -n mongodb
Use the pod name and get log for that pod
kubectl logs <pod-name> -n mongodb -c mongodb-agent
In the Agent logs if we are seeing below line then the upgrade hasn't been successful
['currentState.Version = 4.4.4-ent is equal to desiredState.Version = 5.0.7-ent' = false]
To fix the issue, take the following steps:
-
Disable auto-sync in ArgoCD. Go to Applications > MongoDB > AppDetails > Summary, and click Disable Auto-Sync.
-
The MongoDB sts definition is still using the old MongoDB
localhost:30071/mongodb/mongodb-enterprise-appdb-database:4.4.4-ent
image. Edit the definition to use version 5.0.7-ent. Save it and sync it. -
Delete the old MongoDB pod.
-
The pods should come up with MongoDB version 5.0.7-ent.
Upgrade fails due to unhealthy Ceph
説明
When trying to upgrade to a new Automation Suite version, you might see the following error message: Ceph objectstore is not completely healthy at the moment. Inner exception - Timeout waiting for all PGs to become active+clean
.
解決策
To fix this upgrade issue, verify if the OSD pods are running and healthy by running the following command:
kubectl -n rook-ceph get pod -l app=rook-ceph-osd --no-headers | grep -P '([0-9])/\1' -v
- If the command does not output any pods, verify if Ceph placement groups (PGs) are recovering or not by running the following command:
function is_ceph_pg_active_clean() {
local return_code=1
if kubectl -n rook-ceph exec deploy/rook-ceph-tools -- ceph status --format json | jq '. as $root | ($root | .pgmap.num_pgs) as $total_pgs | try ( ($root | .pgmap.pgs_by_state[] | select(.state_name == "active+clean").count) // 0) as $active_pgs | if $total_pgs == $active_pgs then true else false end' | grep -q 'true';then
return_code=0
fi
[[ $return_code -eq 0 ]] && echo "All Ceph Placement groups(PG) are active+clean"
if [[ $return_code -ne 0 ]]; then
echo "All Ceph Placement groups(PG) are not active+clean. Please wait for PGs to become active+clean"
kubectl -n rook-ceph exec deploy/rook-ceph-tools -- ceph pg dump --format json | jq -r '.pg_map.pg_stats[] | select(.state!="active+clean") | [.pgid, .state] | @tsv'
fi
return "${return_code}"
}
# Execute the function multiple times to get updated ceph PG status
is_ceph_pg_active_clean
If none of the affected Ceph PG recovers even after waiting for more than 30 minutes, raise a ticket with UiPath Support.
- If the command outputs pod(s), you must first fix the issue affecting them:
- If a pod is stuck in
Init:0/4
, then it could be a PV provider (Longhorn) issue. To debut this issue, raise a ticket with UiPath Support. - If a pod is in
CrashLoopBackOff
, fix the issue by running the following command:
- If a pod is stuck in
function cleanup_crashing_osd() {
local restart_operator="false"
local min_required_healthy_osd=1
local in_osd
local up_osd
local healthy_osd_pod_count
local crashed_osd_deploy
local crashed_pvc_name
if ! kubectl -n rook-ceph exec deploy/rook-ceph-tools -- ceph osd pool ls detail | grep 'rook-ceph.rgw.buckets.data' | grep -q 'replicated'; then
min_required_healthy_osd=2
fi
in_osd=$(kubectl -n rook-ceph exec deploy/rook-ceph-tools -- ceph status -f json | jq -r '.osdmap.num_in_osds')
up_osd=$(kubectl -n rook-ceph exec deploy/rook-ceph-tools -- ceph status -f json | jq -r '.osdmap.num_up_osds')
healthy_osd_pod_count=$(kubectl -n rook-ceph get pod -l app=rook-ceph-osd | grep 'Running' | grep -c -P '([0-9])/\1')
if ! [[ $in_osd -ge $min_required_healthy_osd && $up_osd -ge $min_required_healthy_osd && $healthy_osd_pod_count -ge $min_required_healthy_osd ]]; then
return
fi
for crashed_osd_deploy in $(kubectl -n rook-ceph get pod -l app=rook-ceph-osd | grep 'CrashLoopBackOff' | cut -d'-' -f'1-4') ; do
if kubectl -n rook-ceph logs "deployment/${crashed_osd_deploy}" | grep -q '/crash/'; then
echo "Found crashing OSD deployment: '${crashed_osd_deploy}'"
crashed_pvc_name=$(kubectl -n rook-ceph get deployment "${crashed_osd_deploy}" -o json | jq -r '.metadata.labels["ceph.rook.io/pvc"]')
info "Removing crashing OSD deployment: '${crashed_osd_deploy}' and PVC: '${crashed_pvc_name}'"
timeout 60 kubectl -n rook-ceph delete deployment "${crashed_osd_deploy}" || kubectl -n rook-ceph delete deployment "${crashed_osd_deploy}" --force --grace-period=0
timeout 100 kubectl -n rook-ceph delete pvc "${crashed_pvc_name}" || kubectl -n rook-ceph delete pvc "${crashed_pvc_name}" --force --grace-period=0
restart_operator="true"
fi
done
if [[ $restart_operator == "true" ]]; then
kubectl -n rook-ceph rollout restart deployment/rook-ceph-operator
fi
return 0
}
# Execute the cleanup function
cleanup_crashing_osd
After fixing the crashing OSD, verify if PGs are recovering or not by running the following command:
is_ceph_pg_active_clean
2021.10 からの自動アップグレード後にクラスターが異常になる
Automation Suite 2021.10 からの自動アップグレード中に、CNI プロバイダーが Canal から Cilium に移行されます。この操作では、すべてのノードを再起動する必要があります。まれに、1 つ以上のノードが正常に再起動されないことがあります。この場合、それらのノードで実行されているポッドが異常なままになります。
回復の手順
- 失敗した再起動を特定します。
Ansible の実行中に、次のスニペットのような出力が表示される場合があります。
TASK [Reboot the servers] ***************************************************************************************************************************
fatal: [10.0.1.6]: FAILED! =>
msg: 'Failed to connect to the host via ssh: ssh: connect to host 10.0.1.6 port 22: Connection timed out'
または、Ansible ホスト マシンのログを参照します。このログは、/var/tmp/uipathctl_<version>/_install-uipath.log
にあります。失敗した再起動を特定したら、すべてのノードで手順 2 から 4 を実行します。
- 各ノードで、再起動が必要であるかを確認します。
各ノードに接続し、次のコマンドを実行します。
ssh <username>@<ip-address>
iptables-save 2>/dev/null | grep -i cali -c
結果が 0 でない場合は、再起動が必要です。
- ノードを再起動します。
sudo reboot
- ノードが応答可能になるまで待ち (ノードに SSH で接続できる必要があります)、他のすべてのノードで手順 2 から 4 を繰り返します。
Longhorn のセットアップ中に最初のインストールが失敗する
まれに、Longhorn の最初のインストール試行に失敗した場合、後続のリトライで Helm 固有のエラー「Error: UPGRADE FAILED: longhorn has no deployed releases
」がスローされることがあります。
回復の手順
インストールをリトライする前に、次のコマンドを実行して Longhorn Helm のリリースを削除します。
/opt/UiPathAutomationSuite/<version>/bin/helm uninstall longhorn --namespace longhorn-system
OS のアップグレード後に Automation Suite が動作しない
説明
OS のアップグレード後に、Ceph OSD ポッドが CrashLoopBackOff
ステートでスタックすることがあります。この問題が発生すると、Automation Suite にアクセスできなくなります。
解決策
- 次のコマンドを実行して、ポッドのステートを確認します。
kubectl - n rook-ceph get pods
- 前の出力のポッドのいずれかが
CrashLoopBackOff
である場合は、次のコマンドを実行してそのポッドを回復します。
$OSD_PODS=$(kubectl -n rook-ceph get deployment -l app=rook-ceph-rgw --no-headers | awk '{print $1}')
kubectl -n rook-ceph rollout restart deploy $OSD_PODS
- ポッドが再び「実行中」ステートになるまで約 5 分待ってから、次のコマンドを実行してそのステータスを確認します。
kubectl - n rook-ceph get pods
Azure disk not marked as SSD
説明
An Azure known issue incorrectly shows the rotational flag enabled for the Azure SSD disk. As a result, the Azure disk is not marked as SSD, and the following error occurs when trying to configure the Objectstore disk:
ERROR][2022-08-18T05:26:35+0000]: Rotational device: '/dev/sdf' is not recommended for ceph OSD
解決策
To fix this issue and mark the Azure SSD disk as non-rotational, run the following commands:
echo "0" > "/sys/block/{raw_device_name}/queue/rotational"
echo "KERNEL==\"${raw_device_name}\", ATTR{queue/rotational}=\"0\"" >> "/etc/udev/rules.d/99-ceph-raw-osd-mark-ssd.rules"
udevadm control --reload
udevadm trigger
Click for an example
echo "0" > "/sys/block/sdf/queue/rotational"
echo "KERNEL==\"sdf\", ATTR{queue/rotational}=\"0\"" >> "/etc/udev/rules.d/99-ceph-raw-osd-mark-ssd.rules"
udevadm control --reload
udevadm trigger
Antivirus causing installation issues
説明
Using an antivirus results in an Automation Suite installation issue.
解決策
To fix this issue, add the following folders to the antivirus allowlist:
/var/lib/rancher
/var/lib/kubelet
/opt/UiPathAutomationSuite
/datadisk
/var/lib/rancher/rke2/server/db
/var/lib/longhorn
Unhealthy services after cluster restore or rollback
説明
Following a cluster restore or rollback, AI Center, Orchestrator, Platform, Document Understanding or Task Mining might be unhealthy, with the RabbitMQ pod logs showing the following error:
[root@server0 UiPathAutomationSuite]# k -n rabbitmq logs rabbitmq-server-0
2022-10-29 07:38:49.146614+00:00 [info] <0.9223.362> accepting AMQP connection <0.9223.362> (10.42.1.161:37524 -> 10.42.0.228:5672)
2022-10-29 07:38:49.147411+00:00 [info] <0.9223.362> Connection <0.9223.362> (10.42.1.161:37524 -> 10.42.0.228:5672) has a client-provided name: rabbitConnectionFactory#77049094:2100
2022-10-29 07:38:49.147644+00:00 [erro] <0.9223.362> Error on AMQP connection <0.9223.362> (10.42.1.161:37524 -> 10.42.0.228:5672, state: starting):
2022-10-29 07:38:49.147644+00:00 [erro] <0.9223.362> PLAIN login refused: user 'aicenter-service' - invalid credentials
2022-10-29 07:38:49.147922+00:00 [info] <0.9223.362> closing AMQP connection <0.9223.362> (10.42.1.161:37524 -> 10.42.0.228:5672 - rabbitConnectionFactory#77049094:2100)
2022-10-29 07:38:55.818447+00:00 [info] <0.9533.362> accepting AMQP connection <0.9533.362> (10.42.0.198:45032 -> 10.42.0.228:5672)
2022-10-29 07:38:55.821662+00:00 [info] <0.9533.362> Connection <0.9533.362> (10.42.0.198:45032 -> 10.42.0.228:5672) has a client-provided name: rabbitConnectionFactory#2100d047:4057
2022-10-29 07:38:55.822058+00:00 [erro] <0.9533.362> Error on AMQP connection <0.9533.362> (10.42.0.198:45032 -> 10.42.0.228:5672, state: starting):
2022-10-29 07:38:55.822058+00:00 [erro] <0.9533.362> PLAIN login refused: user 'aicenter-service' - invalid credentials
2022-10-29 07:38:55.822447+00:00 [info] <0.9533.362> closing AMQP connection <0.9533.362> (10.42.0.198:45032 -> 10.42.0.228:5672 - rabbitConnectionFactory#2100d047:4057)
解決策
To fix the issue, take the following steps:
- Check if some or all RabbitMQ pods are in
CrashLoopBackOff
state due to the Mnesia table data write issue. If all pods are running, skip to step 2.
If some pods are in CrashLoopBackOff state, click here for instructions.
- Identify which RabbitMQ pods are stuck in
CrashLoopBackOff
state, and check the RabbitMQCrashLoopBackOff
pod logs:
kubectl -n rabbitmq get pods
kubectl -n rabbitmq logs <CrashLoopBackOff-Pod-Name>
- Check the output of the previous commands. If the issue is related to the Mnesia table data write, you should see an error message similar to the following:
Mnesia('rabbit@rabbitmq-server-0.rabbitmq-nodes.rabbitmq'): ** ERROR ** (could not write core file: eacces)
** FATAL ** Failed to merge schema: Bad cookie in table definition rabbit_user_permission: 'rabbit@rabbitmq-server-0.rabbitmq-nodes.rabbitmq' = {cstruct,rabbit_user_permission,set,[],['rabbit@rabbitmq-server-2.rabbitmq-nodes.rabbitmq','rabbit@rabbitmq-server-0.rabbitmq-nodes.rabbitmq','rabbit@rabbitmq-server-1.rabbitmq-nodes.rabbitmq'],[],[],0,read_write,false,[],[],false,user_permission,[user_vhost,permission],[],[],[],{{1667351034020261908,-576460752303416575,1},'rabbit@rabbitmq-server-1.rabbitmq-nodes.rabbitmq'},{{4,0},{'rabbit@rabbitmq-server-2.rabbitmq-nodes.rabbitmq',{1667,351040,418694}}}}, 'rabbit@rabbitmq-server-1.rabbitmq-nodes.rabbitmq' = {cstruct,rabbit_user_permission,set,[],['rabbit@rabbitmq-server-1.rabbitmq-nodes.rabbitmq'],[],[],0,read_write,false,[],[],false,user_permission,[user_vhost,permission],[],[],[],{{1667372429216834387,-576460752303417087,1},'rabbit@rabbitmq-server-1.rabbitmq-nodes.rabbitmq'},{{2,0},[]}}
- To fix the issue, take the following steps:
- Find the number of RabbitMQ replicas:
rabbitmqReplicas=$(kubectl -n rabbitmq get rabbitmqcluster rabbitmq -o json | jq -r '.spec.replicas')
- Scale down the RabbitMQ replicas:
kubectl -n rabbitmq patch rabbitmqcluster rabbitmq -p "{\"spec\":{\"replicas\": 0}}" --type=merge
kubectl -n rabbitmq scale sts rabbitmq-server --replicas=0
- Wait until all RabbitMQ pods are terminated:
kubectl -n rabbitmq get pod
- Find and delete the PVC of the RabbitMQ pod that is stuck in
CrashLoopBackOff
state:
kubectl -n rabbitmq get pvc
kubectl -n rabbitmq delete pvc <crashloopbackupoff_pod_pvc_name>
- Scale up the RabbitMQ replicas:
kubectl -n rabbitmq patch rabbitmqcluster rabbitmq -p "{\"spec\":{\"replicas\": $rabbitmqReplicas}}" --type=merge
- Check if all RabbitMQ pods are healthy:
kubectl -n rabbitmq get pod
- Find the number of RabbitMQ replicas:
- Delete the users in RabbitMQ:
kubectl -n rabbitmq exec rabbitmq-server-0 -c rabbitmq -- rabbitmqctl list_users -s --formatter json | jq '.[]|.user' | grep -v default_user | xargs -I{} kubectl -n rabbitmq exec rabbitmq-server-0 -c rabbitmq -- rabbitmqctl delete_user {}
- Delete RabbitMQ application secrets in the UiPath namespace:
kubectl -n uipath get secret --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}' | grep -i rabbitmq-secret | xargs -I{} kubectl -n uipath delete secret {}
- Delete RabbitMQ application secrets in the RabbitMQ namespace:
kubectl -n rabbitmq get secret --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}' | grep -i rabbitmq-secret | xargs -I{} kubectl -n rabbitmq delete secret {}
- Sync
sfcore
application via ArgoCD and wait for the sync to complete:

- Perform a rollout restart on all applications in the UiPath namespace:
kubectl -n uipath rollout restart deploy
rke2 not getting started due to space issue
説明
When upgrading to Automation Suite 2022.10 and migrating your data to Azure external storage, rke2 might experience some issues. Specifically, rke2 might not get started and might fail with the following error message: Failed to reconcile with temporary etcd: write /var/lib/rancher/rke2/server/db/etcd-tmp/member/snap/db: no space left on device
.
解決策
この問題を修正するには、次の手順に従います。
- Stop the SSSD service:
systemctl stop sssd
- Remove the SSSD logs:
rm /var/log/sssd/*
- Start the SSSD service:
systemctl start sssd
-
We recommend changing the log rotate policy for the SSSD service from weekly to daily.
-
If the error message persists, try rebooting the host.
Cleaning up old logs stored in the sf-logs
bundle
sf-logs
bundleA bug might cause log accumulation in the sf-logs
object store bucket. To clean up old logs in the sf-logs
bucket, follow the instructions on running the dedicated script. Make sure to follow the steps relevant to your environment type.
To clean up old logs stored in the sf-logs
bundle, take the following steps:
-
Get the version of the
sf-k8-utils-rhel
image available in your environment:- in an offline environment, run the following command:
podman search localhost:30071/uipath/sf-k8-utils-rhel --tls-verify=false --list-tags
- in an online environment, run the following command:
podman search registry.uipath.com/uipath/sf-k8-utils-rhel --list-tags
- in an offline environment, run the following command:
-
Update line 121 in the following
yaml
definition accordingly to include the proper image tag:
apiVersion: v1
kind: ConfigMap
metadata:
name: cleanup-script
namespace: uipath-infra
data:
cleanup_old_logs.sh: |
#!/bin/bash
function parse_args() {
CUTOFFDAY=7
SKIPDRYRUN=0
while getopts 'c:sh' flag "$@"; do
case "${flag}" in
c)
CUTOFFDAY=${OPTARG}
;;
s)
SKIPDRYRUN=1
;;
h)
display_usage
exit 0
;;
*)
echo "Unexpected option ${flag}"
display_usage
exit 1
;;
esac
done
shift $((OPTIND - 1))
}
function display_usage() {
echo "usage: $(basename "$0") -c <number> [-s]"
echo " -s skip dry run, Really deletes the log dirs"
echo " -c logs older than how many days to be deleted. Default is 7 days"
echo " -h help"
echo "NOTE: Default is dry run, to really delete logs set -s"
}
function setS3CMDContext() {
OBJECT_GATEWAY_INTERNAL_HOST=$(kubectl -n rook-ceph get services/rook-ceph-rgw-rook-ceph -o jsonpath="{.spec.clusterIP}")
OBJECT_GATEWAY_INTERNAL_PORT=$(kubectl -n rook-ceph get services/rook-ceph-rgw-rook-ceph -o jsonpath="{.spec.ports[0].port}")
AWS_ACCESS_KEY=$1
AWS_SECRET_KEY=$2
# Reference https://rook.io/docs/rook/v1.5/ceph-object.html#consume-the-object-storage
export AWS_HOST=$OBJECT_GATEWAY_INTERNAL_HOST
export AWS_ENDPOINT=$OBJECT_GATEWAY_INTERNAL_HOST:$OBJECT_GATEWAY_INTERNAL_PORT
export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY
export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_KEY
}
# Set s3cmd context by passing correct AccessKey and SecretKey
function setS3CMDContextForLogs() {
BUCKET_NAME='sf-logs'
AWS_ACCESS_KEY=$(kubectl -n cattle-logging-system get secret s3-store-secret -o json | jq '.data.OBJECT_STORAGE_ACCESSKEY' | sed -e 's/^"//' -e 's/"$//' | base64 -d)
AWS_SECRET_KEY=$(kubectl -n cattle-logging-system get secret s3-store-secret -o json | jq '.data.OBJECT_STORAGE_SECRETKEY' | sed -e 's/^"//' -e 's/"$//' | base64 -d)
setS3CMDContext "$AWS_ACCESS_KEY" "$AWS_SECRET_KEY"
}
function delete_old_logs() {
local cutoffdate=$1
days=$(s3cmd ls s3://sf-logs/ --host="${AWS_HOST}" --host-bucket= s3://sf-logs --no-check-certificate --no-ssl)
days=${days//DIR}
if [[ $SKIPDRYRUN -eq 0 ]];
then
echo "DRY RUN. Following log dirs are selected for deletion"
fi
for day in $days
do
day=${day#*sf-logs/}
day=${day::-1}
if [[ ${day} < ${cutoffdate} ]];
then
if [[ $SKIPDRYRUN -eq 0 ]];
then
echo "s3://$BUCKET_NAME/$day"
else
echo "###############################################################"
echo "Deleting Logs for day: {$day}"
echo "###############################################################"
s3cmd del "s3://$BUCKET_NAME/$day/" --host="${AWS_HOST}" --host-bucket= --no-ssl --recursive || true
fi
fi
done
}
function main() {
# Set S3 context by setting correct env variables
setS3CMDContextForLogs
echo "Bucket name is $BUCKET_NAME"
CUTOFFDATE=$(date --date="${CUTOFFDAY} day ago" +%Y_%m_%d)
echo "logs older than ${CUTOFFDATE} will be deleted"
delete_old_logs "${CUTOFFDATE}"
if [[ $SKIPDRYRUN -eq 0 ]];
then
echo "NOTE: For really deleting the old log directories run with -s option"
fi
}
parse_args "$@"
main
exit 0
---
apiVersion: v1
kind: Pod
metadata:
name: cleanup-old-logs
namespace: uipath-infra
spec:
serviceAccountName: fluentd-logs-cleanup-sa
containers:
- name: cleanup
image: localhost:30071/uipath/sf-k8-utils-rhel:0.8
command: ["/bin/bash"]
args: ["/scripts-dir/cleanup_old_logs.sh", "-s"]
volumeMounts:
- name: scripts-vol
mountPath: /scripts-dir
securityContext:
privileged: false
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
runAsUser: 9999
runAsGroup: 9999
runAsNonRoot: true
capabilities:
drop: ["NET_RAW"]
volumes:
- name: scripts-vol
configMap:
name: cleanup-script
- Copy the content of the aforementioned
yaml
definition to a file calledcleanup.yaml
. Trigger a pod to clean up the old logs:
kubectl apply -f cleanup.yaml
- Get details on the progress:
kubectl -n uipath-infra logs cleanup-old-logs -f
- Delete the job:
kubectl delete -f cleanup.yaml
Identity Server の問題
管理ポータルのタイムアウト期間を設定する
インストール前には、ホストレベルおよび組織レベルの管理ポータルでの認証に使用されるトークンの有効期限を更新できません。そのため、ユーザー セッションはタイムアウトしません。
これらのポータルにタイムアウト期間を設定するには、accessTokenLifetime
プロパティを更新します。
次の例では、タイムアウト期間を 86400 秒 (24 時間) に設定します。
UPDATE [identity].[Clients] SET AccessTokenLifetime = 86400 WHERE ClientName = 'Portal.OpenId'
Update the underlying directory connections
Disabling or changing the AD integration settings does not update the underlying directory connections properly.
Run the following command to update the SQL DirectoryConnections
table entries, then restart the Identity pods:
UPDATE [identity].[DirectoryConnections] SET IsDeleted = 1, DeletionTime=GETUTCDATE() WHERE (Type='ad' OR Type='ldapad') AND IsDeleted=0
Kerberos の問題
kinit: Cannot find KDC for realm while getting initial credentials
説明
このエラーは、インストール中 (Kerberos 認証を有効化している場合) または kerberos-tgt-update
cron ジョブの実行中に、UiPath クラスターが Active Directory サーバーに接続して認証用の Kerberos チケットを取得できないときに発生することがあります。
解決策
Active Directory ドメインをチェックし、ドメインが次のように正しく設定されていて、ルーティング可能であることを確認します。
getent ahosts <AD domain> | awk '{print $1}' | sort | uniq
このコマンドがルーティング可能な IP アドレスを返さない場合、Kerberos 認証に必要な Active Directory ドメインは正しく設定されていません。
IT 管理者と協力して Active Directory ドメインを DNS サーバーに追加し、このコマンドがルーティング可能な IP アドレスを返すようにする必要があります。
kinit: Keytab contains no suitable keys for *** while getting initial credentials
説明
このエラーは、失敗したジョブのログ内に、services-preinstall-validations-job
、kerberos-jobs-trigger
、kerberos-tgt-update
のいずれかのジョブ名で確認できます。
解決策
Active Directory ユーザーがまだ存在していてアクティブで、パスワードが変更されておらず期限切れではなかったことを確認します。必要に応じて、ユーザーのパスワードをリセットして keytab を再生成します。
また、既定の Kerberos Active Directory ユーザー パラメーター <KERB_DEFAULT_USERNAME>
を HTTP/<Service Fabric FQDN>
の形式で指定してください。
GSSAPI operation failed with error: An invalid status code was supplied (Client's credentials have been revoked).
説明
このログは、Kerberos を SQL アクセスに使用していて、SQL 接続がサービス内で失敗するときに見つかる可能性があります。同様に、「kinit: Client's credentials have been revoked while getting initial credential
」がジョブ名 services-preinstall-validations-job
、kerberos-jobs-trigger
、kerberos-tgt-update
のいずれかに表示される可能性があります。
解決策
これは、keytab の生成に使用した Active Directory ユーザー アカウントが無効化されていることが原因である可能性があります。Active Directory ユーザー アカウントを再度有効化すると、問題は修正されます。
Alarm received for failed kerberos-tgt-update job
説明
これは、UiPath クラスターが最新の Kerberos チケットの取得に失敗した場合に発生します。
解決策
To find the issue, check the log for a failed job whose name starts with kerberos-tgt-update
. After you've identified the problem in the log, check the related troubleshooting information in this section and in the Troubleshooting section for configuring Active Directory.
SSPI Provider: Server not found in Kerberos database
解決策
Make sure that the correct SPN records are set up in the AD domain controller for the SQL server. For instructions, see SPN formats in the Microsoft SQL Server documentation.
Login failed for user <ADDOMAIN>\<aduser>
.Reason: The account is disabled.
<ADDOMAIN>\<aduser>
.Reason: The account is disabled.説明
このログは、Kerberos を SQL アクセスに使用していて、SQL 接続がサービス内で失敗するときに見つかる可能性があります。
解決策
This issue could be caused by the AD user losing access to the SQL server. See instructions on how to reconfigure the AD user.
Orchestrator に関連する問題
CrashLoopBackOff または 1/2 になっている Orchestrator ポッドが複数の再起動で実行されている
説明
CrashLoopBackOff または 1/2 になっている Orchestrator ポッドが複数の再起動で実行されている場合、エラーはオブジェクト ストレージ プロバイダー Ceph の認証キーに関連している可能性があります。
エラーが Ceph に関連しているかどうかを確認するには、次のコマンドを実行します。
kubectl -n uipath get pod -l app.kubernetes.io/component=orchestrator
このコマンドの出力が、次のいずれかのオプションの出力と似ている場合は、追加のコマンドを実行する必要があります。
Option 1:
NAME READY STATUS RESTARTS AGE
orchestrator-6dc848b7d5-q5c2q 1/2 Running 2 6m1s
OR
Option 2
NAME READY STATUS RESTARTS AGE
orchestrator-6dc848b7d5-q5c2q 1/2 CrashLoopBackOff 6 16m
次のコマンドを実行して、障害が Ceph 認証キーに関係しているかどうかを検証します。
kubectl -n uipath logs -l app.kubernetes.io/component=orchestrator | grep 'Error making request with Error Code InvalidAccessKeyId and Http Status Code Forbidden' -o
上記のコマンドの出力に文字列 Error making request with Error Code InvalidAccessKeyId and Http Status Code Forbidden
が含まれている場合、障害は Ceph 認証キーに起因しています。
解決策
次のコマンドを使用して、rook-ceph-configure-script-job
と credential-manager
のジョブを再実行します。
kubectl -n uipath-infra get job "rook-ceph-configure-script-job" -o json | jq 'del(. | .spec.selector, .spec.template.metadata.labels)' | kubectl replace --force -f -
kubectl -n uipath-infra get job "credential-manager-job" -o json | jq 'del(. | .spec.selector, .spec.template.metadata.labels)' | kubectl replace --force -f -
kubectl -n uipath delete pod -l app.kubernetes.io/component=orchestrator
Test Manager に関連する問題
Test Manager のライセンスに関する問題
ユーザーが Automation Suite にログイン中にライセンスが割り当てられた場合、Test Manager を開いた際にライセンスの割り当てが検出されないことがあります。
この問題が発生する場合は、以下の手順に従ってください。
- Test Manager に移動します。
- ポータルからログアウトします。
- 再度ログインします。
AI Center に関連する問題
AI Center のスキルのデプロイに関する問題
DU モデル スキルのデプロイが、最初のモデルのデプロイ時に断続的に、デプロイのリスト表示の失敗または不明なエラーで失敗することがあります。回避するには、そのモデルを再度デプロイします。1 回目のデプロイ試行時に画像構築のデプロイ作業のほとんどが完了しているため、2 回目のデプロイには時間がかかりません。DU モデルの最初のデプロイには約 1 - 1.5 時間を要しますが、再度デプロイする際は、これより短時間で完了します。
まれに、クラスターのステートが原因で、スキルのデプロイやパッケージのアップロードなどの非同期操作が長時間スタックしてしまうことがあります。DU スキルのデプロイに 2 - 3 時間以上かかる場合は、よりシンプルなモデル (例: TemplateModel) のデプロイを試みてください。シンプルなモデルを使用した場合でもデプロイに 1 時間以上かかる場合は、軽減策として以下のコマンドを使用した AI Center サービスの再起動を実行します。
kubectl -n uipath rollout restart deployment ai-deployer-deployment
kubectl -n uipath rollout restart deployment ai-trainer-deployment
kubectl -n uipath rollout restart deployment ai-pkgmanager-deployment
kubectl -n uipath rollout restart deployment ai-helper-deployment
kubectl -n uipath rollout restart deployment ai-appmanager-deployment
以下のコマンドを使用して検証し、AI Center の pod が復旧されるまで待機します。
kubectl -n uipath get pods | grep ai-*
成功していれば、上記の pod のステートはすべて「Running」になり、コンテナーのステートは「2/2」になるはずです。
Disabling streaming logs
To disable log streaming on existing skills, edit the skill deployment and change the LOGS_STREAMING_ENABLED
environment variable to false
.
You can also add a logsStreamingEnabled
global variable with the value set as false
using ArgoCD under the aicenter app details. Make sure to sync ArgoCD after the change is done.

Unknown error when accessing AI Center
説明
The following error can occur when accessing AI Center:
An unknown error has occurred. (#200)

解決策
To recover from this error, run the final step for installing AI Center. For more information, check the page applicable to your case:
- Online single-node, Completing AI Center installation section
- Offline single-node, Completing AI Center installation section
- Online multi-node, Completing AI Center installation section
- Offline multi-node, Completing AI Center installation section in Step 4.3: Finishing installing the suite
Document Understanding に関連する問題
Document Understanding が Automation Suite の画面左側のレールにない
説明
Document Understanding が Automation Suite の左側のレールで見つからない場合は、現在 Document Understanding が Automation Suite の独立したアプリケーションではないため、左側のレールに表示されないということをご承知おきください。
解決策
データ マネージャーのコンポーネントは AI Center の一部であるため、AI Center が有効化されていることを確認してください。
また、下記の公開 URL から、フォーム抽出器、インテリジェント フォーム抽出器 (HandwritingRecognition (手書き文字認識) を含む)、インテリジェント キーワード分類器にアクセスしてください。
<FQDN>/du_/svc/formextractor
<FQDN>/du_/svc/intelligentforms
<FQDN>/du_/svc/intelligentkeywords
Studio 内でインテリジェント キーワード分類器、フォーム抽出器、インテリジェント フォーム抽出器を使おうとして Your license can not be validated
というエラー メッセージが表示される場合、適切なエンドポイントを入力したことを確認するとともに、API キーとして、cloud.uipath.com からのものではなく、Automation Suite インストールのライセンス対象である Document Understanding 用に生成したものを使用してください。
データのラベル付けセッションの作成時の失敗ステータス
説明
AI Center のデータ マネージャーでデータのラベル付けセッションを作成できない場合は、次の手順を実行します。
解決策 1
Document Understanding が適切に有効化されていることをダブルチェックします。インストール前に構成ファイルを更新し、documentunderstanding.enabled
を True に設定している必要があります。あるいは、下記のようにインストール後に ArgoCD で更新することもできます。
それを行った後、これを無効化し、データのラベル付け機能を使用するテナントで AI Center を無効化するか、新しいテナントを作成する必要があります。

解決策 2
構成ファイルまたは ArgoCD で Document Understanding が適切に有効化されている場合に、Document Understanding が DefaultTenant で有効化されないことがあります。これにより、データのラベル付けセッションを作成できません。
この問題を修正するには、テナント上の AI Center を無効化にしてから再度有効化します。再度有効化できるようになるまで、数分かかる場合がある点にご注意ください。
ML スキルのデプロイ試行時の失敗ステータス
説明
Document Understanding ML Skill を AI Center に正常にデプロイできない場合は、次の解決策を確認してください。
解決策 1
Automation Suite をオフラインでインストールする場合、Document Understanding のバンドルがダウンロードされインストールされていることをダブルチェックしてください。
バンドルには、AI Center の UI を介して ML パッケージをアップロードした後にモデルが AI Center で適切に動作するためのベース イメージ (例: モデル ライブラリ) が含まれます。
For details about installing Document Understanding bundle, please refer to the documentation here and here. To add Document Understanding bundle, please follow the documentation to re-run the Document Understanding bundle installation.
解決策 2
オフライン インストールで Document Understanding バンドルをインストールした場合であっても、エラー メッセージ modulenotfounderror: no module named 'ocr.release'; 'ocr' is not a package
に加えて、もう 1 つの問題が発生する可能性があります。
AI Center で Document Understanding OCR ML パッケージを作成する場合、その名前に ocr または OCR を使用できないことに注意してください。これらの名前はパッケージ内のフォルダーと競合します。必ず別の名前を選択してください。
解決策 3
Document Understanding モデル スキルのデプロイが、最初のモデルのデプロイ時に断続的に Failed to list deployment
または Unknown Error
で失敗することがあります。
回避するには、そのモデルを再度デプロイします。1 回目のデプロイ試行時に画像構築のデプロイ作業のほとんどが完了しているため、2 回目のデプロイには時間がかかりません。Document Understanding ML パッケージの最初のデプロイには約 1 - 1.5 時間を要しますが、再度デプロイする際は、これより短時間で完了します。
ArgoCD で移行ジョブが失敗する
説明
ArgoCD で Document Understanding の移行ジョブが失敗する。
解決策
Document Understanding を使用するには、SQL サーバーでフルテキスト検索機能が有効化されている必要があります。有効化されていない場合に移行ジョブが ArgoCD で失敗すると、明示的なエラー メッセージが表示されないままインストールに失敗することがあります。
インテリジェント フォーム抽出器による手書き文字認識が機能しない
説明
インテリジェント フォーム抽出器による手書き文字認識が機能しない、または動作が遅い。
解決策 1
インテリジェント フォーム抽出器をオフラインで使用している場合、手書き文字機能を ArgoCD でインストールまたは有効化する前に、構成ファイルで有効化済みであることを確認してください。
ダブルチェックするには、ArgoCD > [Document Understanding] > [App details] > du-services.handwritingEnabled に移動し、これを True に設定します。
エアギャップ シナリオでは、これを実行する前に Document Understanding バンドルをインストールする必要があります。こうしないと、ArgoCD の同期が失敗します。
解決策 2
構成ファイルで手書き文字を有効化していても、依然として同じ問題が発生する場合があります。
各コンテナーが手書き文字に使用できる CPU の最大数は既定で 2 であることを覚えておいてください。手書き文字処理のワークロードが大きい場合は、handwriting.max_cpu_per_pod
パラメーターの調整が必要になる可能性があります。このパラメーターはインストール前に構成ファイルで更新するか、ArgoCD で更新できます。
For more details on how to calculate the parameter value based on your volume, please check the documentation here.
Insights に関連する問題
Insights のホーム ページに移動すると 404 エラーが表示される
まれに、ルーティング エラーが発生し、Insights のホーム ページに 404 が表示されることがあります。このエラーは、ArgoCD で Insights アプリケーションに移動し、仮想サービス insightsprovisioning-vs を削除することで解決できます。この仮想サービスを表示および削除するために [clear filters to show X additional resources] をクリックする必要が生じることがあります。
Looker が初期化に失敗する
During Looker initialization, you might encounter and error stating RuntimeError: Error starting Looker
. A Looker pod failure produced this error due to a possible system failure or loss of power. The issue is persistent even if you reinitialize Looker.
この問題を解決するには、永続ボリューム要求 (PVC) を削除してから再起動します。
2 日前に更新