nla / jvmctl Goto Github PK

• CLI options for the daemon
• Socket activation (accept listening socket on stdin)
• Graceful restart/reload (passing open fds and serialized state to successor)
• Close log files that are idle.
• Persist unit name from socket establishment so messages from a now exited process are directed to the right file.
• Daemon handling of secondary pipes like gc logs (logduct-run transfer them but they're currently ignored)
• Log expiry
• Decide compression policy
• jvmctl integration
  • global logruct-run wrapping
  • log command
  • status command
• Test failure behaviour
  • Disk full
  • Daemon killed
  • Permission denied writing to log files
  • Memory leak check
  • Full system reboot

Some people want to run scripts post-deploy. For example:

• Moving static assets around
• Restarting dependent processes
• Triggering database migrations

Sometimes they abuse nla-deploy.sh to try to do these things. It usually ends in tears.

We maybe should support something like this officially but it's not clear to me exactly how the feature should work.

Maybe give up and print a deprecation warning instead.

So that if you mount it on another host the link is not broken.

/cc @brycollins @JonathanShaw

It seems on RHEL 9 the contents of /proc/{pid}/cgroup changed from

 1:name=systemd:/system.slice/jvm:myapp.service

to

 0::/system.slice/jvm:myapp.service

This causes logductd to fail to detect the systemd unit name and ignore all received log messages.

CC: @JonathanShaw @sdarvell @brycollins

• jvmctl needs to make tailing easy
• Shift-F Shift-G etc in less hangs on large log files
• Leading whitespace indentation is stripped (makes stack traces hard to distinguish)
• Ctrl+C leads to terminal screwed upness (check less flags?)
• Slow (to grep, seek etc)

The config directory becomes a git repo and jvmctl config automatically commits to it. To avoid dealing with authentication data leaks etc no pushing to a central server (the intent is you could pull if desired for backups). Add a new history command that runs git log -p.

Migration mechanism: the first config change should git init and commit everything.

https://github.com/nla/jvmctl/blob/master/jvmctl/jvmctl/jvmctl.py#L427

In this particular instance I need it for running Solr as a command line application because is scans the working directory for contexts.

Looks like something like this in the the conf file would be basic to add:
WORKING_DIR=/some/random/path

The name "gs-rest-service-master" confuses the logging daemon as it does a regex search for "jvm:(.+).service". The . should be a literal not a wildcard match so we need to fix it to match with .service instead.

Need to remove systemd unit file and /var/cache/jvmctl/base/$NODE

Often we're asked to help compile a list of applications a particular branch is responsible for.

Perhaps jvmctl could asynchronously push the app name, branch version and hostname to a central repository on deploy and or start.
An optional conf variable for owner could be added and pushed aswell.
Start time could also be included, which would help show application uptimes in an app dashboard or something of that kind.
It might help to maintain an application register.

Just an idea..

Probably need an install section in the generated systemd unit file:

[Install]
WantedBy=multi-user.target

Also make sure it calls systemctl enable at some point.

This change conflicts with our model of a read-only jetty base directory:
jetty/jetty.project@837a36e

A second commit makes the properties file path configurable
jetty/jetty.project@aca2aa5

So probably our best bet is to specify a path in /var/run/. Presumably older versions of Jetty error when given that argument though so we'll have to gate it on jetty version somehow.

Workarounds for now either:

• Use a version of Jetty prior to this change
• Manually make jetty base directory writable by the user the application is running as.

Suggested by Shaun D