Stream: IG creation
Topic: Jekyll hangs with new publisher jar
Ole Hedegaard (Sep 02 2019 at 07:46):
Hi,
Our project generates a DSTU3 implementation guide using a jruby docker image (see attached Dockerfile), including latest Jekyll install and the latest org.hl7.fhir.igpublisher.jar. However, this broke recently. It seems to stall during "Jekyll generating...". If I login to the docker image while it's running and perform a thread dump on the Jekyll process, it seems to be resolving/looking up some gems (but I'm no Ruby expert - see attached thread_dump.txt). I tried adding a Java 11 runtime and fixing the Jekyll version to 3.8.5, but no luck.
I'm able to generate the IG outside of docker, but that requires a Ruby installation, XCode, Jekyll etc. Anyway, it doesn't seem to be an issue with our IG.
Does anyone have a working Dockerfile (or just a working documented setup) using the new IG publisher?
Btw: I build+run the publisher like this:
docker build . -t igpublisher:localbuild
cd <IG directory>
docker run -v ${PWD}/:/app/ igpublisher:localbuild /app/ig.json
Jens Villadsen (Sep 02 2019 at 14:52):
@Grahame Grieve
Grahame Grieve (Sep 02 2019 at 19:42):
beats me. I don't use docker or know anything about it, and it works outside docker...
Jens Villadsen (Sep 03 2019 at 08:48):
@Grahame Grieve which versions of Jekyll is the IgPublisher compatible with?
Jens Villadsen (Sep 03 2019 at 14:40):
@Vadim Peretokin are you guys using the IGpub and docker in combo?
Vadim Peretokin (Sep 03 2019 at 14:58):
We have our own custom IG publisher engine on Simplifier because the performance of the IG publisher isn't really realtime, so no we don't use it
Grahame Grieve (Sep 03 2019 at 19:16):
There's no structural dependency on Jekyll version that I know of; we run it via command line so we're pretty isolated. There's nasty stuff around Ruby which is a horrible thing, but if Jekyll runs from the command line, I have no idea why it wouldn't work for the IGPublisher
Jens Villadsen (Sep 04 2019 at 08:47):
@Grahame Grieve so what versions of jekyll is the Ig compatible with?
Grahame Grieve (Sep 04 2019 at 08:50):
really I don't know. the IGPublisher doesn't use any feature of Jekyll that wasn't documented 4 years ago. It would be up to the templates / html things to hammer away on new features
Jens Villadsen (Sep 05 2019 at 07:32):
So the million dollar question is then: Have you changed anything in the part of executing jekyll from the igpub jar in the last couple of months?
Jens Villadsen (Sep 05 2019 at 07:33):
docker is a tool for process isolation - and our docker image for building IG's haven't changed. The only thing that has changed within the image is the version of the igpub
Jens Villadsen (Sep 05 2019 at 07:40):
and now stuff does not work any more with the latest version of the igpub as it hangs in the statement:
Jekyll: Generating...
Grahame Grieve (Sep 05 2019 at 07:47):
I confirm that there has been no change around executing Jekyll.
Looking at the code: "Generating..." comes from Jekyll. That means Jekyll has started correctly.
Grahame Grieve (Sep 05 2019 at 07:48):
what happens if you kill the process at the point, and run Jekyll directly from the command line? The command line parameters for Jekyll are :
build --destination [output]
Where output is the name of the output folder, and current folder is the temp folder. Does it work then?
Jens Villadsen (Sep 05 2019 at 12:02):
Hmmmm .... so far I've found the following: During generation of the IG the following is in the output:
Error in snapshot generation: Differential for http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-address with id: Address.extension:regionalSubdivisionCode.valueCodeableConcept:valueCodeableConcept.coding has an element that is not marked with a snapshot match Error in snapshot generation: Differential for http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-address with id: Address.extension:regionalSubdivisionCode.valueCodeableConcept:valueCodeableConcept.coding:regionalCode has an element that is not marked with a snapshot match Error in snapshot generation: Differential for http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-address with id: Address.extension:regionalSubdivisionCode.valueCodeableConcept:valueCodeableConcept.coding:regionalCode.system has an element that is not marked with a snapshot match
This does not stop the further processing of the publisher. In the end it still hangs in the Jekyll: Generating...
Now, if I step into the container, I've found an exception:
Liquid Exception: Could not locate the included file 'header.html' in any of ["/app/_includes"]. Ensure it exists in one of those directories and, if it is a symlink, does not point outside your site source. in temp/Address-ehealth-address-genexample.html
I suspect there's a link between these errors. What is more interesting is that the reason why it looks like Jekyll keeps hanging is that the exception is probably not interpreted/handled by the IGpublisher
Grahame Grieve (Sep 05 2019 at 12:03):
f I step into the container
not sure what that means but I could believe that I'm failing to pick up a Jekyll error... that's kind of a fun game. but nothing has changed there recently. But you can't step into Jekyll...
Jens Villadsen (Sep 05 2019 at 12:04):
but you can pick up the output of running jekyll
Jens Villadsen (Sep 05 2019 at 12:05):
Jens Villadsen (Sep 05 2019 at 12:05):
It doesn't look like you pick anything up
Grahame Grieve (Sep 05 2019 at 12:06):
it's the PumpStreamHandler, and it's working because you get the Generating... line which comes fromJekyll
Jens Villadsen (Sep 05 2019 at 12:07):
but that only comes into play if it throws an io exception
Jens Villadsen (Sep 05 2019 at 12:07):
right?
Grahame Grieve (Sep 05 2019 at 12:08):
no. you get "Jekyll has failed " in that case. But the Jekyll: Generating... can only come from the PumpStreamHandler.
Grahame Grieve (Sep 05 2019 at 12:08):
either the Apache commons library is not picking up process termination, or the Jekyll process is not terminating. Easy to tell those apart.... look in the system process monitor
Jens Villadsen (Sep 05 2019 at 12:15):
why doesn't the publisher stop at the snapshot generation part? that happens way earlier?
Jens Villadsen (Sep 05 2019 at 12:15):
it is logged as an error
Jens Villadsen (Sep 05 2019 at 12:17):
jekyll does not terminate in this case
Jens Villadsen (Sep 05 2019 at 12:20):
so the IG needs to terminate the jekyll process based on jekylls output
Jens Villadsen (Sep 05 2019 at 12:39):
You could perhaps throw an exception here: https://github.com/HL7/fhir-ig-publisher/blob/c422f4d5992dab4f477072e656be3078799d5312/org.hl7.fhir.publisher.core/src/main/java/org/hl7/fhir/igtools/publisher/Publisher.java#L4405
Jens Villadsen (Sep 05 2019 at 12:39):
instead of returning a boolean that doesn't do much
Jens Villadsen (Sep 05 2019 at 13:08):
@Grahame Grieve here you go: https://github.com/HL7/fhir-ig-publisher/pull/32
Grahame Grieve (Sep 05 2019 at 20:13):
I'm not following the logic of this change. What the code does now is log anything significant from Jekyll, and wait for it to finish.
You're proposing for it to simply ignore the fact that Jekyll hasn't terminated, and hide the error, and abandon the IG publication? I'm certainly not approving a PR like that
Grahame Grieve (Sep 05 2019 at 20:14):
what happens if you run Jekyll outside the IG publisher? do you get that error, and then it hangs?
Jens Villadsen (Sep 05 2019 at 20:35):
My PR was a bit eagerly I must admit
Jens Villadsen (Sep 05 2019 at 20:38):
I'll try to do some further investigation, but I'm pretty sure that something needs to be changed
Grahame Grieve (Sep 05 2019 at 20:38):
maybe. but you haven't actually identified the problem yet
Jens Villadsen (Sep 05 2019 at 20:39):
Jekyll does not terminate when it encounters the error
Jens Villadsen (Sep 05 2019 at 20:39):
thats the problem
Jens Villadsen (Sep 05 2019 at 20:39):
and that causes the publisher to hang
Grahame Grieve (Sep 05 2019 at 20:39):
and you can reproduce this running Jekyll manually?
Jens Villadsen (Sep 05 2019 at 20:40):
working on it
Jens Villadsen (Sep 05 2019 at 20:40):
preferably, I would favour that the IG actually did not spawn other processes
Jens Villadsen (Sep 05 2019 at 20:41):
so that the chaining of tools would be in hands of one self
Jens Villadsen (Sep 05 2019 at 20:43):
do you know why the IG does not stop processing during the
Error in snapshot generation: Differential for http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-address with id: Address.extension:regionalSubdivisionCode.valueCodeableConcept:valueCodeableConcept.coding has an element that is not marked with a snapshot match Error in snapshot generation: Differential for http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-address with id: Address.extension:regionalSubdivisionCode.valueCodeableConcept:valueCodeableConcept.coding:regionalCode has an element that is not marked with a snapshot match Error in snapshot generation: Differential for http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-address with id: Address.extension:regionalSubdivisionCode.valueCodeableConcept:valueCodeableConcept.coding:regionalCode.system has an element that is not marked with a snapshot match
Jens Villadsen (Sep 05 2019 at 20:47):
And yes, I can produce it manually - however the error logs from jekyll is sent to stderr
Liquid Exception: Could not locate the included file 'header.html' in any of ["/Users/jvi/gitlab/implementationguide/_includes"]. Ensure it exists in one of those directories and, if it is a symlink, does not point outside your site source. in temp/Address-ehealth-address-genexample.html
Jens Villadsen (Sep 05 2019 at 20:48):
you don't see it when running with the IG publisher
Jens Villadsen (Sep 05 2019 at 20:48):
it is present when you invoke jekyll build -t
Grahame Grieve (Sep 05 2019 at 20:49):
preferably, I would favour that the IG actually did not spawn other processes
Sure I'll just rewrite Jekyll
Jens Villadsen (Sep 05 2019 at 20:49):
thats not what I mean
Jens Villadsen (Sep 05 2019 at 20:50):
the pulisher generates some artifacts right? and after that jekyll processes those artifacts with some templates
Grahame Grieve (Sep 05 2019 at 20:50):
do you know why the IG does not stop processing during the
because the IG publisher tries very hard not to stop, and it doesn't have to stop for those errors. They'll be in QA.html
Grahame Grieve (Sep 05 2019 at 20:50):
yes
Jens Villadsen (Sep 05 2019 at 20:51):
what I mean is that I would like to do the chaining myself.
Jens Villadsen (Sep 05 2019 at 20:52):
as in run the igpub, run jekyll and then run whatever i need afterwards
Jens Villadsen (Sep 05 2019 at 20:52):
like piping output from one process to another
Grahame Grieve (Sep 05 2019 at 20:53):
the IG publisher does lots of work after Jekyll has finished
Jens Villadsen (Sep 05 2019 at 20:53):
could that be reordered?
Jens Villadsen (Sep 05 2019 at 20:53):
or are there some logical constraints to the output of jekyll?
Grahame Grieve (Sep 05 2019 at 20:54):
error logs from jekyll is sent to stderr
the apache commons doco appears to claim that stderr output should be sent to the pump handler.
Jens Villadsen (Sep 05 2019 at 20:54):
I saw that as well ...
Grahame Grieve (Sep 05 2019 at 20:54):
and the fact that I have a catcher for Liquid Exception implies it is being seen.... so I'm not following
Jens Villadsen (Sep 05 2019 at 20:54):
well it isn't logged
Grahame Grieve (Sep 05 2019 at 20:55):
that still doesn't relate to not terminating? but maybe apache commons has a bug here? log to stderr and then it hangs somewhere?
Jens Villadsen (Sep 05 2019 at 20:55):
maybe
Jens Villadsen (Sep 05 2019 at 20:55):
I can send you the content of the IG
Jens Villadsen (Sep 05 2019 at 20:56):
then you can run it and see for yourself
Grahame Grieve (Sep 05 2019 at 20:56):
ok
Jens Villadsen (Sep 05 2019 at 20:56):
when run by the IG the output is not present
Jens Villadsen (Sep 05 2019 at 20:56):
when you afterwards run jekyll build -t you see it
Jens Villadsen (Sep 05 2019 at 20:58):
same email as always?
Grahame Grieve (Sep 05 2019 at 20:58):
sure
Jens Villadsen (Sep 05 2019 at 21:01):
it should be running through the SMTP servers now
Jens Villadsen (Sep 05 2019 at 21:06):
it went to your gmail
Grahame Grieve (Sep 05 2019 at 21:15):
you'll be unhappy to know that works just fine for me
Jens Villadsen (Sep 05 2019 at 21:15):
what works?
Grahame Grieve (Sep 05 2019 at 21:16):
well I got to the end of the production run but there were so many html errors I couldn't see what happened. running again with a break point
Jens Villadsen (Sep 05 2019 at 21:17):
and running jekyll build -tdoes not print anything to stderr?
Grahame Grieve (Sep 05 2019 at 21:18):
Jekyll: Source: C:/work/org.hl7.fhir.igs/jens-dk/temp (00:02:40.0920sec)
Jekyll: Generating... (00:02:40.0920sec)
Jekyll: done in 13.688 seconds. (00:02:54.0608sec)
Jens Villadsen (Sep 05 2019 at 21:18):
thats the output of the IG right?
Grahame Grieve (Sep 05 2019 at 21:19):
yep. jekyll worked just fine for me
Jens Villadsen (Sep 05 2019 at 21:20):
now try to call jekyll yourself
Grahame Grieve (Sep 05 2019 at 21:20):
I can't find an /app/ so I don't know what that's about....
Jens Villadsen (Sep 05 2019 at 21:20):
?
Jens Villadsen (Sep 05 2019 at 21:22):
if there's and app folder you can safely delete it
Grahame Grieve (Sep 05 2019 at 21:23):
that was based on Could not locate the included file 'header.html' in any of ["/app/_includes"
Jens Villadsen (Sep 05 2019 at 21:23):
disregard that
Jens Villadsen (Sep 05 2019 at 21:23):
the /app/ thing is a leftover artifact
Grahame Grieve (Sep 05 2019 at 21:24):
so this time I manually deleted the header file from /temp/_includes, and I got this log:
Grahame Grieve (Sep 05 2019 at 21:24):
Jekyll: Source: C:/work/org.hl7.fhir.igs/jens-dk/temp (00:03:48.0351sec) Jekyll: Generating... (00:03:48.0352sec) Jekyll has failed - not installed (correcty?). Complete output from running Jekyll: [31m Liquid Exception: Could not locate the included file 'header.html' in any of ["C:/work/org.hl7.fhir.igs/jens-dk/temp/_includes"]. Ensure it exists in one of those directories and, if it is a symlink, does not point outside your site source. in Addre (00:03:50.0751sec) Publishing Content Failed: Process exited with an error: 1 (Exit value: 1) (00:03:50.0753sec)
Jens Villadsen (Sep 05 2019 at 21:24):
just remove temp and output and whatnot
Jens Villadsen (Sep 05 2019 at 21:24):
yes
Jens Villadsen (Sep 05 2019 at 21:24):
there you hav eit
Grahame Grieve (Sep 05 2019 at 21:25):
there I have what? What I see is that it handled the failure properly.
Jens Villadsen (Sep 05 2019 at 21:25):
Grahame Grieve (Sep 05 2019 at 21:25):
Jekyll has failed, and I got the input
Jens Villadsen (Sep 05 2019 at 21:25):
is that not the proper place to fetch the IGpbulisher?
Grahame Grieve (Sep 05 2019 at 21:26):
no. it's not. Maven can't get latest correct. The right place is
Grahame Grieve (Sep 05 2019 at 21:27):
https://fhir.github.io/latest-ig-publisher/org.hl7.fhir.publisher.jar
Jens Villadsen (Sep 05 2019 at 21:27):
wtf?
Grahame Grieve (Sep 05 2019 at 21:27):
but it doesn't make any difference for this stuff
Jens Villadsen (Sep 05 2019 at 21:27):
lets find out
Grahame Grieve (Sep 05 2019 at 21:27):
https://issues.sonatype.org/browse/NEXUS-5440
Jens Villadsen (Sep 05 2019 at 21:31):
but it doesn't make any difference for this stuff
if it does not make a difference, how come you saw the output
Grahame Grieve (Sep 05 2019 at 21:34):
I wonder if it's because I'm on windows?
Jens Villadsen (Sep 05 2019 at 21:34):
and im on linux and mac?
Jens Villadsen (Sep 05 2019 at 21:35):
see this is one of the reasons for running on docker
Grahame Grieve (Sep 05 2019 at 21:35):
well... I don't know what else it could be. But I did have to delete the file manually to create the problem. do you have a file temp/_includes/header.html?
Jens Villadsen (Sep 05 2019 at 21:36):
yep
Grahame Grieve (Sep 05 2019 at 21:36):
so why can't jekyll find it?
Grahame Grieve (Sep 05 2019 at 21:36):
you get the same error running jekyll from the command line in temp?
Jens Villadsen (Sep 05 2019 at 21:37):
no
Jens Villadsen (Sep 05 2019 at 21:37):
no errors
Grahame Grieve (Sep 05 2019 at 21:39):
this is not making a lot of sense.... under what conditions do you get the jekyll error from the command line?
Jens Villadsen (Sep 05 2019 at 21:41):
Jenss-MacBook-Pro-2:implementationguide jvi$ pwd
/Users/jvi/gitlab/implementationguide
Jenss-MacBook-Pro-2:implementationguide jvi$ jekyll build -t
Configuration file: none
Source: /Users/jvi/gitlab/implementationguide
Destination: /Users/jvi/gitlab/implementationguide/_site
Incremental build: disabled. Enable with --incremental
Generating...
Liquid Exception: Could not locate the included file 'header.html' in any of ["/Users/jvi/gitlab/implementationguide/_includes"]. Ensure it exists in one of those directories and, if it is a symlink, does not point outside your site source. in temp/Address-ehealth-address-genexample.html
/Users/jvi/.gem/ruby/2.3.0/gems/jekyll-3.8.5/lib/jekyll/tags/include.rb:121:in `locate_include_file': Could not locate the included file 'header.html' in any of ["/Users/jvi/gitlab/implementationguide/_includes"]. Ensure it exists in one of those directories and, if it is a symlink, does not point outside your site source. (IOError)
Grahame Grieve (Sep 05 2019 at 21:44):
you missing /temp on the source?
Jens Villadsen (Sep 05 2019 at 21:58):
1)running java -jar org.hl7.fhir.publisher.jar -ig ig.json processes without issues (so it looks like)
2)running jekyll build -tshows the LiquidException in stderr
3)running java -jar org.hl7.fhir.publisher.jar -ig ig.json in my docker container never ends (probably because of 2)
4)running jekyll build -tin my docker container shows the LiquidException in stderr
1) 2) and 4) is only done as part of troubleshooting 3)
Jens Villadsen (Sep 05 2019 at 22:00):
you missing /temp on the source?
what do you mean?
Grahame Grieve (Sep 05 2019 at 22:00):
Source: /Users/jvi/gitlab/implementationguide - that's wrong. it should be Source: /Users/jvi/gitlab/implementationguide/temp
Grahame Grieve (Sep 05 2019 at 22:01):
I do not understand 1&2 unless you are running jekyll wrongly
Jens Villadsen (Sep 05 2019 at 22:03):
I do not understand 1&2 unless you are running jekyll wrongly
how can that be done?
Jens Villadsen (Sep 05 2019 at 22:04):
Source: /Users/jvi/gitlab/implementationguide - that's wrong. it should be Source: /Users/jvi/gitlab/implementationguide/temp
I agree - so why does this happen?
Grahame Grieve (Sep 05 2019 at 22:05):
why does what happen? looks like you're running it in the wrong directory
Jens Villadsen (Sep 05 2019 at 22:05):
so I shouldn't have to run jekyll manually at all
Jens Villadsen (Sep 05 2019 at 22:06):
that should be spawned by the IG
Grahame Grieve (Sep 05 2019 at 22:06):
no you're doing that for troubleshooting purposes
Jens Villadsen (Sep 05 2019 at 22:14):
hmmm I seem to get another error if invoke jekyll in the temp dir and then eventually terminate it (as it just keeps spinninig)
Jens Villadsen (Sep 05 2019 at 22:14):
Configuration file: none
Source: /app/temp
Destination: /app/temp/_site
Incremental build: disabled. Enable with --incremental
Generating...
^C Liquid Exception: in StructureDefinition-ehealth-careteam-example-operations.html
- i wonder what that could be ...
Grahame Grieve (Sep 05 2019 at 22:17):
now we're getting somewhere. where does the ^C thing come from? is that jekyll output?
Jens Villadsen (Sep 05 2019 at 22:17):
thats me terminating it
Grahame Grieve (Sep 05 2019 at 22:17):
so you get the liquid exception printed out after you terminate it?
Jens Villadsen (Sep 05 2019 at 22:18):
yep
Grahame Grieve (Sep 05 2019 at 22:18):
https://github.com/envygeeks/jekyll-docker/issues/12
Jens Villadsen (Sep 05 2019 at 22:21):
interesting ... but that does not explain why we suddenly have encountered this bug after an upgrade of jruby and the publisher
Jens Villadsen (Sep 05 2019 at 22:21):
it has been working for months
Grahame Grieve (Sep 05 2019 at 22:22):
sure. but this is definitely a jekyll bug...
Grahame Grieve (Sep 05 2019 at 22:24):
I'm going to pout a limit of 5 minutes on Jekyll
Jens Villadsen (Sep 05 2019 at 22:25):
i'll try to run from the jekyll images and see if that does any magic
Jens Villadsen (Sep 06 2019 at 07:41):
https://github.com/envygeeks/jekyll-docker/issues/12 is solved
Jens Villadsen (Sep 06 2019 at 07:41):
I just tried it myself
Jens Villadsen (Sep 06 2019 at 07:57):
I've downloaded the source of the IG and added a -V to the runJekyll command line ...
Jens Villadsen (Sep 06 2019 at 07:57):
now ... I've seem to have found something
Jens Villadsen (Sep 06 2019 at 08:03):
it simply goes cold at a point ....
Jekyll: Rendering Liquid: StructureDefinition-ehealth-careteam-definitions.html (00:03:08.0232sec) Jekyll: Rendering Markup: StructureDefinition-ehealth-careteam-definitions.html (00:03:08.0245sec) Jekyll: Rendering Layout: StructureDefinition-ehealth-careteam-definitions.html (00:03:08.0245sec) Jekyll: Rendering: StructureDefinition-ehealth-careteam-example-operations.html (00:03:08.0245sec) Jekyll: Pre-Render Hooks: StructureDefinition-ehealth-careteam-example-operations.html (00:03:08.0245sec) Jekyll: Rendering Liquid: StructureDefinition-ehealth-careteam-example-operations.html (00:03:08.0245sec)
Grahame Grieve (Sep 06 2019 at 12:00):
well, that was a given. I'm not sure that the point in very informative? is it a memory issue?
Jens Villadsen (Sep 06 2019 at 12:16):
Haven't looked, but I would be surprised if that was the cause
Grahame Grieve (Sep 06 2019 at 12:17):
any other cause would also be surprising...?
Jens Villadsen (Sep 06 2019 at 12:17):
not to the same extent
Jens Villadsen (Sep 06 2019 at 12:20):
By default docker does not impose constraints on memory, disk, cpu. So if it was a memory issue, it would also hit me outside docker
Jens Villadsen (Sep 06 2019 at 12:20):
which is not the case
Jens Villadsen (Sep 06 2019 at 12:21):
and actually ... delivering the igpublisher in docker would probably be welcomed by a load of users
Jens Villadsen (Sep 06 2019 at 12:21):
they wouldn't have to deal with ruby, jekyll or java in terms of installation
Jens Villadsen (Sep 06 2019 at 12:21):
they would only have to deal with docker
Jens Villadsen (Sep 06 2019 at 12:22):
nothing else
Jens Villadsen (Sep 06 2019 at 13:32):
Sending Usage Stats to Server (00:01:41.0150sec)
Submitting Usage Stats failed: Connection refused (Connection refused)
Jekyll: Source: /app/temp (00:03:05.0425sec)
Jekyll: Generating... (00:03:05.0427sec)
Jekyll has failed - not installed (correctly?). Complete output from running Jekyll: Generating...
isabled. Enable with --incremental
(00:07:58.0316sec)
Check that Jekyll is installed correctly (00:07:58.0316sec)
Publishing Content Failed: Process exited with an error: 143 (Exit value: 143) (00:07:58.0352sec)
(00:07:58.0352sec)
Use -? to get command line help (00:07:58.0352sec)
(00:07:58.0352sec)
Stack Dump (for debugging): (00:07:58.0352sec)
org.apache.commons.exec.ExecuteException: Process exited with an error: 143 (Exit value: 143)
at org.apache.commons.exec.DefaultExecutor.executeInternal(DefaultExecutor.java:404)
at org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:166)
at org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:153)
at org.hl7.fhir.igtools.publisher.Publisher.runJekyll(Publisher.java:4467)
at org.hl7.fhir.igtools.publisher.Publisher.runTool(Publisher.java:4385)
at org.hl7.fhir.igtools.publisher.Publisher.generate(Publisher.java:3900)
at org.hl7.fhir.igtools.publisher.Publisher.createIg(Publisher.java:731)
at org.hl7.fhir.igtools.publisher.Publisher.execute(Publisher.java:609)
at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:6410)
Exception in thread "main" java.lang.NullPointerException
at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:6420)
- with your new kill-feature
Grahame Grieve (Sep 06 2019 at 19:58):
so where does this leave us? it's certainly frustrating...
Jens Villadsen (Sep 07 2019 at 20:29):
probably somewhere where the Igpub is not a great fit for docker as long as it has to spawn sub processes. Is there an optional argument where you can get the igpub to stop processing when it encounters an error? e.g. at the snapshot generation part?
Grahame Grieve (Sep 07 2019 at 20:58):
- docker doesn't support sub-processes?
- have you asked about this on a Jekyll support forum?
- there's no optional argument
- but why do you think there's a connection? the snapshot generation errors are arcane issues inside the generation of the snapshot that don't affect anything else except that correctness of the snapshot
Jens Villadsen (Sep 07 2019 at 21:08):
- docker is primarily process isolation and it is considered good practice to only have a single process running pr container (https://devops.stackexchange.com/questions/447/why-it-is-recommended-to-run-only-one-process-in-a-container) while the use of multiple processes actually are supported.
- Jekyll in itself has no issue running in docker
- ok
- I'm simply looking into what is piped out at errors, and the snapshot generation is listed as an error.
Grahame Grieve (Sep 07 2019 at 21:11):
so I read that link, but I don't understand it. Spawning sub-processes is standard software re-use. Docker's trying to reinvent software development?
Jens Villadsen (Sep 07 2019 at 21:13):
docker is trying to revinvent virtualization ... and then some ...
Jens Villadsen (Sep 07 2019 at 21:13):
its actually not trying ... it already succeeded
Grahame Grieve (Sep 07 2019 at 21:13):
anyway I though you had shown that Jekyll hangs when you run it directly on the source
Grahame Grieve (Sep 07 2019 at 21:13):
reinvent virtualization != reinvent software development
Jens Villadsen (Sep 07 2019 at 21:14):
not when running locally
Jens Villadsen (Sep 07 2019 at 21:14):
reinvent virtualization != reinvent software development
right
Grahame Grieve (Sep 07 2019 at 21:14):
what happens when you run it on the source manually?
Jens Villadsen (Sep 07 2019 at 21:14):
define source
Grahame Grieve (Sep 07 2019 at 21:14):
this is what you pasted above:
Configuration file: none
Source: /app/temp
Destination: /app/temp/_site
Incremental build: disabled. Enable with --incremental
Generating...
^C Liquid Exception: in StructureDefinition-ehealth-careteam-example-operations.html
Grahame Grieve (Sep 07 2019 at 21:15):
you had to kill it manually
Grahame Grieve (Sep 07 2019 at 21:15):
is what you said
Jens Villadsen (Sep 07 2019 at 21:15):
thats from within docker, yes
Jens Villadsen (Sep 07 2019 at 21:15):
where I had to kill it manually
Grahame Grieve (Sep 07 2019 at 21:16):
so you started it manually in docker, it hangs, and then, when the IGpublisher starts it the same way and it hangs, this is an IG publisher issue?
Jens Villadsen (Sep 07 2019 at 21:18):
I started the ig in docker where it hangs in the jekyll step
Grahame Grieve (Sep 07 2019 at 21:18):
but happens if you kill the ig process manually and run jekyll on the source directly?
Grahame Grieve (Sep 07 2019 at 21:18):
from the command line, which you must have done to get the output above
Jens Villadsen (Sep 07 2019 at 21:19):
and if I step into the docker container while the ig is still hanging and run jekyll it still hangs
Grahame Grieve (Sep 07 2019 at 21:19):
... you had to ^C it
Grahame Grieve (Sep 07 2019 at 21:19):
kill the IG process first...
Jens Villadsen (Sep 07 2019 at 21:19):
if I kill the ig inside the docker container, it is the same as killing the docker container
Grahame Grieve (Sep 07 2019 at 21:20):
how much memory does the JVM have, and how much memory does the docker have? is docker running out of memory, so Jekyll is going into a memory disaster?
Jens Villadsen (Sep 07 2019 at 21:20):
1Gb
Jens Villadsen (Sep 07 2019 at 21:20):
for the JVM
Jens Villadsen (Sep 07 2019 at 21:20):
no limits on the docker container
Grahame Grieve (Sep 07 2019 at 21:24):
@James Agnew a question. There's JRuby where we could possibly run Jekyll directly inside the JVM. But it's kind of a big addition to the cli package and I would only use it by configuration request on the command line, to support docker. is there a way to use it if it's installed, but not to put it in the cli? And how would you set that up in Eclipse?
@Jens Villadsen maybe if the Jekyll issue is just not resolveable, JRuby can help but it seems like a risky thing to me
Jens Villadsen (Sep 07 2019 at 21:25):
is it out of the question to split the generation up in multiple steps?
Grahame Grieve (Sep 07 2019 at 21:26):
yes in the sense you are asking. The IG publisher does things before Jekyll runs, and then it does things afterwards
Grahame Grieve (Sep 07 2019 at 21:27):
and a bunch of context is carried across that process
Jens Villadsen (Sep 07 2019 at 21:27):
and the things afterwards ... they depend on the output of jekyll?
Grahame Grieve (Sep 07 2019 at 21:27):
they do, or they wouldn't be done afterwards
Jens Villadsen (Sep 07 2019 at 21:29):
the context that is carried over ... that stuff that is not serialized to disk, what is that?
Grahame Grieve (Sep 07 2019 at 21:29):
all the context of the classes that run the publishing
Jens Villadsen (Sep 07 2019 at 21:31):
from the source it looks like some NPM generation, some zip stuff and some validation, right?
Grahame Grieve (Sep 07 2019 at 21:31):
yes
Jens Villadsen (Sep 07 2019 at 21:33):
and the context cannot be reconstructed from the ig configuration + the result of the jekyll execution?
Grahame Grieve (Sep 07 2019 at 21:34):
look it's probably theoretically possible. But I'm not going to spend months rewriting to work around some problem running jekyll in docker. Specially when it already worked in the past
Lloyd McKenzie (Sep 07 2019 at 21:34):
Loading all of that stuff takes a good chunk of time. It would decrease performance of a process that's already problematic in terms of performance.
Grahame Grieve (Sep 07 2019 at 21:35):
and I've learnt too, about this: each new more complex configuration that allows for something to work.... it kills me. Maven... man... I hate maven. It's made what we do so much more complex in ways I could not have imagined when we moved the java code to maven
Jens Villadsen (Sep 07 2019 at 21:36):
then pick gradle or ivy if you have issues with maven
Grahame Grieve (Sep 07 2019 at 21:37):
I would if @James Agnew told me it would make my life simpler. but I think it wouldn't
Jens Villadsen (Sep 07 2019 at 21:38):
sounds like you are trying to shoehorn maven into something that doesn't fit the bill
Grahame Grieve (Sep 07 2019 at 21:40):
perhaps. But it's the cross project dependencies and the way that interacts with PRs that's creating us problems. We just shouldn't have split our project up.... but it has other advantages. Anyway, this is a rabbit hole. Jekyll used to work, it hangs internally... it really feels like a Jekyll issue to me
Grahame Grieve (Sep 07 2019 at 21:43):
if you ask here: https://talk.jekyllrb.com/ I'll track the discussion
Jens Villadsen (Sep 07 2019 at 22:07):
https://talk.jekyllrb.com/t/jekyll-spawned-from-another-process-inside-docker/3308
Grahame Grieve (Sep 07 2019 at 22:28):
I'll in some further details
Grahame Grieve (Sep 09 2019 at 06:17):
does it work on docker with some other IG?
Jens Villadsen (Sep 09 2019 at 07:07):
It previously worked on our IG
Grahame Grieve (Sep 09 2019 at 07:09):
right. but that was then. Does it work on a different ig now?
Jens Villadsen (Sep 09 2019 at 07:11):
can you point to an IG that works? I just tried to check out IPS and that failed
Jens Villadsen (Sep 09 2019 at 07:12):
as in:
Terminology Cache is at /app/txCache. 14 files in cache (02.0127sec)
Loading package.tgz to the package cache
Fetching:............................................................................................................
......................................................................................................................
......................................................................................................................
.............................................................................................. done.
Load hl7.fhir.core-4.0.0 package from memory (03.0168sec)
Publishing Content Failed: Not a JSON Object: "AuditEvent.entity" (04.0766sec)
(04.0766sec)
Use -? to get command line help (04.0766sec)
(04.0766sec)
Stack Dump (for debugging): (04.0766sec)
java.lang.IllegalStateException: Not a JSON Object: "AuditEvent.entity"
at com.google.gson.JsonElement.getAsJsonObject(JsonElement.java:91)
at org.hl7.fhir.r4.formats.JsonParser.parseStructureDefinitionProperties(JsonParser.java:23590)
at org.hl7.fhir.r4.formats.JsonParser.parseStructureDefinition(JsonParser.java:23489)
Jens Villadsen (Sep 09 2019 at 07:16):
I'm seeing a pattern here: error was the same for FHIR QI Core ...
Grahame Grieve (Sep 09 2019 at 07:18):
Jens Villadsen (Sep 09 2019 at 07:18):
master branch?
Grahame Grieve (Sep 09 2019 at 07:19):
y
Grahame Grieve (Sep 09 2019 at 07:19):
have you seen this page? https://fhir.github.io/auto-ig-builder/builds.html
Jens Villadsen (Sep 09 2019 at 07:21):
onLoad:
Publishing Content Failed: null (09.0631sec)
(09.0632sec)
Use -? to get command line help (09.0632sec)
(09.0632sec)
Stack Dump (for debugging): (09.0633sec)
java.lang.NullPointerException
at org.hl7.fhir.igtools.templates.Template.loadValidationMessages(Template.java:260)
at org.hl7.fhir.igtools.templates.Template.runScriptTarget(Template.java:198)
at org.hl7.fhir.igtools.templates.Template.onLoadEvent(Template.java:323)
at org.hl7.fhir.igtools.publisher.Publisher.initializeFromIg(Publisher.java:1185)
at org.hl7.fhir.igtools.publisher.Publisher.initialize(Publisher.java:1116)
at org.hl7.fhir.igtools.publisher.Publisher.execute(Publisher.java:603)
at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:6410)
Exception in thread "main" java.lang.NullPointerException
at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:6420)
Grahame Grieve (Sep 09 2019 at 07:21):
what's the start of the log? Did you get the very latest IG publisher? (it's only an hour old...)
Jens Villadsen (Sep 09 2019 at 07:22):
i just cloned it
Jens Villadsen (Sep 09 2019 at 07:22):
FHIR IG Publisher Version 0.9.65-SNAPSHOT - Built 2019-09-06T15:04:14.427+10:00 - Git 07429344b330
Detected Java version: 1.8.0_212 from /usr/lib/jvm/java-8-openjdk-amd64/jre on amd64 (64bit). 1820MB available
Run time = Monday, September 9, 2019 7:20:09 AM UTC ( @ 2019-09-09T07:20:09Z )
[/] -spec package.tgz -ig /app/ig.ini
Package Cache: /root/.fhir/packages
Contacting Build Server... (00.0116sec)
... done (01.0728sec)
Load Template from hl7.fhir.template
Installing hl7.fhir.template#current to the package cache
Fetching:...|
Analysing done.
onLoad.setup:
onLoad.r5-schemas:
[get] Getting: http://build.fhir.org/fhir-single.xsd
[get] To: /app/input-cache/schemas-r5/fhir-single.xsd
[get] Not modified - so not downloaded
[get] Getting: http://build.fhir.org/fhir-xhtml.xsd
[get] To: /app/input-cache/schemas-r5/fhir-xhtml.xsd
[get] Not modified - so not downloaded
[get] Getting: http://build.fhir.org/xml.xsd
[get] To: /app/input-cache/schemas-r5/xml.xsd
[get] Not modified - so not downloaded
[get] Getting: http://build.fhir.org/xmldsig-core-schema.xsd
[get] To: /app/input-cache/schemas-r5/xmldsig-core-schema.xsd
[get] Not modified - so not downloaded
onLoad.checkPublisher:
onLoad.upgradeWarning:
onLoad.findSpreadsheets:
onLoad.updateIg:
[xslt] Processing /app/template/onLoad-ig-working.xml to /app/template/onLoad-ig-updated.xml
[xslt] Loading stylesheet /app/template/scripts/onLoad.xslt
onLoad:
Publishing Content Failed: null (09.0631sec)
(09.0632sec)
Use -? to get command line help (09.0632sec)
(09.0632sec)
Stack Dump (for debugging): (09.0633sec)
java.lang.NullPointerException
at org.hl7.fhir.igtools.templates.Template.loadValidationMessages(Template.java:260)
at org.hl7.fhir.igtools.templates.Template.runScriptTarget(Template.java:198)
at org.hl7.fhir.igtools.templates.Template.onLoadEvent(Template.java:323)
at org.hl7.fhir.igtools.publisher.Publisher.initializeFromIg(Publisher.java:1185)
at org.hl7.fhir.igtools.publisher.Publisher.initialize(Publisher.java:1116)
at org.hl7.fhir.igtools.publisher.Publisher.execute(Publisher.java:603)
at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:6410)
Exception in thread "main" java.lang.NullPointerException
at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:6420)
Grahame Grieve (Sep 09 2019 at 07:23):
that's not the latest - latest is 69
Grahame Grieve (Sep 09 2019 at 07:23):
not 65
Jens Villadsen (Sep 09 2019 at 07:23):
arh... you talked 'bout the tool version
Jens Villadsen (Sep 09 2019 at 07:30):
FHIR IG Publisher Version 0.9.69-SNAPSHOT - Built 2019-09-09T15:20:31.152+10:00 - Git bbf4b68a7f57
Detected Java version: 1.8.0_212 from /usr/lib/jvm/java-8-openjdk-amd64/jre on amd64 (64bit). 1820MB available
Parameters: -spec package.tgz -ig /app/ig.ini [dir = /]
Run time = Monday, September 9, 2019 7:29:58 AM UTC (2019-09-09T07:29:58Z)
Package Cache: /root/.fhir/packages (00:00.0102)
Contacting Build Server... (00:00.0115)
... done (00:01.0756)
Load Template from hl7.fhir.template (00:02.0805)
Installing hl7.fhir.template#current to the package cache
Fetching:...|
Analysing done.
onLoad.setup:
onLoad.r5-schemas:
[get] Getting: http://build.fhir.org/fhir-single.xsd
[get] To: /app/input-cache/schemas-r5/fhir-single.xsd
[get] Not modified - so not downloaded
[get] Getting: http://build.fhir.org/fhir-xhtml.xsd
[get] To: /app/input-cache/schemas-r5/fhir-xhtml.xsd
[get] Not modified - so not downloaded
[get] Getting: http://build.fhir.org/xml.xsd
[get] To: /app/input-cache/schemas-r5/xml.xsd
[get] Not modified - so not downloaded
[get] Getting: http://build.fhir.org/xmldsig-core-schema.xsd
[get] To: /app/input-cache/schemas-r5/xmldsig-core-schema.xsd
[get] Not modified - so not downloaded
onLoad.checkPublisher:
onLoad.upgradeWarning:
onLoad.findSpreadsheets:
onLoad.updateIg:
[xslt] Processing /app/template/onLoad-ig-working.xml to /app/template/onLoad-ig-updated.xml
[xslt] Loading stylesheet /app/template/scripts/onLoad.xslt
onLoad:
Root directory: /app (00:09.0524)
Loading package.tgz to the package cache
Fetching:............................................................................................................
......................................................................................................................
......................................................................................................................
.............................................................................................. done.
Publishing Content Failed: Not a JSON Object: "AuditEvent.entity" (00:14.0645)
(00:14.0645)
Use -? to get command line help (00:14.0645)
(00:14.0645)
Stack Dump (for debugging): (00:14.0646)
java.lang.IllegalStateException: Not a JSON Object: "AuditEvent.entity"
at com.google.gson.JsonElement.getAsJsonObject(JsonElement.java:91)
at org.hl7.fhir.r4.formats.JsonParser.parseStructureDefinitionProperties(JsonParser.java:23590)
at org.hl7.fhir.r4.formats.JsonParser.parseStructureDefinition(JsonParser.java:23489)
at org.hl7.fhir.r4.formats.JsonParser.parseResource(JsonParser.java:27666)
at org.hl7.fhir.r4.formats.JsonParserBase.parse(JsonParserBase.java:113)
at org.hl7.fhir.convertors.R4ToR5Loader.loadBundle(R4ToR5Loader.java:58)
at org.hl7.fhir.r5.context.SimpleWorkerContext.loadFromFileJson(SimpleWorkerContext.java:260)
at org.hl7.fhir.r5.context.SimpleWorkerContext.loadDefinitionItem(SimpleWorkerContext.java:212)
at org.hl7.fhir.r5.context.SimpleWorkerContext.loadFromPackage(SimpleWorkerContext.java:289)
at org.hl7.fhir.r5.context.SimpleWorkerContext.fromPackage(SimpleWorkerContext.java:158)
at org.hl7.fhir.igtools.publisher.SpecificationPackage.fromPackage(SpecificationPackage.java:65)
at org.hl7.fhir.igtools.publisher.Publisher.loadPack(Publisher.java:2082)
at org.hl7.fhir.igtools.publisher.Publisher.loadCorePackage(Publisher.java:2045)
at org.hl7.fhir.igtools.publisher.Publisher.initializeFromIg(Publisher.java:1341)
at org.hl7.fhir.igtools.publisher.Publisher.initialize(Publisher.java:1112)
at org.hl7.fhir.igtools.publisher.Publisher.execute(Publisher.java:604)
at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:6437)
Exception in thread "main" java.lang.NullPointerException
at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:6447)
Grahame Grieve (Sep 09 2019 at 07:37):
oh. that's bad
Jens Villadsen (Sep 09 2019 at 07:39):
wait a sec ... I bootstrapped with the wrong package version
Jens Villadsen (Sep 09 2019 at 07:40):
sdc runs with 4.0
Grahame Grieve (Sep 09 2019 at 07:40):
where does it matter what you say about that?
Jens Villadsen (Sep 09 2019 at 07:40):
-spec package.tgz
Grahame Grieve (Sep 09 2019 at 07:41):
hmm. you're trying to circumvent the package cache?
Grahame Grieve (Sep 09 2019 at 07:41):
I would say that you have no reason to use the -spec parameter ?
Jens Villadsen (Sep 09 2019 at 07:41):
im bootstrapping the package cache
Jens Villadsen (Sep 09 2019 at 07:41):
i would ... its a cache .... so it speeds up the process
Grahame Grieve (Sep 09 2019 at 07:42):
that means you're slowing down the process by destroying the cache otherwise
Grahame Grieve (Sep 09 2019 at 07:42):
like there's no reason to do that
Jens Villadsen (Sep 09 2019 at 07:42):
i would then need to fetch it for each build otherwise
Grahame Grieve (Sep 09 2019 at 07:43):
I don't see why that makes sense. the cache is a system cache. No need to do anything to it
Jens Villadsen (Sep 09 2019 at 07:43):
please elaborate on that
Jens Villadsen (Sep 09 2019 at 07:43):
and please remember that when run in docker nothing is shared with the host system
Jens Villadsen (Sep 09 2019 at 07:44):
unless explicitly stated
Grahame Grieve (Sep 09 2019 at 07:44):
hmm ok I forgot about the docker thing. can you share the cache through docker?
Jens Villadsen (Sep 09 2019 at 07:45):
thats what I just did
Grahame Grieve (Sep 09 2019 at 07:45):
by the -spec parameter? that isn't the same thing
btw the sdc thing works for me if I blow my cache. So your spec.tgz may be the problem
Jens Villadsen (Sep 09 2019 at 07:46):
it is ... igpub does not like to be bootstrapped with a v3.0 cache when it is about to generate an artifact for v4.0
Jens Villadsen (Sep 09 2019 at 07:46):
apparently it does not check whether the cache is stale or not
Jens Villadsen (Sep 09 2019 at 07:47):
consider that a bugreport
Grahame Grieve (Sep 09 2019 at 07:47):
better to just have a cache that is shared directly through docker and let the packages manage themselves. We're going to push ever more into the package cach....
Jens Villadsen (Sep 09 2019 at 07:47):
anyways (without cache):
Jenss-MacBook-Pro-2:sdc jvi$ docker run --rm -v ${PWD}/:/app/ igpublisher:localbuild /app/ig.ini
FHIR IG Publisher Version 0.9.69-SNAPSHOT - Built 2019-09-09T15:20:31.152+10:00 - Git bbf4b68a7f57
Detected Java version: 1.8.0_212 from /usr/lib/jvm/java-8-openjdk-amd64/jre on amd64 (64bit). 1820MB available
Parameters: -ig /app/ig.ini [dir = /]
Run time = Monday, September 9, 2019 7:37:37 AM UTC (2019-09-09T07:37:37Z)
Package Cache: /root/.fhir/packages (00:00.0103)
Contacting Build Server... (00:00.0115)
... done (00:01.0690)
Load Template from hl7.fhir.template (00:02.0715)
Installing hl7.fhir.template#current to the package cache
Fetching:...|
Analysing done.
onLoad.setup:
onLoad.r5-schemas:
[get] Getting: http://build.fhir.org/fhir-single.xsd
[get] To: /app/input-cache/schemas-r5/fhir-single.xsd
[get] Not modified - so not downloaded
[get] Getting: http://build.fhir.org/fhir-xhtml.xsd
[get] To: /app/input-cache/schemas-r5/fhir-xhtml.xsd
[get] Not modified - so not downloaded
[get] Getting: http://build.fhir.org/xml.xsd
[get] To: /app/input-cache/schemas-r5/xml.xsd
[get] Not modified - so not downloaded
[get] Getting: http://build.fhir.org/xmldsig-core-schema.xsd
[get] To: /app/input-cache/schemas-r5/xmldsig-core-schema.xsd
[get] Not modified - so not downloaded
onLoad.checkPublisher:
onLoad.upgradeWarning:
onLoad.findSpreadsheets:
onLoad.updateIg:
[xslt] Processing /app/template/onLoad-ig-working.xml to /app/template/onLoad-ig-updated.xml
[xslt] Loading stylesheet /app/template/scripts/onLoad.xslt
onLoad:
Root directory: /app (00:09.0244)
Installing hl7.fhir.core#4.0.0 to the package cache
Fetching:............................................................................................................
......................................................................................................................
.......................................................................................|
Analysing.............................................................................................................
......................................................................................................................
................................................... done.
Terminology Cache is at /app/input-cache/txcache. 12 files in cache (01:31.0097)
Connect to Terminology Server at http://tx.fhir.org (01:31.0157)
Initialization complete (01:32.0944)
Load Content (01:32.0944)
Processing Conformance Resources (01:35.0463)
Terminology server: Check for supported code systems for http://unstats.un.org/unsd/methods/m49/m49.htm (01:35.0842)
Generating Narratives (01:39.0695)
Validating Resources (01:39.0695)
Generating Outputs in /app/output (01:41.0184)
onGenerate.setup:
onGenerate.infoFile:
onGenerate.processIncludes:
[copy] Copying 4 files to /app/temp/pages/_includes
[xslt] Transforming into /app/temp/pages/_includes
[xslt] Processing /app/input/includes/menu.xml to /app/temp/pages/_includes/menu.xml
[xslt] Loading stylesheet /app/template/scripts/processPages.xslt
[xslt] Transforming into /app/temp/pages/_includes
[xslt] Processing /app/input/pagecontent/adaptive.xml to /app/temp/pages/_includes/adaptive.xml
[xslt] Loading stylesheet /app/template/scripts/processPages.xslt
[xslt] Processing /app/input/pagecontent/behavior.xml to /app/temp/pages/_includes/behavior.xml
[xslt] Processing /app/input/pagecontent/changes.xml to /app/temp/pages/_includes/changes.xml
[xslt] Processing /app/input/pagecontent/downloads.xml to /app/temp/pages/_includes/downloads.xml
[xslt] Processing /app/input/pagecontent/expressions.xml to /app/temp/pages/_includes/expressions.xml
[xslt] Processing /app/input/pagecontent/extraction.xml to /app/temp/pages/_includes/extraction.xml
[xslt] Processing /app/input/pagecontent/index.xml to /app/temp/pages/_includes/index.xml
[xslt] Processing /app/input/pagecontent/intro.xml to /app/temp/pages/_includes/intro.xml
[xslt] Processing /app/input/pagecontent/parameters-questionnaire-next-question-in-intro.xml to /app/temp/pages/_includes/parameters-questionnaire-next-question-in-intro.xml
[xslt] Processing /app/input/pagecontent/parameters-questionnaire-next-question-out-intro.xml to /app/temp/pages/_includes/parameters-questionnaire-next-question-out-intro.xml
[xslt] Processing /app/input/pagecontent/parameters-questionnaire-process-response-in-intro.xml to /app/temp/pages/_includes/parameters-questionnaire-process-response-in-intro.xml
[xslt] Processing /app/input/pagecontent/parameters-questionnaireresponse-extract-in-intro.xml to /app/temp/pages/_includes/parameters-questionnaireresponse-extract-in-intro.xml
[xslt] Processing /app/input/pagecontent/populate.xml to /app/temp/pages/_includes/populate.xml
[xslt] Processing /app/input/pagecontent/rendering.xml to /app/temp/pages/_includes/rendering.xml
[xslt] Processing /app/input/pagecontent/sdc-codesystem-examples-notes.xml to /app/temp/pages/_includes/sdc-codesystem-examples-notes.xml
[xslt] Processing /app/input/pagecontent/sdc-codesystem-intro.xml to /app/temp/pages/_includes/sdc-codesystem-intro.xml
[xslt] Processing /app/input/pagecontent/sdc-dataelement-examples-notes.xml to /app/temp/pages/_includes/sdc-dataelement-examples-notes.xml
[xslt] Processing /app/input/pagecontent/sdc-dataelement-intro.xml to /app/temp/pages/_includes/sdc-dataelement-intro.xml
[xslt] Processing /app/input/pagecontent/sdc-dataelement-notes.xml to /app/temp/pages/_includes/sdc-dataelement-notes.xml
[xslt] Processing /app/input/pagecontent/sdc-questionnaire-adapt-intro.xml to /app/temp/pages/_includes/sdc-questionnaire-adapt-intro.xml
[xslt] Processing /app/input/pagecontent/sdc-questionnaire-behave-intro.xml to /app/temp/pages/_includes/sdc-questionnaire-behave-intro.xml
[xslt] Processing /app/input/pagecontent/sdc-questionnaire-examples-notes.xml to /app/temp/pages/_includes/sdc-questionnaire-examples-notes.xml
[xslt] Processing /app/input/pagecontent/sdc-questionnaire-extract-intro.xml to /app/temp/pages/_includes/sdc-questionnaire-extract-intro.xml
[xslt] Processing /app/input/pagecontent/sdc-questionnaire-intro.xml to /app/temp/pages/_includes/sdc-questionnaire-intro.xml
[xslt] Processing /app/input/pagecontent/sdc-questionnaire-notes.xml to /app/temp/pages/_includes/sdc-questionnaire-notes.xml
[xslt] Processing /app/input/pagecontent/sdc-questionnaire-populate-intro.xml to /app/temp/pages/_includes/sdc-questionnaire-populate-intro.xml
[xslt] Processing /app/input/pagecontent/sdc-questionnaire-render-intro.xml to /app/temp/pages/_includes/sdc-questionnaire-render-intro.xml
[xslt] Processing /app/input/pagecontent/sdc-questionnaire-search-intro.xml to /app/temp/pages/_includes/sdc-questionnaire-search-intro.xml
[xslt] Processing /app/input/pagecontent/sdc-questionnaireresponse-examples-notes.xml to /app/temp/pages/_includes/sdc-questionnaireresponse-examples-notes.xml
[xslt] Processing /app/input/pagecontent/sdc-questionnaireresponse-intro.xml to /app/temp/pages/_includes/sdc-questionnaireresponse-intro.xml
[xslt] Processing /app/input/pagecontent/sdc-valueset-examples-notes.xml to /app/temp/pages/_includes/sdc-valueset-examples-notes.xml
[xslt] Processing /app/input/pagecontent/sdc-valueset-intro.xml to /app/temp/pages/_includes/sdc-valueset-intro.xml
[xslt] Processing /app/input/pagecontent/search.xml to /app/temp/pages/_includes/search.xml
[xslt] Processing /app/input/pagecontent/security.xml to /app/temp/pages/_includes/security.xml
[xslt] Processing /app/input/pagecontent/workflow.xml to /app/temp/pages/_includes/workflow.xml
onGenerate.processIg:
[xslt] Processing /app/template/onGenerate-ig-working.xml to /app/template/onGenerate-ig-working.1.xml
[xslt] Loading stylesheet /app/template/scripts/onGenerate.group.xslt
[xslt] Processing /app/template/onGenerate-ig-working.1.xml to /app/template/onGenerate-ig-updated.xml
[xslt] Loading stylesheet /app/template/scripts/onGenerate.final.xslt
onGenerate.artifactList:
[xslt] Processing /app/template/onGenerate-ig-updated.xml to /app/temp/pages/_includes/artifacts.xml
[xslt] Loading stylesheet /app/template/scripts/createArtifactSummary.xslt
onGenerate:
Generating Summary Outputs (02:04.0530)
Sending Usage Stats to Server (02:10.0588)
Jekyll: Source: /app/temp/pages (02:20.0513)
Jekyll: Generating... (02:20.0514)
ERRO[0158] error waiting for container: EOF
Grahame Grieve (Sep 09 2019 at 07:47):
so that also has the jekyll timeout....
Jens Villadsen (Sep 09 2019 at 07:48):
nop
Jens Villadsen (Sep 09 2019 at 07:48):
that simply fails
Grahame Grieve (Sep 09 2019 at 07:48):
well, that suggests that it's something more infrastructural than content (though it's not proof)
Grahame Grieve (Sep 09 2019 at 07:48):
ERRO[0158] error waiting for container: EOF
isn't that timeout?
Jens Villadsen (Sep 09 2019 at 07:48):
as suspected (from my side)
Jens Villadsen (Sep 09 2019 at 07:49):
no
Jens Villadsen (Sep 09 2019 at 07:49):
this happened almost instantly
Grahame Grieve (Sep 09 2019 at 07:50):
oh?
Jens Villadsen (Sep 09 2019 at 07:50):
wait a sec
Grahame Grieve (Sep 09 2019 at 07:50):
it's from the Apache code?
Jens Villadsen (Sep 09 2019 at 07:50):
docker crashed
Grahame Grieve (Sep 09 2019 at 07:50):
wooah
Grahame Grieve (Sep 09 2019 at 07:51):
one thing I've been wondering... can we make a -docker parameter which means that instead of running jekyll from the command line, we ask a (different) docker process to run it?
Grahame Grieve (Sep 09 2019 at 07:51):
I hd a quick look for Java code to do that, but didn't find anything. Google was overwhelmed with other stuff about running java on docker as a deployment thing
Jens Villadsen (Sep 09 2019 at 07:52):
that would be docker in docker ... for this setup I would not recommend it
Grahame Grieve (Sep 09 2019 at 07:53):
I though it would be asking the docker host to spawn another docker and then wait for it... but never mind... I'm just searching for a solution here. still Jekyll seems unhappy in docker. what happens if you run Jekyll manually in the docker on the SDC IG?
Jens Villadsen (Sep 09 2019 at 08:23):
Jenss-MacBook-Pro-2:sdc jvi$ docker run --rm -v ${PWD}/:/app/ igpublisher:localbuild /app/ig.ini
FHIR IG Publisher Version 0.9.69-SNAPSHOT - Built 2019-09-09T15:20:31.152+10:00 - Git bbf4b68a7f57
Detected Java version: 1.8.0_212 from /usr/lib/jvm/java-8-openjdk-amd64/jre on amd64 (64bit). 1820MB available
Parameters: -ig /app/ig.ini [dir = /]
Run time = Monday, September 9, 2019 8:17:20 AM UTC (2019-09-09T08:17:20Z)
Package Cache: /root/.fhir/packages (00:00.0076)
Contacting Build Server... (00:00.0094)
... done (00:01.0948)
Load Template from hl7.fhir.template (00:03.0236)
Installing hl7.fhir.template#current to the package cache
Fetching:...|
Analysing done.
onLoad.setup:
onLoad.r5-schemas:
[get] Getting: http://build.fhir.org/fhir-single.xsd
[get] To: /app/input-cache/schemas-r5/fhir-single.xsd
[get] Not modified - so not downloaded
[get] Getting: http://build.fhir.org/fhir-xhtml.xsd
[get] To: /app/input-cache/schemas-r5/fhir-xhtml.xsd
[get] Not modified - so not downloaded
[get] Getting: http://build.fhir.org/xml.xsd
[get] To: /app/input-cache/schemas-r5/xml.xsd
[get] Not modified - so not downloaded
[get] Getting: http://build.fhir.org/xmldsig-core-schema.xsd
[get] To: /app/input-cache/schemas-r5/xmldsig-core-schema.xsd
[get] Not modified - so not downloaded
onLoad.checkPublisher:
onLoad.upgradeWarning:
onLoad.findSpreadsheets:
onLoad.updateIg:
[xslt] Processing /app/template/onLoad-ig-working.xml to /app/template/onLoad-ig-updated.xml
[xslt] Loading stylesheet /app/template/scripts/onLoad.xslt
onLoad:
Root directory: /app (00:09.0427)
Installing hl7.fhir.core#4.0.0 to the package cache
Fetching:............................................................................................................
......................................................................................................................
.......................................................................................|
Analysing.............................................................................................................
......................................................................................................................
................................................... done.
Terminology Cache is at /app/input-cache/txcache. 12 files in cache (01:43.0508)
Connect to Terminology Server at http://tx.fhir.org (01:43.0572)
Initialization complete (01:46.0973)
Load Content (01:46.0973)
Processing Conformance Resources (01:49.0851)
Terminology server: Check for supported code systems for http://unstats.un.org/unsd/methods/m49/m49.htm (01:50.0201)
Generating Narratives (01:54.0063)
Validating Resources (01:54.0063)
Generating Outputs in /app/output (01:55.0920)
onGenerate.setup:
onGenerate.infoFile:
...
[xslt] Processing /app/input/pagecontent/sdc-valueset-examples-notes.xml to /app/temp/pages/_includes/sdc-valueset-examples-notes.xml
[xslt] Processing /app/input/pagecontent/sdc-valueset-intro.xml to /app/temp/pages/_includes/sdc-valueset-intro.xml
[xslt] Processing /app/input/pagecontent/search.xml to /app/temp/pages/_includes/search.xml
[xslt] Processing /app/input/pagecontent/security.xml to /app/temp/pages/_includes/security.xml
[xslt] Processing /app/input/pagecontent/workflow.xml to /app/temp/pages/_includes/workflow.xml
onGenerate.processIg:
[xslt] Processing /app/template/onGenerate-ig-working.xml to /app/template/onGenerate-ig-working.1.xml
[xslt] Loading stylesheet /app/template/scripts/onGenerate.group.xslt
[xslt] Processing /app/template/onGenerate-ig-working.1.xml to /app/template/onGenerate-ig-updated.xml
[xslt] Loading stylesheet /app/template/scripts/onGenerate.final.xslt
onGenerate.artifactList:
[xslt] Processing /app/template/onGenerate-ig-updated.xml to /app/temp/pages/_includes/artifacts.xml
[xslt] Loading stylesheet /app/template/scripts/createArtifactSummary.xslt
onGenerate:
Generating Summary Outputs (02:40.0705)
Sending Usage Stats to Server (02:49.0899)
Jekyll: Source: /app/temp/pages (02:57.0197)
Jekyll: Generating... (02:57.0197)
Jekyll: done in 26.797 seconds. (03:23.0998)
Installing hl7.fhir.uv.sdc#dev to the package cache
Fetching:.....|
Analysing.. done.
Checking Output HTML (03:30.0889)
found 1123 files (03:31.0535)
... 1123 html files, 0 pages invalid xhtml (0%) (04:12.0198)
... 509587 links, 2 broken links (0%) (04:12.0199)
Build final .zip (04:12.0203)
Final .zip built (04:18.0963)
context [anonymous] 2:13 attribute path isn't defined
Finished. 02:29.0112. Validation output in /app/output/qa.html
Errors: 156 Warnings: 398 Info: 0 (04:19.0317)
Done
Jens Villadsen (Sep 09 2019 at 08:24):
sdc works fine in docker
Jens Villadsen (Sep 09 2019 at 08:25):
i don't think jekyll is the issue here
Jens Villadsen (Sep 09 2019 at 08:54):
as it is not unhappy
Jens Villadsen (Sep 09 2019 at 11:21):
@Grahame Grieve any ideas to the next step of debugging?
Grahame Grieve (Sep 09 2019 at 11:28):
Hmmm. SDC does work under docker.... well. That’s challenging. What’s the size of the sdc temp directory compared to your ig?
Jens Villadsen (Sep 09 2019 at 11:58):
Size: 145.671.385 bytes (171,7 MB on disk) for 6.758 items
Jens Villadsen (Sep 09 2019 at 12:03):
that was SDC
Jens Villadsen (Sep 09 2019 at 12:12):
105.710.547 bytes (123,3 MB on disk) for 9.054 items for my own
Grahame Grieve (Sep 09 2019 at 19:03):
that doesn't feel like it. I wonder whether it's possible to debug Jekyll?
Jens Villadsen (Sep 10 2019 at 21:41):
I'll start by adding --verbose to jekyll args ...
Grahame Grieve (Sep 10 2019 at 22:13):
I could add that as a flag...
Jens Villadsen (Sep 11 2019 at 18:44):
I've got the source to igpub ... so I'll just do it locally for now
Grahame Grieve (Sep 11 2019 at 18:44):
ok
Jens Villadsen (Sep 11 2019 at 18:45):
I don't have the same anxiety towards maven ... ;)
Jens Villadsen (Sep 11 2019 at 20:57):
I think I found the bug - at least removing some content made it pass through. It's due to some extra tabs we've added as part of the generation process. Content in these extra tabs contains markdown. This markdown is probably badly formatted which causes Jekyll to hang. Why it only does it in Docker beats me
Jens Villadsen (Sep 11 2019 at 20:58):
Maybe a linefeed or something ... The docker container always runs in a linux environment ...
Grahame Grieve (Sep 11 2019 at 20:58):
that's.... weird
Jens Villadsen (Sep 11 2019 at 21:00):
indeed
Last updated: Apr 12 2022 at 19:14 UTC
