I have these tmux sessions:
0: 2 windows (created Mon Mar 14 21:17:49 2022)
devel: 1 windows (created Mon Mar 14 22:58:39 2022)
notes: 6 windows (created Mon Mar 14 22:58:26 2022)
tasks: 4 windows (created Mon Mar 14 22:58:45 2022)
Notice that none of these sessions are showing (attached) next to them. Running ps | ax | grep tmux shows no other attached sessions either.
However, if I attach to tasks with tmux attach -d -t tasks, the first window in the session shows a bunch of empty space.
I tried to set aggressive resize but that did not help. Also tried tmux detach -a but that did nothing either.
Related
I notice (via byobu ls or "Move focus among sessions" Alt-Up/Down) that there are some sessions that begin with underscore and I am sure I have not named the sessions like that :) They look as if they are linked to other sessions that do no start with underscore, because if I add or remove windows from the linked session, the ones starting with underscore reflect the change.
I also notice in the byobu ls that sessions are part of something called "group".
So I'd like to ask:
what are the sessions that begin with underscore and if I can
avoid cycling through them
what is a group in byobu (in case it's related)
I have searched the man page and the help page for "group" or "underscore" but I couldn't find something. I also watched all of https://youtu.be/NawuGmcvKus but didn't see anything mentioned.
Example output:
ubuntu:~ $ byobu ls
apple: 1 windows (created Wed Jun 12 09:26:46 2019) [190x44] (group carrot)
banana: 2 windows (created Wed Jun 12 10:14:10 2019) [190x44]
_carrot-17655: 1 windows (created Wed Jun 12 09:29:55 2019) [190x43] (group carrot) (attached)
_egg-11803: 7 windows (created Wed Jun 12 09:19:28 2019) [190x44] (group egg)
fig: 7 windows (created Wed Jun 12 09:15:27 2019) [190x44] (group egg)
My environment:
ubuntu:~ $ byobu --version
byobu version 5.125
tmux 2.6
ubuntu:~ $ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.2 LTS
Release: 18.04
Codename: bionic
I'm trying to use dcm4che for downloading images from the free http://www.dicomserver.co.uk/. I've cloned and checked out the 5.13.2 version and built it using mvn install. Now when I go into the dcm4che-assembly/target/dcm4che-5.13.2-bin/dcm4che-5.13.2/bin directory and try to download a StudyInstanceUID:
./movescu -c DCMQRSCP#www.dicomserver.co.uk:104 -m StudyInstanceUID=1.2.826.0.1.3680043.11.105 --dest STORESCP
I get the error:
...
(0000,0902) LO [Unknown Move Destination: STORESCP] ErrorComment
...
The error indicates that it can't connect to the the receiver. I've tried to run:
./storescp -b STORESCP:11112
without much success. I've also tried to run the dcmqrscp with similar outcomes.
My humble request: Please provide a working example of the movescu.
Details
I can get the findscu to work without issues, e.g.:
./findscu -c DCMQRSCP#www.dicomserver.co.uk:104 -m StudyInstanceUID=1.2.826.0.1.3680043.11.105 -r PatientID
gives:
(0008,0005) CS [] SpecificCharacterSet
(0008,0052) CS [STUDY] QueryRetrieveLevel
(0008,0054) AE [DCMQRSCP] RetrieveAETitle
(0010,0020) LO [PAT004] PatientID
(0020,000D) UI [1.2.826.0.1.3680043.11.105] StudyInstanceUID
Similarly the getscu command seems to work:
>./getscu -c DCMQRSCP#www.dicomserver.co.uk:104 -m StudyInstanceUID=1.2.826.0.1.3680043.11.105
Creates the following DICOM files:
ls 1* -lh
-rw-rw-r-- 1 max max 12M jul 7 12:16 1.2.276.0.7230010.3.1.4.39332053.7432.1527748041.31
-rw-rw-r-- 1 max max 150K jul 7 12:17 1.2.276.0.7230010.3.1.4.8323329.11391.1527939718.955155
-rw-rw-r-- 1 max max 6,0M jul 7 12:17 1.2.826.0.1.3680043.9.6384.2.2087.20180322152557.400.100
-rw-rw-r-- 1 max max 6,0M jul 7 12:17 1.2.826.0.1.3680043.9.6384.2.2087.20180322152557.400.104
-rw-rw-r-- 1 max max 6,0M jul 7 12:17 1.2.826.0.1.3680043.9.6384.2.2087.20180322152557.400.108
-rw-rw-r-- 1 max max 6,0M jul 7 12:17 1.2.826.0.1.3680043.9.6384.2.2087.20180322152557.400.112
-rw-rw-r-- 1 max max 6,0M jul 7 12:16 1.2.826.0.1.3680043.9.6384.2.2087.20180322152557.400.80
-rw-rw-r-- 1 max max 6,0M jul 7 12:17 1.2.826.0.1.3680043.9.6384.2.2087.20180322152557.400.84
-rw-rw-r-- 1 max max 6,0M jul 7 12:17 1.2.826.0.1.3680043.9.6384.2.2087.20180322152557.400.88
-rw-rw-r-- 1 max max 6,0M jul 7 12:17 1.2.826.0.1.3680043.9.6384.2.2087.20180322152557.400.92
-rw-rw-r-- 1 max max 6,0M jul 7 12:17 1.2.826.0.1.3680043.9.6384.2.2087.20180322152557.400.96
Lastly, I'm sorry if this question falls into the duplicate category. After spending days without finding a working movescu example on either StackOverflow or the dcm4che-forum, I've given up searching. The goal is to have an example to use so that I can modify the underlying Java code for my own purposes. Also let me know if you're interested in the entire movescu dump.
Update
After Tarmo's helpful tip I tried to (1) use the correct AE & port and (2) change to Orthanc. Unfortunately I still can't retrieve an image from the dicomserver.co.uk but the Orthanc solution worked.
Below is the summary of the outcomes:
Alt. 1: Port & port compliance
As it seems part of my issue was RTFM-related:
Use any calling and called AE titles you like (making them specific to you will assist if logs need to be examined), but if you wish to use C-MOVE, ensure that the calling and destination AETs are the same, and that you listen on port 104.
My first attempt was to align the two AE-titles:
./movescu -c STORESCP#www.dicomserver.co.uk:104 -m StudyInstanceUID=1.2.826.0.1.3680043.11.105 --dest STORESCP
This does not work and it turns out that the destination port is random. At both ends (server log + local) one can find that the port was:
14:23:47,539 INFO - MOVESCU->APA(1): close Socket
[addr=www.dicomserver.co.uk/88.202.185.144,port=104,localport=57985]
The localport changes between each attempt. Things that I've tried so far:
Variants of --dest (1) STORESCP:104, (2) STORESCP$localhost:104, (3) other AE-titles
Starting up a SCP through sudo ./dcmqrscp -b STORESCP:104 --dicomdir /home/max/tmp/dcm (the sudo is due to the low port number) and calling with AE-title only as dest
Same as above but with the -b option: ./movescu -c STORESCP#www.dicomserver.co.uk:104 -b STORESCP#localhost:104 -m StudyInstanceUID=1.2.826.0.1.3680043.11.105 --dest STORESCP
Same as above without the SCP and with my local IP/external IP (no firewall changes made)
I've also tried USB-tethering through my phone to circumvent the router but the phone operated at IPv6 and not v4
It would still be nice to know how to set this up as it could be quite useful. My guess is that since C-MOVE provides the raw IP-address to the dicomserver the 104-port needs to be forwarded to the current machine. Being new to the DICOM-protocol I find many of these features somewhat cryptic...
Alt 2: Local Orthanc server (WORKS!)
Here's the full set-up for anyone that wants to get a test system up and running (using Ubuntu 18.04):
sudo apt install orthanc & check that the service is started systemsctl status orthanc.service
In /etc/orthanc/orthanc.json uncomment the line with: "sample" : [ "STORESCP", "localhost", 2000 ] and restart the server systemsctl restart orthanc.service
Go to http://localhost:8042 (unless you've changed the web-port at /etc/orthanc/orthanc.json)
Navigate into upload and find a dcm-file for uploading (you can find dcm-files to download here: https://www.dicomlibrary.com/ or you can use the getscu from above)
Drag and drop the dcm-file into http://localhost:8042/app/explorer.html#upload + press "Start the upload"
Go to patients and get the new StudyInstanceUID for the uploaded image
Start a SCP-service with the STORESCP and 2000 port that you allowed in the /etc/orthanc/orthanc.json, e.g. ./dcmqrscp -b STORESCP:2000 --dicomdir /home/max/tmp/dcm
Call the movescu with the -b to the above SCP with the new StudyInstanceUID (shortened below for readability), e.g.:
./movescu
-c ORTHANC#localhost:4242
-m StudyInstanceUID=1.2.826.0.1.3680043.8.....
-b STORESCP#localhost:2000
--dest STORESCP
And that's it!
Please read the C-MOVE information on the http://www.dicomserver.co.uk/ homepage again to figure out, how to set up your query. Your syntax for the command is correct, but some details are wrong.
Basically you need two things:
Your calling AE title must be the same as the destination AE title. You have them different at the moment
Your storescp must be accessible from the public internet on the same port, that you used to connect to dicomserver.co.uk, in your example that is 104. Their server needs to make a new TCP connection back to your computer for it to work.
I think it would be easier to install a lightweight PACS on your local machine to test your applications with (e.g. Orthanc). Getting DICOM C-MOVE to work over public internet is asking for trouble in my opinion.
I've encountered a problem with deploying my shiny app on linux Ubuntu 16.04 LTS.
After I run sudo systemctl start shiny-server, and open up my browser heading to http://192.168..*:3838/StockVis/, the web page greys out in a second.
I found some warnings in the web console as below, and survey some information on the web for like two weeks, but still have no solution. :(
***"Thu Feb 16 2017 12:20:49 GMT+0800 (CST) [INF]: Connection opened. http://192.168.**.***:3838/StockVis/"
Thu Feb 16 2017 12:20:49 GMT+0800 (CST) [DBG]: Open channel 0
The application unexpectedly exited.
Diagnostic information is private. Please ask your system admin for permission if you need to check the R logs.
**Thu Feb 16 2017 12:20:50 GMT+0800 (CST) [INF]: Connection closed. Info: {"type":"close","code":4503,"reason":"The application unexpectedly exited","wasClean":true}
Thu Feb 16 2017 12:20:50 GMT+0800 (CST) [DBG]: SockJS connection closed
Thu Feb 16 2017 12:20:50 GMT+0800 (CST) [DBG]: Channel 0 is closed
Thu Feb 16 2017 12:20:50 GMT+0800 (CST) [DBG]: Removed channel 0, 0 left*****
Please kindly give some suggestions to move on.
This can indicate something in your R code is causing an error. As that R error could be anything, this answer is to help you gather that info. The browser console messages will not tell you what that is. In order to access the error, you need to configure Shiny to not delete the log upon exiting the application.
Assuming you have sudo access:
$ sudo vi /etc/shiny-server/shiny-server.conf
Place the following line in the file after run_as shiny; :
preserve_logs true;
Restart shiny:
sudo systemctl restart shiny-server
Reload your Shiny app.
In the var/log/shiny-sever/ directory there will be a log file with your application name. Viewing that file will give you more information on what is going on.
Warning. After you are done, take out the preserve_logs true; line in the conf file and restart Shiny. If not, you will start generating a bunch of log files you don't want.
I have a simple 4 server setup running jMeter (3 slaves, 1 master):
Slave 1: 10.135.62.18 running ./jmeter-server -Djava.rmi.server.hostname=10.135.62.18
Slave 2: 10.135.62.22 running ./jmeter-server -Djava.rmi.server.hostname=10.135.62.22
Slave 3: 10.135.62.20 running ./jmeter-server -Djava.rmi.server.hostname=10.135.62.20
Master: 10.135.62.11 with remote_hosts=10.135.62.18,10.135.62.22,10.135.62.20
I start the test with ./jmeter -n -t /root/jmeter/simple.jmx -l /root/jmeter/result.jtl -r
With the following output:
Writing log file to: /root/apache-jmeter-3.0/bin/jmeter.log
Creating summariser <summary>
Created the tree successfully using /root/jmeter/simple.jmx
Configuring remote engine: 10.135.62.18
Configuring remote engine: 10.135.62.22
Configuring remote engine: 10.135.62.20
Starting remote engines
Starting the test # Mon Aug 29 11:22:38 UTC 2016 (1472469758410)
Remote engines have been started
Waiting for possible Shutdown/StopTestNow/Heapdump message on port 4445
The Slaves print:
Starting the test on host 10.135.62.22 # Mon Aug 29 11:22:39 UTC 2016 (1472469759257)
Finished the test on host 10.135.62.22 # Mon Aug 29 11:22:54 UTC 2016 (1472469774871)
Starting the test on host 10.135.62.18 # Mon Aug 29 11:22:39 UTC 2016 (1472469759519)
Finished the test on host 10.135.62.18 # Mon Aug 29 11:22:57 UTC 2016 (1472469777173)
Starting the test on host 10.135.62.20 # Mon Aug 29 11:22:39 UTC 2016 (1472469759775)
Finished the test on host 10.135.62.20 # Mon Aug 29 11:22:56 UTC 2016 (1472469776670)
Unfortunately the master waits for messages on port 4445 indefinitely event though all slaves finished the test.
Is there anything I have missed?
I figured it out myself just before submitting the question. I guess the solution could be useful nonetheless:
Once I start the test (on the main server) with this:
./jmeter -n -t /root/jmeter/simple.jmx -l /root/jmeter/result.jtl -r -Djava.rmi.server.hostname=10.135.62.11 -Dclient.rmi.localport=4001
It works just fine. I wonder why the documentation doesn't mention something like this.
I have a Deis cluster running in a (hopefully-soon-to-be) Production environment, with quite a few different apps using the Dockerfile deployment method. Everything's running fine, but promoting this system to a true Production environment (that is, converting the DNS over) isn't really possible unless I can get some worthwhile log output. Using the standard Deis logging platform, here's some sample output of a Web hit (with a bit more output, for context):
Feb 10 01:46:04 ip-10-21-2-154.ec2.internal systemd[1]: Starting Generate /run/coreos/motd...
Feb 10 01:46:04 ip-10-21-2-154.ec2.internal systemd[1]: Started Generate /run/coreos/motd.
Feb 10 01:46:08 ip-10-21-2-154.ec2.internal docker[1867]: [info] GET /containers/json
Feb 10 01:46:08 ip-10-21-2-154.ec2.internal docker[1867]: [215084df] +job containers()
Feb 10 01:46:08 ip-10-21-2-154.ec2.internal docker[1867]: [215084df] -job containers() = OK (0)
Feb 10 01:46:09 ip-10-21-2-154.ec2.internal sh[1316]: 2015/02/10 01:46:09 set /deis/services/production-web/production-web_v8.cmd.1 -> 10.21.2.154:49409
Feb 10 01:46:12 ip-10-21-2-154.ec2.internal sh[9844]: 2015-02-10 01:46:12.302721 7f213ae14700 0 mon.ip-10-21-2-154.ec2.internal#4(peon).data_health(58) update_stats avail 80% total 102400 MB, used 17621 MB, avail 82542 MB
Feb 10 01:46:18 ip-10-21-2-154.ec2.internal docker[1867]: [info] GET /containers/json
Feb 10 01:46:18 ip-10-21-2-154.ec2.internal docker[1867]: [215084df] +job containers()
Feb 10 01:46:18 ip-10-21-2-154.ec2.internal docker[1867]: [215084df] -job containers() = OK (0)
Feb 10 01:46:19 ip-10-23-1-151.ec2.internal sh[1521]: [INFO] - [10/Feb/2015:01:46:27 +0000] - 10.21.2.179 - - - 200 - "GET / HTTP/1.1" - 4927 - "-" - "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari/537.36" - "~^production-web\x5C.(?<domain>.+)$" - 10.21.2.154:49409
Feb 10 01:46:19 ip-10-21-2-154.ec2.internal sh[8468]: ===========
Feb 10 01:46:19 ip-10-21-2-154.ec2.internal sh[8468]: HIT TRACKER
Feb 10 01:46:19 ip-10-21-2-154.ec2.internal sh[8468]: SLUG: public/javascripts/bundle.js
Feb 10 01:46:19 ip-10-21-2-154.ec2.internal sh[8468]: ===========
That contains alot of platform information – which is great to have, if only I could filter it out. The problem is all the lines for which the source is sh, but with different PIDs. Those are each completely different containers:
1316 is deis-publisher
9844 is deis-store-monitor
1521 is deis-router
8468 is my web application, production-web
The only way for me to find that out is to ssh into the box and run ps. What's worse, if I had any logs from my other containers at the same time, they would have also shown up as sh – in a production environment with several active apps all logging to the same stream, this situation is obviously untenable. The ideal situation would have sh replaced by the name of the Docker container or, preferably, the Deis app.
I've poured over the documentation and dug into the logspout and logger source code, but I can't find anything to fix this. Any chance I could get some pointers here?
In order to get at the name of the deis container that logged the line, the best way I've found is either:
To run the output of journalctl -f -o short through netcat to a fluentd or logstash tcp listener. You can use these tools to summarize the fields like _SYSTEMD_UNIT that appeal to your needs.
Use ianblenke/fluentd with LOG_DOCKER_JSON defined or fork and modify the autobuild source docker-ianblenke/fluentd. This uses the fluentd-docker plugin to follow the raw docker container json logs.
If you're using CoreOS, I use this fluentd.cloud-init to auto-feed my logs to a local elasticsearch instance on TCP 9200. Will fill find other useful CoreOS cloud-init configs in that project as well.