Run Jira as a systemd service on linux

 

Purpose

This article explains how to install Jira as a systemd service in Linux. 

Pre-requisites

Jira is installed and working but does not automatically start on boot. For example, Jira is installed via the .zip package rather than the .bin installer, or you have migrated JIRA to a different server.

Solution

• 1. Login to the Jira application server as the root user.

  2. Create the following systemd unit file for the JIRA service as root:

     touch /lib/systemd/system/jira.service
     chmod 664 /lib/systemd/system/jira.service

  3. Edit the systemd unit file as root:

     vi /lib/systemd/system/jira.service

  4. Add the following content into the systemd unit file to define the JIRA service:

     [Unit] 
     Description=Atlassian Jira
     After=network.target
     
     [Service] 
     Type=forking
     User=jira
     LimitNOFILE=20000
     PIDFile=/opt/atlassian/jira/work/catalina.pid
     ExecStart=/opt/atlassian/jira/bin/start-jira.sh
     ExecStop=/opt/atlassian/jira/bin/stop-jira.sh
     
     [Install] 
     WantedBy=multi-user.target 

      The above defined 'jira' user would be the user that is used to run JIRA, change this if you are running JIRA under a different user.

      '/opt/atlassian/jira' would be the default Jira installation path, change this if your Jira installation path is different.
      Do not run Jira in the foreground, as this will prevent the file 'catalina.out' from being created. 

  5. Enable the service and start it:

     systemctl daemon-reload
     systemctl enable jira.service
     systemctl start jira.service
     systemctl status jira.service

      In some instances, you may see the following error message when attempting to enable the Jira service:

     systemctl enable jira.service
     Synchronizing state of jira.service with SysV service script with /lib/systemd/systemd-sysv-install.
     Executing: /lib/systemd/systemd-sysv-install enable jira
     update-rc.d: error: jira Default-Start contains no runlevels, aborting.

      This may be due to a previously created Jira service file. To resolve this, users may perform the following depending on their environment:
     
     

  6. If the file exists, backup up the previous Jira service file and then remove it before enabling the new Jira service file:

     cp /etc/init.d/jira /opt/atlassian/jira-init.d.bak && rm /etc/init.d/jira
     sudo systemctl enable jira.service
     Created symlink /etc/systemd/system/multi-user.target.wants/jira.service → /lib/systemd/system/jira.service.

      Furthermore, we recommend either disabling SELinux policies or thoroughly validating them.

Read More

How to list all enabled services from systemctl?

How can I list all enabled services from systemctl?

I know running systemctl command by itself lists all services, but I would like to only get the enabled ones.

------

Answer:

How can I list all enabled services from systemctl?

I know running systemctl command by itself lists all services, but I would like to only get the enabled ones.

Read More

How to Switch Namespaces in Kubernetes

 

1. Overview

In a Kubernetes cluster, namespaces provide a way to partition resources and isolate workloads. They act as virtual clusters within a physical cluster, enabling multiple teams or projects to run independently. Switching namespaces allows administrators or developers to work with different sets of resources within the same cluster.

In this tutorial, we’ll explore various methods to switch namespaces in Kubernetes, providing the flexibility to manage workloads effectively.

2. Switching Namespaces Using the kubectl Command

The primary interface for interacting with Kubernetes clusters is the kubectl command-line tool. To switch to a specific namespace, we can use the kubectl config set-context command. Let’s see how:

$ kubectl config set-context --current --namespace=<namespace-name>

We replace namespace-name with the name of the desired namespace we want to switch to. For instance, let’s switch to the namespace named “kube-public” using the kubectl command:

$ kubectl config set-context --current --namespace=kube-public
Context "minikube" modified.

Once we execute this command, the context of our kubectl configuration will update to the new namespace. Subsequent commands will operate within this namespace by default.

3. Using the kubectl Command With the –namespace Flag

Alternatively, we can use the –namespace flag directly with the kubectl command to switch namespaces for a specific command. This approach is useful when we want to run isolated commands within a different namespace without changing the default context.

For example, let’s list all the pods in the “kube-public” namespace:

$ kubectl get pods --namespace=kube-public 
No resources found in kube-public namespace.

This command retrieves the pod information from the specified namespace.

4. Setting Namespace in Kubernetes Configuration Files

If we frequently work with a particular namespace, we can set it as the default namespace in our Kubernetes configuration file. This approach ensures that every kubectl command operates within the specified namespace unless overridden.

To set the default namespace, we need to open our Kubernetes configuration file (usually located at ~/.kube/config) and locate the contexts section. We can add or modify the context entry to include the namespace field:

contexts:
- context:
    cluster: my-cluster
    user: my-user
    namespace: my-namespace
  name: my-context

We save the configuration file, and from now on, any kubectl command executed without explicitly specifying a namespace will operate within the default namespace.

5. Conclusion

Mastering the ability to switch namespaces in Kubernetes equips us with powerful tools for effectively managing workloads and maintaining resource isolation within virtual clusters.

In this article, we’ve delved into various methods, such as utilizing the kubectl command with the –namespace flag, modifying the Kubernetes configuration file, and updating the context with the kubectl config set-context command.

By leveraging these techniques, we gain the flexibility to seamlessly navigate and interact with multiple namespaces within our Kubernetes cluster, enabling us to efficiently organize and control our applications and resources. With a solid understanding of namespace switching, we can optimize our workflow and ensure a well-structured Kubernetes environment tailored to our specific needs.

Read More