我可以使用Windows中的命令行(設置服務帳戶密鑰等)成功運行帶Windows域帳戶的gsutil命令。當我嘗試使用CmdExec任務從SQL代理作業運行相同的命令時,作業掛起並且無法完成。我看不到任何日誌記錄,所以不知道它正在等待什麼。我已經將該作業設置爲使用用於手動運行gsutil命令的相同代理用戶運行。SQL Server代理作業和gsutil
任何想法如何讓這個工作或如何看到更多的日誌?
我可以使用Windows中的命令行(設置服務帳戶密鑰等)成功運行帶Windows域帳戶的gsutil命令。當我嘗試使用CmdExec任務從SQL代理作業運行相同的命令時,作業掛起並且無法完成。我看不到任何日誌記錄,所以不知道它正在等待什麼。我已經將該作業設置爲使用用於手動運行gsutil命令的相同代理用戶運行。SQL Server代理作業和gsutil
任何想法如何讓這個工作或如何看到更多的日誌?
你在使用獨立gsutil嗎?或者您是否將其作爲安裝Cloud SDK(gcloud)的一部分?
如果作業掛了很長時間,可能會停止多次重試。爲了測試,如果是這樣的話,你可以設置NUM_RETRIES選項非常小,但高於0(如1)無論是在你的.boto
文件或通過該選項的命令行參數:
gsutil -o 'Boto:num_retries=1' <rest of command here...>
第二件事需要注意的是(至少對於gsutil不包含gcloud的版本)是gsutil默認在你的主目錄下查找你的boto配置文件(它指定它應該使用的憑證)。如果您以不同的用戶身份運行gsutil(也許您的SQL代理作業是作爲其自己的專用用戶運行的?),它將在中查找.boto
文件,即用戶的主目錄。這同樣適用於gcloud版本 - gcloud使用基於執行它的用戶的憑據。通過將.boto文件複製到作業有權讀取的位置,並在運行gsutil之前將BOTO_CONFIG環境變量設置爲該路徑,您可以避免這種情況。從CMD外殼,這看起來是這樣的:
set BOTO_CONFIG=C:\some\path\.boto && gsutil <rest of command here...>
注意:如果你不知道這博託配置文件你正常使用,你可以找到通過運行gsutil version -l
看着那行顯示你的配置路徑。
謝謝你。事實證明,BOTO_CONFIG是問題。 – jimmy