Problems pushing images to lightsail containers registry - aws-cli

I'm starting to deploy an app in Lightsail Containers. I've created the service from the console and ran custom images from public repositories.
Now, I'm trying to push my own image from my host using the aws cli, but when I run push-container-image no results are shown in the console. No error, no successful response
Command:
aws lightsail push-container-image --region us-east-1 --service-name container-service-1 --image mystaticwebsite --profile rg --label mystaticwebsite --debug
Debug log:
2021-08-17 17:37:01,238 - MainThread - awscli.clidriver - DEBUG - CLI version: aws-cli/2.2.29 Python/3.8.8 Linux/5.4.0-80-generic exe/x86_64.ubuntu.20
2021-08-17 17:37:01,238 - MainThread - awscli.clidriver - DEBUG - Arguments entered to CLI: ['lightsail', 'push-container-image', '--region', 'us-east-1', '--service-name', 'container-service-1', '--image', 'mystaticwebsite', '--profile', 'rg', '--label', 'mystaticwebsite', '--debug']
2021-08-17 17:37:01,244 - MainThread - botocore.hooks - DEBUG - Event building-command-table.main: calling handler <function add_s3 at 0x7f86ddab7ee0>
2021-08-17 17:37:01,244 - MainThread - botocore.hooks - DEBUG - Event building-command-table.main: calling handler <function add_ddb at 0x7f86ddc784c0>
2021-08-17 17:37:01,245 - MainThread - botocore.hooks - DEBUG - Event building-command-table.main: calling handler <bound method BasicCommand.add_command of <class 'awscli.customizations.configure.configure.ConfigureCommand'>>
2021-08-17 17:37:01,245 - MainThread - botocore.hooks - DEBUG - Event building-command-table.main: calling handler <function change_name at 0x7f86ddc99ee0>
2021-08-17 17:37:01,245 - MainThread - botocore.hooks - DEBUG - Event building-command-table.main: calling handler <function change_name at 0x7f86ddca1ee0>
2021-08-17 17:37:01,245 - MainThread - botocore.hooks - DEBUG - Event building-command-table.main: calling handler <function alias_opsworks_cm at 0x7f86ddac7940>
2021-08-17 17:37:01,245 - MainThread - botocore.hooks - DEBUG - Event building-command-table.main: calling handler <function add_history_commands at 0x7f86ddc41280>
2021-08-17 17:37:01,245 - MainThread - botocore.hooks - DEBUG - Event building-command-table.main: calling handler <bound method BasicCommand.add_command of <class 'awscli.customizations.devcommands.CLIDevCommand'>>
2021-08-17 17:37:01,245 - MainThread - botocore.hooks - DEBUG - Event building-command-table.main: calling handler <function add_waiters at 0x7f86ddabfb80>
2021-08-17 17:37:01,245 - MainThread - botocore.loaders - DEBUG - Loading JSON file: /usr/aws-cli/v2/2.2.29/dist/awscli/data/cli.json
2021-08-17 17:37:01,247 - MainThread - botocore.hooks - DEBUG - Event top-level-args-parsed: calling handler <function resolve_types at 0x7f86ddb6bdc0>
2021-08-17 17:37:01,247 - MainThread - botocore.hooks - DEBUG - Event top-level-args-parsed: calling handler <function no_sign_request at 0x7f86ddb71940>
2021-08-17 17:37:01,247 - MainThread - botocore.hooks - DEBUG - Event top-level-args-parsed: calling handler <function resolve_verify_ssl at 0x7f86ddb718b0>
2021-08-17 17:37:01,247 - MainThread - botocore.hooks - DEBUG - Event top-level-args-parsed: calling handler <function resolve_cli_read_timeout at 0x7f86ddb71a60>
2021-08-17 17:37:01,247 - MainThread - botocore.hooks - DEBUG - Event top-level-args-parsed: calling handler <function resolve_cli_connect_timeout at 0x7f86ddb719d0>
2021-08-17 17:37:01,247 - MainThread - botocore.hooks - DEBUG - Event top-level-args-parsed: calling handler <built-in method update of dict object at 0x7f86dd9e0e40>
2021-08-17 17:37:01,248 - MainThread - botocore.session - DEBUG - Setting config variable for profile to 'rg'
2021-08-17 17:37:01,248 - MainThread - botocore.session - DEBUG - Setting config variable for region to 'us-east-1'
2021-08-17 17:37:01,248 - MainThread - awscli.clidriver - DEBUG - CLI version: aws-cli/2.2.29 Python/3.8.8 Linux/5.4.0-80-generic exe/x86_64.ubuntu.20 prompt/off
2021-08-17 17:37:01,248 - MainThread - awscli.clidriver - DEBUG - Arguments entered to CLI: ['lightsail', 'push-container-image', '--region', 'us-east-1', '--service-name', 'container-service-1', '--image', 'mystaticwebsite', '--profile', 'rg', '--label', 'mystaticwebsite', '--debug']
2021-08-17 17:37:01,248 - MainThread - botocore.hooks - DEBUG - Event session-initialized: calling handler <function add_timestamp_parser at 0x7f86ddab9550>
2021-08-17 17:37:01,248 - MainThread - botocore.hooks - DEBUG - Event session-initialized: calling handler <function register_uri_param_handler at 0x7f86de4d6e50>
2021-08-17 17:37:01,248 - MainThread - botocore.hooks - DEBUG - Event session-initialized: calling handler <function add_binary_formatter at 0x7f86dda280d0>
2021-08-17 17:37:01,248 - MainThread - botocore.hooks - DEBUG - Event session-initialized: calling handler <function no_pager_handler at 0x7f86de552280>
2021-08-17 17:37:01,248 - MainThread - botocore.hooks - DEBUG - Event session-initialized: calling handler <function inject_assume_role_provider_cache at 0x7f86de4be940>
2021-08-17 17:37:01,249 - MainThread - botocore.utils - DEBUG - IMDS ENDPOINT: http://169.254.169.254/
2021-08-17 17:37:01,251 - MainThread - botocore.credentials - DEBUG - Skipping environment variable credential check because profile name was explicitly set.
2021-08-17 17:37:01,251 - MainThread - botocore.hooks - DEBUG - Event session-initialized: calling handler <function attach_history_handler at 0x7f86ddc41160>
2021-08-17 17:37:01,251 - MainThread - botocore.hooks - DEBUG - Event session-initialized: calling handler <function inject_json_file_cache at 0x7f86ddc763a0>
2021-08-17 17:37:01,259 - MainThread - botocore.loaders - DEBUG - Loading JSON file: /usr/aws-cli/v2/2.2.29/dist/botocore/data/lightsail/2016-11-28/service-2.json
2021-08-17 17:37:01,282 - MainThread - botocore.hooks - DEBUG - Event building-command-table.lightsail: calling handler <function inject_commands at 0x7f86dda28ee0>
2021-08-17 17:37:01,282 - MainThread - botocore.hooks - DEBUG - Event building-command-table.lightsail: calling handler <function add_waiters at 0x7f86ddabfb80>
2021-08-17 17:37:01,288 - MainThread - botocore.hooks - DEBUG - Event building-command-table.lightsail_push-container-image: calling handler <function add_waiters at 0x7f86ddabfb80>
2021-08-17 17:37:01,289 - MainThread - botocore.hooks - DEBUG - Event load-cli-arg.custom.push-container-image.service-name: calling handler <awscli.paramfile.URIArgumentHandler object at 0x7f86dd1a1c10>
2021-08-17 17:37:01,289 - MainThread - botocore.hooks - DEBUG - Event process-cli-arg.custom.push-container-image: calling handler <awscli.argprocess.ParamShorthandParser object at 0x7f86de498160>
2021-08-17 17:37:01,289 - MainThread - botocore.hooks - DEBUG - Event load-cli-arg.custom.push-container-image.image: calling handler <awscli.paramfile.URIArgumentHandler object at 0x7f86dd1a1c10>
2021-08-17 17:37:01,289 - MainThread - botocore.hooks - DEBUG - Event process-cli-arg.custom.push-container-image: calling handler <awscli.argprocess.ParamShorthandParser object at 0x7f86de498160>
2021-08-17 17:37:01,289 - MainThread - botocore.hooks - DEBUG - Event load-cli-arg.custom.push-container-image.label: calling handler <awscli.paramfile.URIArgumentHandler object at 0x7f86dd1a1c10>
2021-08-17 17:37:01,289 - MainThread - botocore.hooks - DEBUG - Event process-cli-arg.custom.push-container-image: calling handler <awscli.argprocess.ParamShorthandParser object at 0x7f86de498160>
Any idea on why this is not working?
Regards!

I had this exact issue on Ubuntu 20.04 just now. After running strace on the command, it turned out that this was due to an EACCES (Permission Denied) error when running the lightsailctl plugin which wasn't making it to the console output.
11067 execve("/usr/local/bin/lightsailctl", ["lightsailctl", "--plugin", "--input-stdin"], 0x557d454e91c0 /* 68 vars */) = -1 EACCES (Permission denied)
I resolved the issue by making the lightsailctl plugin executable like so:
chmod +x /usr/local/bin/lightsailctl

I was also facing the same issue, but somehow I figured and able to push image on lightsail and able to deploy the container:-
aws lightsail push-container-image --region ap-west-1 --service-name invent --label inventory --image invent_app:latest

I have this step in Github Action:
run: |
curl "https://s3.us-west-2.amazonaws.com/lightsailctl/latest/linux-arm64/lightsailctl" -o "/usr/local/bin/lightsailctl"
sudo chmod +x /usr/local/bin/lightsailctl
The push command returns nothing, even with debug option, So I added lightsailctl --version, and got an error
/usr/local/bin/lightsailctl: cannot execute binary file: Exec format error
turn out I use the wrong binary, should be amd64 instead arm64

Related

Airflow Scheduler liveness probe crashing (version 2.0)

I have just upgraded my Airflow from 1.10.13 to 2.0. I am running it in Kubernetes (AKS Azure) with Kubernetes Executor. Unfortunately, I see my Scheduler getting killed every 15-20 mins due to Liveness probe failing. Hence my pod keeps restarting.
I had no issues in 1.10.13.
This is my Liveness probe:
import os
os.environ['AIRFLOW__CORE__LOGGING_LEVEL'] = 'ERROR'
os.environ['AIRFLOW__LOGGING__LOGGING_LEVEL'] = 'ERROR'
from airflow.jobs.scheduler_job import SchedulerJob
from airflow.utils.db import create_session
from airflow.utils.net import get_hostname
import sys
with create_session() as session:
job = session.query(SchedulerJob).filter_by(hostname=get_hostname()).order_by(
SchedulerJob.latest_heartbeat.desc()).limit(1).first()
sys.exit(0 if job.is_alive() else 1)
When I look in the scheduler logs I see the following:
[2021-02-16 12:18:21,883] {scheduler_job.py:309} DEBUG - Waiting for <ForkProcess name='DagFileProcessor489-Process' pid=12812 parent=9286 stopped exitcode=0>
[2021-02-16 12:18:22,228] {scheduler_job.py:933} DEBUG - No tasks to consider for execution.
[2021-02-16 12:18:22,232] {base_executor.py:147} DEBUG - 0 running task instances
[2021-02-16 12:18:22,232] {base_executor.py:148} DEBUG - 0 in queue
[2021-02-16 12:18:22,232] {base_executor.py:149} DEBUG - 32 open slots
[2021-02-16 12:18:22,232] {base_executor.py:158} DEBUG - Calling the <class 'airflow.executors.kubernetes_executor.KubernetesExecutor'> sync method
[2021-02-16 12:18:22,233] {kubernetes_executor.py:337} DEBUG - Syncing KubernetesExecutor
[2021-02-16 12:18:22,233] {kubernetes_executor.py:263} DEBUG - KubeJobWatcher alive, continuing
[2021-02-16 12:18:22,234] {dag_processing.py:383} DEBUG - Received message of type DagParsingStat
[2021-02-16 12:18:22,234] {dag_processing.py:383} DEBUG - Received message of type DagParsingStat
[2021-02-16 12:18:22,236] {dag_processing.py:383} DEBUG - Received message of type DagParsingStat
[2021-02-16 12:18:22,246] {scheduler_job.py:1390} DEBUG - Next timed event is in 0.143059
[2021-02-16 12:18:22,246] {scheduler_job.py:1392} DEBUG - Ran scheduling loop in 0.05 seconds
[2021-02-16 12:18:22,422] {scheduler_job.py:933} DEBUG - No tasks to consider for execution.
[2021-02-16 12:18:22,426] {base_executor.py:147} DEBUG - 0 running task instances
[2021-02-16 12:18:22,426] {base_executor.py:148} DEBUG - 0 in queue
[2021-02-16 12:18:22,426] {base_executor.py:149} DEBUG - 32 open slots
[2021-02-16 12:18:22,427] {base_executor.py:158} DEBUG - Calling the <class 'airflow.executors.kubernetes_executor.KubernetesExecutor'> sync method
[2021-02-16 12:18:22,427] {kubernetes_executor.py:337} DEBUG - Syncing KubernetesExecutor
[2021-02-16 12:18:22,427] {kubernetes_executor.py:263} DEBUG - KubeJobWatcher alive, continuing
[2021-02-16 12:18:22,439] {scheduler_job.py:1751} INFO - Resetting orphaned tasks for active dag runs
[2021-02-16 12:18:22,452] {settings.py:290} DEBUG - Disposing DB connection pool (PID 12819)
[2021-02-16 12:18:22,460] {scheduler_job.py:309} DEBUG - Waiting for <ForkProcess name='DagFileProcessor490-Process' pid=12819 parent=9286 stopped exitcode=0>
[2021-02-16 12:18:23,009] {settings.py:290} DEBUG - Disposing DB connection pool (PID 12826)
[2021-02-16 12:18:23,017] {scheduler_job.py:309} DEBUG - Waiting for <ForkProcess name='DagFileProcessor491-Process' pid=12826 parent=9286 stopped exitcode=0>
[2021-02-16 12:18:23,594] {settings.py:290} DEBUG - Disposing DB connection pool (PID 12833)
... Many of these Disposing DB connection pool entries here
[2021-02-16 12:20:08,212] {scheduler_job.py:309} DEBUG - Waiting for <ForkProcess name='DagFileProcessor675-Process' pid=14146 parent=9286 stopped exitcode=0>
[2021-02-16 12:20:08,916] {settings.py:290} DEBUG - Disposing DB connection pool (PID 14153)
[2021-02-16 12:20:08,924] {scheduler_job.py:309} DEBUG - Waiting for <ForkProcess name='DagFileProcessor676-Process' pid=14153 parent=9286 stopped exitcode=0>
[2021-02-16 12:20:09,475] {settings.py:290} DEBUG - Disposing DB connection pool (PID 14160)
[2021-02-16 12:20:09,484] {scheduler_job.py:309} DEBUG - Waiting for <ForkProcess name='DagFileProcessor677-Process' pid=14160 parent=9286 stopped exitcode=0>
[2021-02-16 12:20:10,044] {settings.py:290} DEBUG - Disposing DB connection pool (PID 14167)
[2021-02-16 12:20:10,053] {scheduler_job.py:309} DEBUG - Waiting for <ForkProcess name='DagFileProcessor678-Process' pid=14167 parent=9286 stopped exitcode=0>
[2021-02-16 12:20:10,610] {settings.py:290} DEBUG - Disposing DB connection pool (PID 14180)
[2021-02-16 12:23:42,287] {scheduler_job.py:746} INFO - Exiting gracefully upon receiving signal 15
[2021-02-16 12:23:43,290] {process_utils.py:95} INFO - Sending Signals.SIGTERM to GPID 9286
[2021-02-16 12:23:43,494] {process_utils.py:201} INFO - Waiting up to 5 seconds for processes to exit...
[2021-02-16 12:23:43,503] {process_utils.py:61} INFO - Process psutil.Process(pid=14180, status='terminated', started='12:20:09') (14180) terminated with exit code None
[2021-02-16 12:23:43,503] {process_utils.py:61} INFO - Process psutil.Process(pid=9286, status='terminated', exitcode=0, started='12:13:35') (9286) terminated with exit code 0
[2021-02-16 12:23:43,506] {process_utils.py:95} INFO - Sending Signals.SIGTERM to GPID 9286
[2021-02-16 12:23:43,506] {scheduler_job.py:1296} INFO - Exited execute loop
[2021-02-16 12:23:43,523] {cli_action_loggers.py:84} DEBUG - Calling callbacks: []
[2021-02-16 12:23:43,525] {settings.py:290} DEBUG - Disposing DB connection pool (PID 7)
I managed to fix my restart by setting up the following configs:
[kubernetes]
...
delete_option_kwargs = {"grace_period_seconds": 10}
enable_tcp_keepalive = True
tcp_keep_idle = 30
tcp_keep_intvl = 30
tcp_keep_cnt = 30
I have another Airflow instance running in AWS - Kubernetes. That one runs fine with any version, I realized the problem is with Azure Kubernetes, the rest api calls to the api server.
Just in case this helps someone else....
For mine case the problem was with the workers. Which had a db connection issues. Fixing it solved the issue for scheduler as well.
Note: Check the workers logs as well.

received signal exits program but does not call signal handler

Problem
After my program runs within the main thread, I send a signal.SIGINT signal to interrupt the program and cause an exit to occur. The program shuts down, however the signal handler is not called for some reason, I need the signal handler to call to run some cleanup code.
Background Info
Currently I'm running on:
- Windows 10
- Python 3.7.3 x64
I've tried sending multiple different signals such as SIGINT, SIGTERM and CTRL_C_EVENT from the builtin signals module. In all cases, the program flow is interrupted and the program exits, however the signal_handler is not called.
I'm aware that all signals are only received by the main function, so that is something I have tried to adhere to within the code.
Code
Where:
client = discordpy client object from the rewrite
init_sanic() = initialises the sanic web framework
class ForcedShutdown(Exception):
"""
Custom exception to be raised
"""
pass
def signal_handler(signal, frame):
print(f'signal received is {signal}')
raise ForcedShutdown
if(__name__ == '__main__'):
try:
signal.signal(signal.SIGINT, signal_handler)
client = DiscordBot()
bot_thread = Thread(target=lambda : client.run(setup_pars['CLIENT_TOKEN']))
api_thread = Thread(target=lambda : init_sanic())
threads = [api_thread, bot_thread]
for x in threads:
x.start()
while True:
time.sleep(100)
except (ForcedShutdown, SystemExit):
print('DO SHUTDOWN ACTIONS')
The output:
[2019-07-31 19:49:18 +0100] [11808] [DEBUG]
Sanic
Build Fast. Run Fast.
[2019-07-31 19:49:18 +0100] [11808] [INFO] Goin' Fast # http://0.0.0.0:8000
[2019-07-31 19:49:18 +0100] [11808] [WARNING] Sanic tried to use loop.add_signal_handler but it is not implemented on this platform.
[2019-07-31 19:49:18 +0100] [11808] [WARNING] Sanic tried to use loop.add_signal_handler but it is not implemented on this platform.
[2019-07-31 19:49:18 +0100] [11808] [INFO] Starting worker [11808]
Discord Bot Loaded
Code used to send the signal:
import os
import signal
os.kill(pid, signal.SIGINT)
Final output:
Process finished with exit code 2
Expected Output
While the code exits as expected, the outputs is:
[2019-07-31 19:49:18 +0100] [11808] [DEBUG]
Sanic
Build Fast. Run Fast.
[2019-07-31 19:49:18 +0100] [11808] [INFO] Goin' Fast # http://0.0.0.0:8000
[2019-07-31 19:49:18 +0100] [11808] [WARNING] Sanic tried to use loop.add_signal_handler but it is not implemented on this platform.
[2019-07-31 19:49:18 +0100] [11808] [WARNING] Sanic tried to use loop.add_signal_handler but it is not implemented on this platform.
[2019-07-31 19:49:18 +0100] [11808] [INFO] Starting worker [11808]
Discord Bot Loaded
Process finished with exit code 2
Whereas the expected final output is:
[2019-07-31 19:49:18 +0100] [11808] [DEBUG]
Sanic
Build Fast. Run Fast.
[2019-07-31 19:49:18 +0100] [11808] [INFO] Goin' Fast # http://0.0.0.0:8000
[2019-07-31 19:49:18 +0100] [11808] [WARNING] Sanic tried to use loop.add_signal_handler but it is not implemented on this platform.
[2019-07-31 19:49:18 +0100] [11808] [WARNING] Sanic tried to use loop.add_signal_handler but it is not implemented on this platform.
[2019-07-31 19:49:18 +0100] [11808] [INFO] Starting worker [11808]
Discord Bot Loaded
DO SHUTDOWN ACTIONS
Process finished with exit code 2
Thanks for any help!

How to execute gremlin query with mogwai

Im trying to query a titan db 0.5.4 via mogwai, but when I run the following script i get the error: rexpro.exceptions.RexProScriptException: transaction is not open
and I found the same question here
P.S there is no tag for mogwai
script:
#!/usr/bin/env python3
from mogwai.connection import execute_query, setup
con = setup('127.0.0.1', graph_name="bio4j", username="re", password="re")
results = execute_query("2 * a",params={"a":2}, connection= con)
print(results)
results = execute_query("bio4j.E",params={}, connection= con)
print(results)
log:
$ ./bin/rexster.sh --start
0 [main] INFO com.tinkerpop.rexster.Application - .:Welcome to Rexster:.
93 [main] INFO com.tinkerpop.rexster.server.RexsterProperties - Using [/Users/Phoenix/Dropbox/Graph4Bio/Titan/rexhome/config/rexster.xml] as configuration source.
102 [main] INFO com.tinkerpop.rexster.Application - Rexster is watching [/Users/Phoenix/Dropbox/Graph4Bio/Titan/rexhome/config/rexster.xml] for change.
730 [main] INFO com.thinkaurelius.titan.graphdb.configuration.GraphDatabaseConfiguration - Generated unique-instance-id=0a69045d1736-AngryMac-local1
804 [main] INFO com.thinkaurelius.titan.diskstorage.Backend - Initiated backend operations thread pool of size 8
905 [main] INFO com.thinkaurelius.titan.diskstorage.log.kcvs.KCVSLog - Loaded unidentified ReadMarker start time Timepoint[1455128079919000 μs] into com.thinkaurelius.titan.diskstorage.log.kcvs.KCVSLog$MessagePuller#302c971f
908 [main] INFO com.tinkerpop.rexster.RexsterApplicationGraph - Graph [bio4j] - configured with allowable namespace [tp:gremlin]
932 [main] INFO com.tinkerpop.rexster.config.GraphConfigurationContainer - Graph bio4j - titangraph[berkeleyje:/Users/Phoenix/Dropbox/Graph4Bio/Bio4j/bio4j] loaded
939 [main] INFO com.tinkerpop.rexster.server.metrics.HttpReporterConfig - Configured HTTP Metric Reporter.
941 [main] INFO com.tinkerpop.rexster.server.metrics.ConsoleReporterConfig - Configured Console Metric Reporter.
2058 [main] INFO com.tinkerpop.rexster.server.HttpRexsterServer - HTTP/REST thread pool configuration: kernal[4 / 4] worker[8 / 8]
2060 [main] INFO com.tinkerpop.rexster.server.HttpRexsterServer - Using org.glassfish.grizzly.strategies.LeaderFollowerNIOStrategy IOStrategy for HTTP/REST.
2160 [main] INFO com.tinkerpop.rexster.server.HttpRexsterServer - Rexster Server running on: [http://localhost:8182]
2160 [main] INFO com.tinkerpop.rexster.server.RexProRexsterServer - Using org.glassfish.grizzly.strategies.LeaderFollowerNIOStrategy IOStrategy for RexPro.
2160 [main] INFO com.tinkerpop.rexster.server.RexProRexsterServer - RexPro thread pool configuration: kernal[4 / 4] worker[8 / 8]
2162 [main] INFO com.tinkerpop.rexster.server.RexProRexsterServer - Rexster configured with [DefaultSecurity].
2163 [main] INFO com.tinkerpop.rexster.server.RexProRexsterServer - RexPro Server bound to [0.0.0.0:8184]
2177 [main] INFO com.tinkerpop.rexster.server.ShutdownManager - Bound shutdown socket to /127.0.0.1:8183. Starting listener thread for shutdown requests.
152568 [Grizzly(2) SelectorRunner] INFO com.tinkerpop.rexster.protocol.EngineController - ScriptEngineManager has factory for: ECMAScript
152568 [Grizzly(2) SelectorRunner] INFO com.tinkerpop.rexster.protocol.EngineController - ScriptEngineManager has factory for: gremlin-groovy
152568 [Grizzly(2) SelectorRunner] INFO com.tinkerpop.rexster.protocol.EngineController - Registered ScriptEngine for: gremlin-groovy
152569 [Grizzly(2) SelectorRunner] INFO com.tinkerpop.rexster.protocol.EngineHolder - Initializing gremlin-groovy engine with additional imports.
153259 [Grizzly(2) SelectorRunner] INFO com.tinkerpop.rexster.protocol.EngineHolder - ScriptEngine initializing with a custom script
154074 [Grizzly(2) SelectorRunner] INFO com.tinkerpop.rexster.protocol.EngineController - ScriptEngineManager has factory for: Groovy
154076 [Grizzly(2) SelectorRunner] INFO com.tinkerpop.rexster.protocol.session.RexProSessions - RexPro Session created: a2b416ce-75ea-4ecb-9835-b287162c90cb
154354 [Grizzly(4)] INFO com.tinkerpop.rexster.protocol.session.RexProSessions - Try to destroy RexPro Session: a2b416ce-75ea-4ecb-9835-b287162c90cb
154355 [Grizzly(4)] INFO com.tinkerpop.rexster.protocol.session.RexProSessions - RexPro Session destroyed or doesn't otherwise exist: a2b416ce-75ea-4ecb-9835-b287162c90cb
154356 [Grizzly(5)] INFO com.tinkerpop.rexster.protocol.session.RexProSessions - RexPro Session created: 5b8a669f-615d-4f84-9d1e-2d10624347f0
154525 [Grizzly(7)] WARN com.tinkerpop.rexster.protocol.server.ScriptServer - Could not process script [bio4j.E] for language [groovy] on session [[B#6634722f] and request [[B#68f38099]
154527 [Grizzly(8)] INFO com.tinkerpop.rexster.protocol.session.RexProSessions - Try to destroy RexPro Session: 5b8a669f-615d-4f84-9d1e-2d10624347f0
154527 [Grizzly(8)] INFO com.tinkerpop.rexster.protocol.session.RexProSessions - RexPro Session destroyed or doesn't otherwise exist: 5b8a669f-615d-4f84-9d1e-2d10624347f0
154529 [Grizzly(1)] INFO com.tinkerpop.rexster.protocol.session.RexProSessions - Try to destroy RexPro Session: 00000000-0000-0000-0000-000000000000
154529 [Grizzly(1)] INFO com.tinkerpop.rexster.protocol.session.RexProSessions - RexPro Session destroyed or doesn't otherwise exist: 00000000-0000-0000-0000-000000000000
Maintainer of mogwai here.
What version of mogwai are you using? in 0.7.7 there is no return value for setup method and the connection object should not be passed around. In fact when you call setup it creates a connection pool (a synchronous rexpro connection pool since there was no concurrency option specified). So in general, just call setup once for the life of your app and you can use execute query without any references.
Also this message in particular stands out:
154525 [Grizzly(7)] WARN com.tinkerpop.rexster.protocol.server.ScriptServer - Could not process script [bio4j.E] for language [groovy] on session [[B#6634722f] and request [[B#68f38099]
Is your graph configured with a graph name of "bio4j"? The default titan graph name is "graph" and the default graph object name mogwai uses is "g". If you have a graph name of "bio4j" you wouldn't reference this directly, you'd use the graph object name associated to the transaction. You can think of a graph-name as a database name in a SQL database, and the graph object being the transactional reference to said database. This is configured in the xml configuration file when starting titan. Particularly:
<graphs>
<graph>
<graph-name>graph</graph-name>
....
</graph>
</graphs>
So assuming you changed that from "graph" to "bio4j" and left the default graph_obj_name in the setup function as "g", then your query should read "g.E".

Selenium test execution via jenkins on linux machine without GUI (CLI-only) - HEADLESS MODE

This is regarding Selenium Automation Testing. I have a Jenkins job setup for some test executions.Jenkins is setup on a Ubuntu machine without GUI (CLI Only).
So when I run the scripts seems like it can't find the web browser obviously.
This job is working perfectly fine in windows. In Windows I get like this result.
Window Successful Result
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running TestSuite
06/08/2015 00:04:47,996 INFO [main] (BasicTestObject.java:251) - ======BEGIN Test workflow============
06/08/2015 00:04:48,002 INFO [main] (BasicTestObject.java:252) - BEGIN Test: MlpBvt
06/08/2015 00:04:48,002 INFO [main] (BasicTestObject.java:253) - ======BEGIN Test workflow============
06/08/2015 00:04:58,862 DEBUG [main] (DefaultUIDriver.java:300) - Opened url: http://mlpdemo.qaprod.ecollege.com/
06/08/2015 00:04:58,912 INFO [main] (BasicTestObject.java:296) - -------------BEGIN Test Method-------------------
06/08/2015 00:04:58,913 INFO [main] (BasicTestObject.java:297) - BEGIN Test Method: verifyAdminLogin
06/08/2015 00:04:58,913 INFO [main] (BasicTestObject.java:298) - -------------BEGIN Test Method-------------------
06/08/2015 00:04:58,969 DEBUG [main] (DefaultUIElement.java:980) - Waiting 60000ms for element to be displayed [Locator = {By.xpath: //input[#id='clientname']}]
06/08/2015 00:04:59,058 DEBUG [main] (DefaultUIElement.java:538) - Element is displayed [Locator = {By.xpath: //input[#id='clientname']}]
06/08/2015 00:04:59,059 DEBUG [main] (DefaultUIElement.java:992) - After 89ms, element is displayed [Locator = {By.xpath: //input[#id='clientname']}]
On Linux I get like this
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running TestSuite
06/08/2015 00:18:46,834 INFO [main] (BasicTestObject.java:251) - ======BEGIN Test workflow============
06/08/2015 00:18:46,839 INFO [main] (BasicTestObject.java:252) - BEGIN Test: MlpBvt
06/08/2015 00:18:46,839 INFO [main] (BasicTestObject.java:253) - ======BEGIN Test workflow============
06/08/2015 00:18:46,998 DEBUG [main] (CapturePageOnFailureListener.java:186) - CapturePageOnFailure found 2 parameters
06/08/2015 00:18:47,002 WARN [main] (DebugUIDriver.java:311) - Called quit() on debugDriver containing null uiDriver
06/08/2015 00:18:47,025 INFO [main] (BasicTestObject.java:304) - -------------END Test Method-------------------
06/08/2015 00:18:47,026 INFO [main] (BasicTestObject.java:305) - END Test Method: verifyAdminLogin
06/08/2015 00:18:47,026 INFO [main] (BasicTestObject.java:306) - -------------END Test Method-------------------
06/08/2015 00:18:47,031 INFO [main] (BasicTestObject.java:304) - -------------END Test Method-------------------
06/08/2015 00:18:47,032 INFO [main] (BasicTestObject.java:305) - END Test Method: VerifyProfessorLogin
06/08/2015 00:18:47,032 INFO [main] (BasicTestObject.java:306) - -------------END Test Method-------------------
06/08/2015 00:18:47,036 INFO [main] (BasicTestObject.java:304) - -------------END Test Method-------------------
06/08/2015 00:18:47,036 INFO [main] (BasicTestObject.java:305) - END Test Method: VerifyStudentLogin
06/08/2015 00:18:47,037 INFO [main] (BasicTestObject.java:306) - -------------END Test Method-------------------
06/08/2015 00:18:47,038 INFO [main] (BasicTestObject.java:283) - ======END Test workflow============
06/08/2015 00:18:47,038 INFO [main] (BasicTestObject.java:284) - END Test: MlpBvt
06/08/2015 00:18:47,040 INFO [main] (BasicTestObject.java:285) - ======END Test workflow============
06/08/2015 00:18:47,100 DEBUG [main] (ProcessTool.java:36) - Getting current tool for LINUX
06/08/2015 00:18:47,100 WARN [main] (ProcessTool.java:40) - Could not find ProcessTool for LINUX
06/08/2015 00:18:47,101 WARN [main] (ProcessTool.java:88) - There was no ProcessTool for LINUX
06/08/2015 00:18:47,101 DEBUG [main] (ProcessTool.java:115) - process count for There was no ProcessTool for LINUX:1
Tests run: 12, Failures: 1, Errors: 0, Skipped: 11, Time elapsed: 1.976 sec <<< FAILURE!
Results :
Failed tests:
It is mentioned as
06/08/2015 00:18:47,002 WARN [main] (DebugUIDriver.java:311) - Called quit() on debugDriver containing null uiDriver
Please provide me some technical specialities regarding this matter. Can I run this job in linux ? Please help me out
Well for unix systems you have to use Xvfb to run tests in headless mode, for jenkins you can use xvfb plugin
Simple example how to open firefox in headless mode
from xvfbwrapper import Xvfb
from selenium import webdriver
xf = Xvfb() # xf = Xvfb(1920, 1080) - will create virtual display with 1920x1080 size
xf.start()
# browser won't appear
driver = webdriver.Firefox()
driver.get("http://google.com")

YouCompleteMe freezes when used with python-mode

When I type self. a popup will automatically select the first one and will never change no matter what input is given. For example, match 1 of 52 is shown.
After <Esc> is used to return to normal mode and enter insert mode again then YouCompleteMe works correctly again. It will show Back at Original and automatically updates with different input.
OS: Kubuntu 13.04
Vim version: 7.4.5
Possibly related plugin: ultisnips
Log:
~/vimConf  ± master ●  2014-02-12 16:37:37,251 - DEBUG - Global extra conf not loaded or no function YcmCorePreload
serving on localhost:
2014-02-12 16:37:38,931 - INFO - Received health request
2014-02-12 16:37:38,935 - INFO - Received event notification
2014-02-12 16:37:38,935 - DEBUG - Event name: BufferVisit
2014-02-12 16:37:39,012 - INFO - Received event notification
2014-02-12 16:37:39,013 - DEBUG - Event name: FileReadyToParse
2014-02-12 16:37:39,013 - INFO - Adding buffer identifiers for file: /home/kamel/vimConf/my_configs.vim
2014-02-12 16:37:39,086 - INFO - Received event notification
2014-02-12 16:37:39,087 - DEBUG - Event name: BufferVisit
2014-02-12 16:37:39,147 - INFO - Received event notification
2014-02-12 16:37:39,148 - DEBUG - Event name: BufferVisit
2014-02-12 16:37:39,149 - INFO - Received event notification
2014-02-12 16:37:39,150 - DEBUG - Event name: FileReadyToParse
2014-02-12 16:37:39,150 - INFO - Adding buffer identifiers for file: /home/kamel/vimConf/my_configs.vim
2014-02-12 16:37:50,482 - INFO - Received event notification
2014-02-12 16:37:50,483 - DEBUG - Event name: BufferVisit
2014-02-12 16:37:50,533 - INFO - Received event notification
2014-02-12 16:37:50,534 - DEBUG - Event name: BufferVisit
2014-02-12 16:37:50,545 - INFO - Received event notification
2014-02-12 16:37:50,545 - DEBUG - Event name: FileReadyToParse
2014-02-12 16:37:50,546 - INFO - Adding buffer identifiers for file: /home/kamel/labola/src/app/mixin/alert.py
2014-02-12 16:37:50,711 - INFO - Received event notification
2014-02-12 16:37:50,712 - DEBUG - Event name: BufferVisit
2014-02-12 16:37:50,748 - INFO - Received event notification
2014-02-12 16:37:50,749 - DEBUG - Event name: BufferVisit
2014-02-12 16:37:50,750 - INFO - Received event notification
2014-02-12 16:37:50,752 - DEBUG - Event name: FileReadyToParse
2014-02-12 16:37:50,752 - INFO - Adding buffer identifiers for file: /home/kamel/labola/src/app/mixin/alert.py
2014-02-12 16:37:57,893 - INFO - Received completion request
2014-02-12 16:37:57,894 - DEBUG - Using filetype completion: False
2014-02-12 16:37:58,055 - INFO - Received completion request
2014-02-12 16:37:58,056 - DEBUG - Using filetype completion: False
2014-02-12 16:37:58,184 - INFO - Received completion request
2014-02-12 16:37:58,184 - DEBUG - Using filetype completion: False
2014-02-12 16:37:58,297 - INFO - Received completion request
2014-02-12 16:37:58,298 - DEBUG - Using filetype completion: False
2014-02-12 16:39:37,853 - INFO - Received event notification
2014-02-12 16:39:37,853 - DEBUG - Event name: FileReadyToParse
2014-02-12 16:39:37,853 - INFO - Adding buffer identifiers for file: /home/kamel/labola/src/app/mixin/alert.py
Screenshot:
Fixed:
It is due to the python-mode autocomplete. When
let g:pymode_rope_complete_on_dot = 0
is set in the .vimrc, it is solved!
It is due to the conflict with python-mode autocomplete.
let g:pymode_rope_complete_on_dot = 0
in the .vimrc, it is solved!
As it is not recommended to use auto completion of pymode and YouComplateMe at the same time, use the following to command to cancel the pymode completion totally.
let g:pymode_rope_completion = 0

Resources