getslingscripthelper().getservice() returns null.
I made sure the bundle and the service is active. However, instead of active, it has the number 16.. not sure if this has anything to do with it.
I tried deleting the bundle and reinstalling with the package manager.
Any help would be much appreciated!
Finally figured this out. It was because I was running the encryption utility service on my local host. I didn't have the keys properly configured in the right directory. After this was fixed it worked fine.
I'm still unsure what the 16 means in the status column of the osgi service but after I configured the keys correctly, the status changed back to 'active'.
Related
We're using odoo.sh platform with odoo14. The installed wkhtmltopdf is wkhtmltopdf_paas_wrapper 0.12.5, we can't upgrade to 0.12.6 because the access is very limited we cant use 'sudo' to apt-install. To temporarily solve this, we decided to use the 0.12.5 version. But it returns "Unable to call host printing service (HTTPError)" even with the right arguments. I've already tried it with the staging and production server, but still the same result. The ticket I've sent hasn't been replied to yet. This is so frustrating, I'm going bonkers...please help.
here's a screenshot:
ps: unrecognized argument error was intentional so I can display the available args. I've also crossed out the project domain. Thank you
Apparently, to properly execute the package, it should not have been "wkhtmltopdf" but instead "wkhtmltopdf.bin". I've overridden the ir_actions_report.py to change the package name. Here's the snippet of the original source code:
They shouldve known better, its a paid platform.
I tried to play with LowCardinality setting, I got a message saying that this is an experimental feature and I have to SET allow_experimental_low_cardinality_type = 1 in order to use it.
I executed this command inside clickhouse-client and then I restarted the server. But I got
clickhouse-server.service: Unit entered failed state
Now I am trying to find out how to disable this setting and make my clickhouse-server start again.
Can you help with this please ?
PS: The version I use is the 18.12.17 and I installed it on Linux Ubuntu 16.04
ClickHouse has different layers for settings. If you used SET <setting> = <value> then you set it for current session. You don't need to restart ClickHouse. Please, take a look here.
I suppose you faced with another problem during starting your server. There a bunch of reasons why. So, firstly try to recollect what were done in configs since last restart (because you have just applied changes by restarting server).
Digging into logs also an awesome idea. Don't hesitate to check other similar issues on github.com, for example like this one
I've had RabbitMQ 3.2.1 (Erl OTP 16B02 x64) running on Win 2008R2, one day it started to return nodedown error. I decided to reinstall RabbitMQ, I've removed Rabbit and Erlang enviriment, cleaned db folder in RABBITMQ_BASE, removed all erlang cookies and RABBITMQ_NODENAME / PORT variables. Intalled RabbitMQ 3.5.4 Erlang OTP18 x64 as admin....but still I'm not able to manage service via command promt, it gives me following output:
I've already seen some post on this error (Post1 , Post2 ) but, as I see right now all that they are suggesting is reinstall RabbitMQ and to be careful with Erlang cookies, and I've cleaned system completely after uninstalling previous version. Still, any suggestions appreciated.
Thanks.
UPD
Funny thing - I've noticed that db folder in RABBITMQ_BASE is empty, so it is empty in %USERPROFILE%\AppData\Roaming\RabbitMQ... I thought it must create node structure there on service first start...
It's telling you that it is trying to connect to a node with name 'rabbit', and it is telling you that there is a node running with a name of 'RabbitMQ'.
Presumably 'RabbitMQ' is indeed your RabbitMQ node? Perhaps your new installation changed the name of the node, or maybe you were using a non default node name before that has been partially reset? Or maybe something else... Either way, I know you said you cleaned it, but there's a definite mismatch in the node name being used by your server and the rabbitmqctl client.
See RabbitMQ configuration for details on how to check and change your configuration (for UNIX and Windows), or try telling rabbitmqctl to use a different node name (this is -n on UNIX, not sure on Windows).
We (the RabbitMQ team) already saw this behavior, but couldn't reproduce it so far. What we discovered is that for unknown reasons, the Windows service is installed without its parameter, in particular, the node name (rabbit#<hostname>) is missing and Erlang (or Windows, I don't know) picks the service name as the node name (RabbitMQ#<hostname>).
rabbitmqctl fails to contact this node because it expects rabbit#<hostname> by default. But anyway, the node is not working properly.
The workaround we know is to remove and reinstall the Windows service.
I'm getting an error while add my public key & it showing this error code: "
Error updating settings on gear: 01779aa6c3e04c71be82fbaa10662fcf with status: -1 and output: "
Any idea that why this is showing everytime when I am registering public key.....//
We believe this is a problem that arose in our most recent update on tuesday and are now investigating. When you add an SSH key we copy it to each of your applications (so git will work) - it looks like the copy process started failing.
EDIT: We fixed an issue in production that was affecting a small number of users that resulted in this symptom. Please let us know if the issue is not fixed, and we'll investigate further.
I am getting the same error. Looks like its their internal server problem..
EDIT: it seems you can't put security on applications that are available for test in openShift. It makes sense. Remove the test applications that you got from OpenShift.
I got it solved. That number {01779aa6c3e04c71be82fbaa10662fcf} is an application you currently have in your domain. I removed all applications in there. Have backups first, then clean your domain. Update your public key again and I am 100% sure it will work.
Please do this with care. Back up your application first. To remove
rhc app destroy -a {appName} -d
It's was my silly mistake, just I have to add my private key at the time of authentication in Putty.
I've compiled and trolled around the quickfix ( http://www.quickfixengine.org ) source and the examples. I figured a good starting point would be to compile (C++) and run the 'executor' example, then use the 'tradeclient' example to connect to 'executor', and send it order requests.
I created two seperate session files one for the 'executor' as an acceptor, and one for the 'tradeclient' as the initiator. They're both running on the same Win7 pc.
'executor' runs, but tradeclient can't connect to it, and I can't figure out why. I downloaded Mini-fix and was able to send messages to executor, so I know that executor is working. I figure that the problem is with the tradeclient session settings. I've included both of them below, I was hoping someone could point out what's causing them to not communicate. They're both running on the same computer using port 56156.
--accceptor session.txt----
[DEFAULT]
ConnectionType=acceptor
ReconnectInterval=5
SenderCompID=EXEC
DefaultApplVerID=FIX.5.0
[SESSION]
BeginString=FIXT.1.1
TargetCompID=SENDER
HeartBtInt=5
#SocketConnectPort=
SocketAcceptPort=56156
SocketConnectHost=127.0.0.1
TransportDataDictionary=pathToXml/spec/FIX50.xml
StartTime=07:00:00
EndTime=23:00:00
FileStorePath=store
---- initiator session.txt ---
[DEFAULT]
ConnectionType=initiator
ReconnectInterval=5
SenderCompID=SENDER
DefaultApplVerID=FIX.5.0
[SESSION]
BeginString=FIXT.1.1
TargetCompID=EXEC
HeartBtInt=5
SocketConnectPort=56156
#SocketAcceptPort=56156
SocketConnectHost=127.0.0.1
TransportDataDictionary=pathToXml/spec/FIX50.xml
StartTime=07:00:00
EndTime=23:00:00
FileLogPath=log
FileStorePath=store
--------end------
Update: Thanks for the resonses... Turns out that my logfile directories didn't exist. Once I created them, they both started communicating. Must have been some logging error that didn't throw an exception, but disabled proper behavior.
Is there an error condition that I should be checking? I was relying on exceptions, but that's obviously not enough.
It doesn't seem to be config, check that your message sequence numbers are in synch, especially since you've been connecting to a different server using the same settings.
Try setting the TargetCompID and SenderCompID on the acceptor to *