I am trying to serve a TorchScript model with the triton (tensorRT) inference server. But every time I start the server it throws the following error:
PytorchStreamReader failed reading zip archive: failed finding central directory
My folder structure is :
<model_repository>
<model_name>
config.pbtxt
<1>
<model.pt>
My config.pbtxt file is :
name: "model"
platform: "pytorch_libtorch"
max_batch_size: 1
input[
{
name: "INPUT__0"
data_type: TYPE_FP32
dims: [-1,3,-1,-1]
}
]
output:[
{
name: "OUTPUT__0"
data_type: TYPE_FP32
dims: [-1,1,-1,-1]
}
]
I found the solution. It was a silly mistake on my part. The .pt torchscript file was not loaded properly.
Related
Starting in macOS 12 (Monterey), the system apparently writes crash file as .ips files, instead of the traditional .crash file format.
The file appears to contain JSON data:
{"app_name":"Helper","timestamp":"2021-10-30 18:49:32.00 +0100","app_version":"3.0.0(66) beta","slice_uuid":"673198dd-94ac-31a7-9e81-09fe6c781255","build_version":"3.0.0.66","platform":1,"bundleID":"com.dislt.helper","share_with_app_devs":0,"is_first_party":0,"bug_type":"309","os_version":"macOS 12.0.1 (21A559)","incident_id":"CC03C2EC-C1D4-4F6E-AA1F-6C4EC555D6B8","name":"Helper"}
{
"uptime" : 91000,
"procLaunch" : "2021-10-30 18:49:29.7791 +0100",
"procRole" : "Unspecified",
"version" : 2,
"userID" : 501,
"deployVersion" : 210,
"modelCode" : "MacBookPro14,3",
"procStartAbsTime" : 91844701503187,
"coalitionID" : 1244,
"osVersion" : {
"train" : "macOS 12.0.1",
"build" : "21A559",
"releaseType" : "User"
},
"captureTime" : "2021-10-30 18:49:32.4572 +0100",
"incident" : "92A89610-D70A-4D93-A974-A9018BB5C72A",
"bug_type" : "309",
"pid" : 77765,
"procExitAbsTime" : 91847378271126,
"cpuType" : "X86-64",
"procName" : "Helper",
...
When I preview the file or open it in the Console app, a traditional crash report is automatically generated:
-------------------------------------
Translated Report (Full Report Below)
-------------------------------------
Process: Helper [77765]
Path: /Users/USER/Library/Application Support/Helper.app/Contents/MacOS/Helper
Identifier: com.distl.helper
Version: 3.0.0(66) beta (3.0.0.66)
Code Type: X86-64 (Native)
Parent Process: TestBead [77726]
Responsible: TestBead [77726]
User ID: 501
Date/Time: 2021-10-30 18:49:32.4572 +0100
OS Version: macOS 12.0.1 (21A559)
Report Version: 12
Bridge OS Version: 3.0 (14Y908)
Anonymous UUID: CC03C2EC-C1D4-4F6E-AA1F-6C4EC555D6B8
Time Awake Since Boot: 91000 seconds
System Integrity Protection: enabled
Crashed Thread: 1 Dispatch queue: com.apple.NSXPCConnection.user.anonymous.77726
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00007f780071a000
Exception Codes: 0x0000000000000001, 0x00007f780071a000
Exception Note: EXC_CORPSE_NOTIFY
Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11
Terminating Process: exc handler [77765]
...
I have customer support and development tools that scan these crash report files automatically, and I'd like to find out if there's a way to automate the translation of the JSON data back into the traditional crash report format?
I'd like to do this to (a) avoid rewriting my crash report scanning tools (although that wouldn't be impossible), and (b) automatically translate these files into a human readable format, without resorting to opening the file in the Console app.
I've run into the same problem. I haven't tried it myself yet, but someone has already created an ips2crash command available at GitHub. As the name implies, it should convert an .ips file to the (now) legacy crash report format.
I need to create, among other items, an SQL instance on the google cloud platform. I am required to create the database using Jinja files.
My Yaml file
imports:
- path: companyInstance.jinja
resources:
# Creates a database instance
- name: dbinstance11
type: companyInstance.jinja
My companyInstance.jinja
resources:
- name: test
type: sqladmin.v1beta4.instance
properties:
zone: europe-west1
settings:
- tier: db-custom-4-15360
Currently, this should all work as far as I can tell but on a full deployment, I get an error message claiming that type is given an array type instead of object.
The full error is below:
ERROR: (gcloud.deployment-manager.deployments.create) Error in Operation [operation-169876402531-756fgfg342844d-6gd6ebb6-8bb655a]: errors:
- code: CONDITION_NOT_MET
location: /deployments/dep/resources/test->$.properties
message: |
error: instance type (array) does not match any allowed primitive type (allowed: ["object"]) level: "error"
schema: {"loadingURI":"#","pointer":"/schemas/Settings"}
instance: {"pointer":"/settings"}
domain: "validation"
keyword: "type"
found: "array"
expected: ["object"]
I downloaded the chisel-tutorial which is offered on the website of usb-bar.
In order to do practise I created a scala file named as "Regfile.scala" under the path:
"chisel-tutorial/src/main/scala/solutions/Regfile.scala".
The Test-file is stored under the path :
"chisel-tutorial/src/test/scala/solutions/RegfileTests.scala".
While running the sbt I was reported
(after execution of command "test:run-main solutions.Launcher Regfile"):
"Errors: 1: in the following tutorials
Bad tutorial name: Regfile "
How can I solve this problem?
You have to add your Regfile to Launcher.scala. The launcher is available in directory :
src/test/scala/solutions/Launcher.scala
I think you can add somethings like this to Launch.scala to test your Regfile:
"Regfile" -> { (backendName: String) =>
Driver(() => new Regfile(), backendName) {
(c) => new RegfileTests(c)
}
},
I have a inventory file which has a RDS endpoint as :
[ems_db]
syd01-devops.ce4l9ofvbl4z.ap-southeast-2.rds.amazonaws.com
I wrote the following play book to create a Cloudwatch ALARM :
---
- name: Get instance ec2 facts
debug: var=groups.ems_db[0].split('.')[0]
register: ems_db_name
- name: Display
debug: var=ems_db_name
- name: Create CPU utilization metric alarm
ec2_metric_alarm:
state: present
region: "{{aws_region}}"
name: "{{ems_db_name}}-cpu-util"
metric: "CPUUtilization"
namespace: "AWS/RDS"
statistic: Average
comparison: ">="
unit: "Percent"
period: 300
description: "It will be triggered when CPU utilization is more than 80% for 5 minutes"
dimensions: { 'DBInstanceIdentifier' : ems_db_name }
alarm_actions: arn:aws:sns:ap-southeast-2:493552970418:cloudwatch_test
ok_actions: arn:aws:sns:ap-southeast-2:493552970418:cloudwatch_test
But this results in
TASK: [cloudwatch | Get instance ec2 facts] ***********************************
ok: [127.0.0.1] => {
"var": {
"groups.ems_db[0].split('.')[0]": "syd01-devops"
}
}
TASK: [cloudwatch | Display] **************************************************
ok: [127.0.0.1] => {
"var": {
"ems_db_name": {
"invocation": {
"module_args": "var=groups.ems_db[0].split('.')[0]",
"module_complex_args": {},
"module_name": "debug"
},
"var": {
"groups.ems_db[0].split('.')[0]": "syd01-devops"
},
"verbose_always": true
}
}
}
TASK: [cloudwatch | Create CPU utilization metric alarm] **********************
failed: [127.0.0.1] => {"failed": true}
msg: BotoServerError: 400 Bad Request
<ErrorResponse xmlns="http://monitoring.amazonaws.com/doc/2010-08-01/">
<Error>
<Type>Sender</Type>
<Code>MalformedInput</Code>
</Error>
<RequestId>f30470a3-2d65-11e6-b7cb-cdbbbb30b60b</RequestId>
</ErrorResponse>
FATAL: all hosts have already failed -- aborting
What is wrong here? What can i do to solve this ? I am new to this but surely this seems some syntax issue with me or the way i am picking up the inventory endpoint split.
The variable from debug isn't being assigned in the first debug statement, though you may be able to if you change it to a message and enclose it with quotes and double braces (untested):
- name: Get instance ec2 facts
debug: msg="{{groups.ems_db[0].split('.')[0]}}"
register: ems_db_name
However, I would use the set_fact module in that task (instead of debug) and assign that value to it. That way, you can reuse it in this and subsequent calls to a play.
- name: Get instance ec2 facts
set_fact: ems_db_name="{{groups.ems_db[0].split('.')[0]}}"
UPDATE: Add a threshold: 80.0 to the last task, and the dimensions needs to use the instance id encapsulated with double braces.
I'm trying to configure the shovel plugin via the config file (running in docker) but I get this error:
BOOT FAILED
===========
Error description:
{error,{failed_to_cluster_with,[rabbit#dalmacpmfd57],
"Mnesia could not connect to any nodes."}}
The config is set up this way because the destination for shovel will be created on demand when a dev environment is spun up... the source is a permanent rabbitmq instance running that the new, dev environment will attach to.
Here is the config file contents:
[
{rabbitmq_shovel,
[{shovels,
[{indexer_replica_static,
[{sources,
[{broker, [ "amqp://guest:guest#rabbitmq/newdev" ]},
{declarations,
[{'queue.declare', [{queue, <<"Indexer_Replica_Static">>}, durable]},
{'queue.bind',[ {exchange, <<"Indexer">>}, {queue, <<"Indexer_Replica_Static">>}]}
]
}
]
},
{destinations,
[{broker, "amqp://"},
{declarations, [ {'exchange.declare', [ {exchange, <<"Indexer_Replica_Static">>}
, {type, <<"fanout">>}, durable]},
{'queue.declare', [
{queue, <<"Indexer_Replica_Static">>},
durable]},
{'queue.bind',
[ {exchange, <<"Indexer_Replica_Static">>}
, {queue, <<"Indexer_Replica_Static">>}
]}
]
}
]
},
{queue, <<"Indexer_Replica_Static">>},
{prefetch_count, 0},
{ack_mode, on_confirm},
{publish_properties, [ {delivery_mode, 2} ]},
{reconnect_delay, 2.5}
]
}
]
},
{reconnect_delay, 2.5}
]
}
].
[UPDATE]
This is being run in docker but since I couldn't debug the issue in docker I tried booting up rabbit locally with the same config file. I noticed in the logs that the rabbit config system variable I set (RABBITMQ_CONFIG_FILE) isn't reflected in the log and the shovel settings haven't been applied (no surprise huh). I verified the variable with an echo statement and the correct path is displayed: /dev/rabbitmq_server-3.3.4/rabbitmq
=INFO REPORT==== 3-Sep-2014::15:30:37 ===
node : rabbit#dalmacpmfd57
home dir : /Users/e002678
config file(s) : (none)
cookie hash : n6vhh8tY7Z+uR2DV6gcHUg==
log : /usr/local/rabbitmq_server-3.3.4/sbin/../var/log/rabbitmq/rabbit#dalmacpmfd57.log
sasl log : /usr/local/rabbitmq_server-3.3.4/sbin/../var/log/rabbitmq/rabbit#dalmacpmfd57- sasl.log
database dir : /usr/local/rabbitmq_server-3.3.4/sbin/../var/lib/rabbitmq/mnesia/rabbit#dalmacpmfd57
Thanks!