Fork me on GitHub

We are deploying an Uberjar to a Docker container and after about 19 days the docker reports a graceful shutdown:

app  | 1702694476 INFO  app.core - Shutting down system.                                                                                                                                                                                 
app exited with code 143
app exited with code 0
We are using this as our -main:
(defn -main [& _]
  (let [system (prod-system)
        shutdown-promise (promise)]
    (.addShutdownHook (Runtime/getRuntime) (Thread. (fn []
                                                      (log/info "Shutting down system.")
                                                      (component/stop-system system)
                                                      (deliver shutdown-promise true))))
    (component/start system)
The strange thing is the container is still running and the app is still responsive. Any suggestions on how to debug this greatly appreciated.


exit code 143 means there was SIGTERM signal sent to your application. you could monitor docker events to see if this happens due to some error, low memory for example


how are you running the container?


Through a docker-compose with restart: unless-stopped and a Dockerfile (`eclipse-temurin:17-jre`) with CMD ["java", "-Dhttp.proxyHost=...", "-Dhttp.proxyPort=80", "-Dhttps.proxyHost=...", "-Dhttps.proxyPort=80", "-Dconf=/app/conf.edn", "-jar", "/app/app.jar"].


Looking through the docker events log right now. Doesn't seem to be OOM.


Oh. The last time it occured was further back than 1000 log entries. I guess I will have to wait until it occurs again.


btw, there are --since and --until options for docker events so you can fetch events around exact time of exit


Yeah, I tried that, but it does not go back far enough.


The last event occured on Jan 9th and it only goes back to the 25th


At the time I didn't realize anything happened since the application kept on working


Ah it probably kept working since I have restart: unless-stopped


Guess I will get rid of that for now


Figured out what it was when it happened again today. We enabled automatic upgrades with dnf-automatic and it had an update for containerd which caused docker to restart.

Ian Fernandez14:01:31

Is there a way to open a repl server in another thread, send some stuff to it and see if it continues to work and then turn it down?

Ian Fernandez14:01:52

My idea is to have a test to prohibit people to break repl driven with certain commands

Phillip Mates14:01:48

👋 I was looking to add a reader macro extension for a symbolic value, along the lines of the existing ##Inf and ##NaN, and I'm curious if there is a specific reason for that? For context, I work with a weird database that represents the absence of a date using the smallest date value: (java.sql.Date. -1899 0 1). I got to thinking it would be nice to be able to write queries like [:= :some-field ##null-db-date] instead of using a tagged literal like [:= :some-field #sql-date "0001-01-01"]


main idea behind it is not extendable is that clojure code must remains "readable" to the standard Clojure. and that is not achievable if it would be possible to introduce something like you describe in original question.

Phillip Mates15:01:50

I'm not sure I follow that reasoning. Like wouldn't that apply to ability to define your own tagged value readers?


to some degree - yes. official, defined through api, scope for tagged literals is clojure.edn/read which accept mapping from tag to function and clojure.core/read which can use redefined mapping. That way it is possible to at least read tagged literal as is even if you don't have the implementation for actual reading function.

Alex Miller (Clojure team)15:01:38

symbolic values are a tool for us, not for you :)


at least this is my understanding

Alex Miller (Clojure team)15:01:58

tagged literals are a tool for you


just out of curiosity, why the need for a data literal? Wouldn't a (def null-db-date (Date. -1899 0 1)) suffice?

Phillip Mates15:01:32

> just out of curiosity, why the need for a data literal? Wouldn't a (def null-db-date (Date. -1899 0 1)) suffice? also possible, but it would require the namespace that contains null-db-date to be required. And also doesn't work when writing out to edn files


yeah, it wouldn't work for edn files. I guess you could always define a custom reader, e.g. #null-db-date "" or maybe #my/sql-date (i.e. support both #my/sql-date "2020-01-02" and #my/sql-date "none")

Phillip Mates15:01:03

> symbolic values are a tool for us, not for you 🙂 I can understand not wanting to expand the surface area of this for a feature that would rarely make sense to use by clojure programmers (especially with the point @U04V4KLKCmade about a default reader). Yet in this case I don't know how much I understand or buy this "us/you" distinction. I see the capability to define and use one's own special constants a useful tool to both Clojure maintainers and maintainers of systems written in Clojure

Alex Miller (Clojure team)15:01:30

that's what tagged literals are for

Alex Miller (Clojure team)15:01:39

and edn does support, not sure I understand that complaint above

Alex Miller (Clojure team)15:01:07

and notably, edn does NOT support symbolic values

👍 2

Why not [:= :some-field the-null-db-date] where the-null-db-date is normal var

Phillip Mates09:01:22

I think it is the same as @U05476190 suggested. Totally works, differing only in that it requires requiring the namespace everywhere it is used, but perhaps that is a good thing.

Phillip Mates09:01:57

Anyways, wanted to thank everyone for exploring this question. I really love Clojure because it almost never prevents me from implementing the ideas I have in my head. The times that I do run up against the limits of the language, I often realize that it is me that was misguided in my framing of the problem/solution. This feels very mind-expanding and so very contrary to so many other languages out there.


Hey folks. Just about to open-source a number of libraries in case people might find them useful. Any suggestions for how to do that? Just post them here on Clojurians? Or...


To clarify, I'm just referring to the "getting it out there" bit so it reaches whomever might find it useful. Not deploying or whatnot.


If you want to reach as many eyes as possible, I'd post in every place mentioned at

👍 2

That's really helpful, thanks!


Remember to include the purpose of each library so people know why they should look at them. 😁 I see a lot of things posted in #C06MAR553 that I don't look at because I don't know what they are (and my learning Todo list is already quite long)

👍 2

A nice, I didn't even know about that channel. Thanks!


What’s a good way to impliment a union find aka in clojure?


Are there some good blog articles or other resources on investigating memory leaks in Clojure code?

delaguardo16:01:22 yourkit has very good memory profiler


Thanks @U04V4KLKC! I love the look of that program


I think I would see the problem immediately if I saw the names of my oldest objects


Something sticks around 🙂


That was super effective @U04V4KLKC - thanks for the prod. I've heard about YourKit before and even tried it a bunch of years ago. It's pretty discoverable.


And fixed! It was almost worth writing the buggy code for the fun experience of finding what was wrong. I hope my subconscious isn't listening and getting any ideas. Thanks again.


There's also this which I only used one time when yourkit /visualVM were failing me for discovering a memory leak, and I forgot the details but just remember it seemed magic in the way it just told me directly what was causing my memory leak