LIGHT

  • News
  • Docs
  • Community
  • Reddit
  • GitHub
Star

Linux Service

Running Light-4J Application as Linux Service

The light-4j application can be easily started as a Unix/Linux service using either init.d or systemd given it is packaged as a fatjar.

Installation as an init.d service (System V)

If your application is packaged as a fatjar, and you’re not using a custom script, then your application can be used as an init.d service. Simply symlink the jar to init.d to support the standard start, stop, restart and status commands.

The script supports the following features:

  • Starts the services as the user that owns the jar file
  • Tracks application’s PID using /var/run//.pid
  • Writes console logs to /var/log/.log

Assuming that you have a light-4j application installed in /var/myapp, to install the application as an init.d service, simply create a symlink:

sudo ln -s /var/myapp/myapp.jar /etc/init.d/myapp

Once installed, you can start and stop the service in the usual way. For example, on a Debian based system:

service myapp start

You can also flag the application to start automatically using your standard operating system tools. For example, on Debian:

update-rc.d myapp defaults <priority>

Securing an init.d service

When executed as a root, as is the case when the root is being used to start an init.d service, the default executable script will run the application as the user which owns the jar file. You should never run a light-4j application as a root, thus, your application’s jar file should never be owned by the root. Instead, create a specific user to run your application and use chown to make it the owner of the jar file. For example:

chown bootapp:bootapp your-app.jar

In this case, the default executable script will run the application as the bootapp user.

To reduce the chances of the application’s user account being compromised, you should consider preventing it from using a login shell. Set the account’s shell to /usr/sbin/nologin, for example.

You should also take steps to prevent the modification of your application’s jar file. Firstly, configure its permissions so that it cannot be written and can only be read or executed by its owner:

chmod 500 your-app.jar

Secondly, you should also take steps to limit the damage if your application or the account that’s running it is compromised. If an attacker does gain access, they could make the jar file writable and change its contents. One way to protect against this is to make it immutable using chattr:

sudo chattr +i your-app.jar

It will prevent any user, including root, from modifying the jar.

The user root is used to control the application’s service, and you use a .conf file to customize its startup, the .conf file will be read and evaluated by the root user. It should be secured accordingly. Use chmod so that only the owner can read the file and use chown to make the root the owner:

chmod 400 your-app.conf
sudo chown root:root your-app.conf

Externalize Configuration

For production deployment, you need to externalize your configuration to a folder so that it can be easily updated.

Update your command line to add -Dlight-4j-config-dir=/etc/yourappconfig

Please follow the config module document for details on how config files are loaded.

Forward Port 443

As the process is running with a non-root user, there is no way that you can bind the port 443. Please follow this tutorial to upddate iptables to redirect 443 to 8443 on your VM.

See Also

  • Windows Service
  • Frontend Backend
  • About Light
    • Overview
    • Testimonials
    • What is Light
    • Features
    • Principles
    • Benefits
    • Roadmap
    • Community
    • Articles
    • Videos
    • License
    • Why Light Platform
  • Getting Started
    • Get Started Overview
    • Environment
    • Light Codegen Tool
    • Light Rest 4j
    • Light Tram 4j
    • Light Graphql 4j
    • Light Hybrid 4j
    • Light Eventuate 4j
    • Light Oauth2
    • Light Portal Service
    • Light Proxy Server
    • Light Router Server
    • Light Config Server
    • Light Saga 4j
    • Light Session 4j
    • Webserver
    • Websocket
    • Spring Boot Servlet
  • Architecture
    • Architecture Overview
    • API Category
    • API Gateway
    • Architecture Patterns
    • CQRS
    • Eco System
    • Event Sourcing
    • Fail Fast vs Fail Slow
    • Integration Patterns
    • JavaEE declining
    • Key Distribution
    • Microservices Architecture
    • Microservices Monitoring
    • Microservices Security
    • Microservices Traceability
    • Modular Monolith
    • Platform Ecosystem
    • Plugin Architecture
    • Scalability and Performance
    • Serverless
    • Service Collaboration
    • Service Mesh
    • SOA
    • Spring is bloated
    • Stages of API Adoption
    • Transaction Management
    • Microservices Cross-cutting Concerns Options
    • Service Mesh Plus
    • Service Discovery
  • Design
    • Design Overview
    • Design First vs Code First
    • Desgin Pattern
    • Service Evolution
    • Consumer Contract and Consumer Driven Contract
    • Handling Partial Failure
    • Idempotency
    • Server Life Cycle
    • Environment Segregation
    • Database
    • Decomposition Patterns
    • Http2
    • Test Driven
    • Multi-Tenancy
    • Why check token expiration
    • WebServices to Microservices
  • Cross-Cutting Concerns
    • Concerns Overview
  • API Styles
    • Light-4j for absolute performance
    • Style Overview
    • Distributed session on IMDG
    • Hybrid Serverless Modularized Monolithic
    • Kafka - Event Sourcing and CQRS
    • REST - Representational state transfer
    • Web Server with Light
    • Websocket with Light
    • Spring Boot Integration
    • Single Page Application
    • GraphQL - A query language for your API
    • Light IBM MQ
    • Light AWS Lambda
    • Chaos Monkey
  • Infrastructure Services
    • Service Overview
    • Light Proxy
    • Light Mesh
    • Light Router
    • Light Portal
    • Messaging Infrastructure
    • Centralized Logging
    • COVID-19
    • Light OAuth2
    • Metrics and Alerts
    • Config Server
    • Tokenization
    • Light Controller
  • Tool Chain
    • Tool Chain Overview
  • Utility Library
  • Service Consumer
    • Service Consumer
  • Development
    • Development Overview
  • Deployment
    • Deployment Overview
    • Frontend Backend
    • Linux Service
    • Windows Service
    • Install Eventuate on Windows
    • Secure API
    • Client vs light-router
    • Memory Limit
    • Deploy to Kubernetes
  • Benchmark
    • Benchmark Overview
  • Tutorial
    • Tutorial Overview
  • Troubleshooting
    • Troubleshoot
  • FAQ
    • FAQ Overview
  • Milestones
  • Contribute
    • Contribute to Light
    • Development
    • Documentation
    • Example
    • Tutorial
“Linux Service” was last updated: April 5, 2021: Issue246 (#256) (50b1c10)
Improve this page
  • News
  • Docs
  • Community
  • Reddit
  • GitHub
  • About Light
  • Getting Started
  • Architecture
  • Design
  • Cross-Cutting Concerns
  • API Styles
  • Infrastructure Services
  • Tool Chain
  • Utility Library
  • Service Consumer
  • Development
  • Deployment
  • Benchmark
  • Tutorial
  • Troubleshooting
  • FAQ
  • Milestones
  • Contribute