 MIAME.INI QUEUE location
#11516
25 Jun 19 10:31 AM
|
Joined: Oct 2015
Posts: 230
Stuart
OP
Member
|
|
OP
Member
Joined: Oct 2015
Posts: 230 |
I understand that whilst qflock.sys might usually reside in the base level /vm/miame directory, it should be possible to use a custom location via MIAME.INI.
We are trying to use docker containers and need to use a shared location in order that a background job can be started in a separate container. However, it appears that this is not being recognised.
It is unclear whether the problem is with Ashell, Docker or if not the latter, then probably somewhere in between.
As a start point, can you confirm if this option has actually been used please?
|
|
|
|
Re: MIAME.INI QUEUE location
#11517
25 Jun 19 11:04 AM
|
Joined: Jun 2001
Posts: 11,645
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,645 |
I can confirm that under normal circumstances, you can put the qflock.sys and jobtbl.sys in any accessible directory. For example, even though my %MIAME% base directory is /vm/miame, I'm running under this environment with A-Shell/Linux 6.4 right now... QUEUE=600,MEM:/tmp/qflock.sys Note however that in the Docker environment, I'm not sure it makes sense to use the MEM: option (for memory-mapped), since I don't think that separate Docker instances can share memory-mapped files. So maybe you should switch to the DISK: variation: QUEUE=600,DISK:/tmp/qflock.sys Note that in either case, the files get created, i.e. ... .host ls -l /tmp/*.sys
-rw-rw-rw-. 1 jack jack 7680 Jun 25 08:53 /tmp/jobtbl.sys
-rw-rw-rw-. 1 jack jack 26112 Jun 25 08:50 /tmp/qflock.sys ... but in the DISK: version, they're just ordinary shared disk files, leaving it up to the OS to cache as it sees fit. In the MEM: version, the files are immediately memory mapped, which allows A-Shell to thereafter bypass the disk service system entirely and access them using memory copy commands, which is faster because it eliminates the interrupts involved in handling system calls. (Disk operations require 'system' calls, whereas memory operations don't.) Whether that's actually measurable any more I can't say as I haven't tried to test it recently, but at one point several years ago, it did make a very significant difference. It's overdue for the A-Shell Docker image to be updated, so let me see about that and perhaps play around with this issue in that environment, after which I'll follow up here.
|
|
|
|
Re: MIAME.INI QUEUE location
#11518
25 Jun 19 11:17 AM
|
Joined: Oct 2015
Posts: 230
Stuart
OP
Member
|
|
OP
Member
Joined: Oct 2015
Posts: 230 |
Thank you for your reply. Unfortunately you beat me to it. I was using a docker-compose file to build and start everything, but although the subsequent container should wait for the background container, I don't think it was.
I suspect that the docker-compose dependency option probably waits for the respective container to start, but not necessarily to finish it's start up processes.
I may have to find a way of holding the subsequent container start up for a longer period of time.
|
|
|
|
Re: MIAME.INI QUEUE location
#11519
25 Jun 19 11:48 AM
|
Joined: Jun 2001
Posts: 11,645
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,645 |
Well, we work fast here!  (At least sometimes. :rolleyes: ) Seems like a reasonable suspicion; perhaps we should have a more formalized/standardized mechanism for the wait-for-background-process-to-become-ready operation. But there are plenty of ways to do it informally (use a dummy file, wait for a TCP connection, maybe wait on an XLOCK, ...) In any case, FWIW I've just built a new image for 6.5.1662.0 and pushed it.
|
|
|
|
Re: MIAME.INI QUEUE location
[Re: Jack McGregor]
#31415
12 Aug 19 04:28 PM
|
Joined: Oct 2015
Posts: 230
Stuart
OP
Member
|
|
OP
Member
Joined: Oct 2015
Posts: 230 |
I hadn't looked at this previously as we are still on 6.4. Just had some time so started to explore and am getting a problem with a missing MIAME.INI?
|
|
|
|
Re: MIAME.INI QUEUE location
[Re: Stuart]
#31421
14 Aug 19 12:36 AM
|
Joined: Jun 2001
Posts: 11,645
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,645 |
Sorry for the delay... I'm just trying this now using the microsabio/centos7-ashell default (latest) image ... I have a script that I use to launch the image with an assortment of switches called launchdocker
$ cat launchdocker
#!/bin/bash
# Wrapper for the docker run (or compose?) launch command(s)
#
docker run -it -v /vm/miame:/vm/miame --network=host \
--publish 39899:39899 --publish 39900:39900 --publish 39001:39001 \
--publish 39002:39002 --publish 39003:39003 --publish 39004:39004 \
-v /etc/localtime:/etc/localtime:ro \
$1 `whoami` 1000 $TERM
With that, it comes up just fine, at least here...
$ ./launchdocker microsabio/centos7-ashell
user jack
gid 1000
Press [Enter] key to continue ...
...
A-Shell License Update Utility 2.4(136)
License issued to ATE client
Logged in to SYS:
.getenv MIAME
MIAME = /vm/miame
.vue %miamefile%
<brings up /vm/miame/miame.ini>
You can see from the above that the MIAME environment variable is set to /vm/miame, which happens to be where my miame.ini is. Looking at the run script ...
PATH=$PATH:$HOME/bin:/vm/miame/bin
export PATH TERM
echo 'user ' $1
echo 'gid ' $2
read -p "Press [Enter] key to continue ..."
groupadd -g $2 ashell
useradd -g $2 $1
echo '%sudo ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers
exec /vm/sys/bin/ashell -silo -td $3 -mntsys sys64:=/vm/sys -n log sys
... there's no explicit miame.ini specified, so it definitely needs that MIAME environment variable to be set. So I would say that the issue is the combination of the -v /vm/miame:/vm/miame parameter in the docker run command and setting the MIAME environment variable appropriately.
|
|
|
|
Re: MIAME.INI QUEUE location
[Re: Stuart]
#31422
14 Aug 19 08:17 AM
|
Joined: Oct 2015
Posts: 230
Stuart
OP
Member
|
|
OP
Member
Joined: Oct 2015
Posts: 230 |
Ah!, OK. I think this is a change in structure to the (or at least a) previous image, where the base image and consequent container were fully self contained and would run without needing any further files or settings. Indeed, it would appear that more is required in the 'vm' volume than just the MIAME.INI and the MIAME.INI needs to be configured relevant to the internal requirements of this image. I can work with this, but for someone coming to this for the first time, it doesn't appear that 'friendly'. 
# docker run -it --name ashell -v //c/Users/Stuart/Documents/dev-src/share:/vm/miame microsabio/centos7-ashell omni 1000 xterm
user omni
gid 1000
Press [Enter] key to continue ...
??Ersatz definition file not found: [/vm/miame/dsk0/001004/ersatz.ini]
- Press any key to continue:
?Language definition file not found: [/vm/miame/dsk0/001006/brtish.ldf]
- Press any key to continue:
%Warning - Include file not found: [/vm/miame/trmdef.ini]
- Press any key to continue:
.log sys:
?Cannot open A-Shell queue system!
Call your dealer for help (or MicroSabio at 818-710-8437 if you have no dealer).
Press any key to continue:
|
|
|
|
Re: MIAME.INI QUEUE location
[Re: Stuart]
#31425
14 Aug 19 02:39 PM
|
Joined: Jun 2001
Posts: 11,645
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,645 |
Point taken. Probably we should have some discussion of just what is expected or needed out of an A-Shell/Docker container. I'm not sure I remember what the setup was in the 6.4 version you apparently have been running, but it seems clear the the newer version more oriented towards multiple containers, some acting as servers as others as client/users, sharing an environment.
While convenient to launch a fully self-contained container, it's not clear how one would actually use such a thing, absent permanent storage.
|
|
|
|
Re: MIAME.INI QUEUE location
[Re: Stuart]
#31431
14 Aug 19 03:10 PM
|
Joined: Oct 2015
Posts: 230
Stuart
OP
Member
|
|
OP
Member
Joined: Oct 2015
Posts: 230 |
Well I think part of the problem of using a pre-built image (not just the Ashell image) is not knowing anything about the content of the image or how it was built, unless the user was involved in the original building.
I believe that a self contained Ashell image can be used to get an Ashell environment up and running, which can then be modified and built into a new image, as we did with the 6.4 version.
Whilst the current image may be more relevant to 'production' use, I think some notes about how it is set up and what it requires in order to be used would be of use, unless they are there and I am just not aware of them.
|
|
|
|
|
