How to Manage Linux Services: Start, Stop, and Restart (Daemon Hunting?) with commands

How to Manage Linux Services: Start, Stop, and Restart (Daemon Hunting?) with commands

This section explains the procedures to manage Linux Services: Start, Stop, and Restart (Daemon Hunting?) with commands


Topics:

  • Starting and Stopping the Daemon

Start and stop the daemon and force the daemon to stop a health check run.

  • Configuring the Daemon for Automatic Restart


By default, you must manually restart the daemon if you restart the server or node on which the daemon is running.

  • Setting and Getting Options for the Daemon


Set the daemon options before you start the daemon. Reset the daemon options anytime after starting the daemon.

  • Querying the Status and Next Planned Daemon Run


Query the status and next automatic run schedule of the running daemon. 



2.4.1 Starting and Stopping the Daemon

Start and stop the daemon and force the daemon to stop a health check run.

To start and stop the daemon:


1. To start the daemon, use the –d start option as follows:

command:

$ ./orachk –d start


$ ./exachk –d start

The tools prompt you to provide required information during startup.


2. To stop the daemon, use the –d stop option as follows:

command:

$ ./orachk –d stop


$ ./exachk –d stop

If a health check run is progress when you run the stop command, then the daemon indicates so and continues running.



3. To force the daemon to stop a health check run, use the –d stop_client option:

 command:

$ ./orachk –d stop_client


$ ./exachk –d stop_client


The daemon stops the health check run and then confirms when it is done. If necessary, stop the daemon using the –d stop option.

2.4.2 Configuring the Daemon for Automatic Restart

By default, you must manually restart the daemon if you restart the server or node on which the daemon is running.

However, if you use the automatic restart option, the daemon restarts automatically after the server or node reboot.

Restarting the daemon automatically requires passwordless SSH user equivalence to root for the user who is configuring the auto-start feature, for example, root or oracle. If passwordless SSH user equivalence is not in place, then Oracle ORAchk and Oracle EXAchk optionally configure for you.

The passwordless SSH user equivalence is retained as long as the daemon automatic restart functionality is configured.

Deconfiguring the daemon automatic restart feature restores the SSH configuration to the state it was found before automatic restart was configured.

To configure the daemon to start automatically:

If a health check run is progress when you run the stop command, then the daemon indicates so and continues running.



3. To force the daemon to stop a health check run, use the –d stop_client option:

The daemon stops the health check run and then confirms when it is done. If necessary, stop the daemon using the –d stop option.

To set up daemon automatic restart, use –initsetup:

 command:

$ ./orachk –initsetup


$ ./exachk –initsetup

The tool prompts you to provide the required information during startup.

✎Note: Stop the daemon before running –initsetup, if the daemon is already running.

Pre-configure root user equivalence for all COMPUTE, STORAGE, or IBSWITCHES using the –initpresetup option (root equivalency for COMPUTE nodes is mandatory for setting up the automatic restart functionality):


 command:

$ ./orachk –initpresetup


$ ./exachk –initpresetup

To query automatic restart status of the daemon, use –initcheck:


 command:

$ ./orachk –initcheck


$ ./exachk –initcheck

To remove automatic restart configuration, use –initrmsetup :

 command:

$ ./orachk –initrmsetup


$ ./exachk –initrmsetup


2.4.3 Setting and Getting Options for the Daemon

Set the daemon options before you start the daemon. Reset the daemon options anytime after starting the daemon.

To set the daemon options:


1. Set the daemon options using the –set option.
Set an option as follows:

 command:

$ ./orachk –set "option_1=option_1_value"


$ ./exachk –set "option_1=option_1_value"

Set multiple options using the name=value format separated by semicolons as follows:

 command:

$ ./orachk –set "option_1=option_1_value;option_2=option_2_value;option_n=option_n_value"


$ ./exachk –set "option_1=option_1_value;option_2=option_2_value;option_n=option_n_value"


Topics:

  • AUTORUN_SCHEDULE
Schedule recurring health check runs using the AUTORUN_SCHEDULE daemon option.
  • AUTORUN_FLAGS
The AUTORUN_FLAGS daemon option determines how health checks are run.

  • NOTIFICATION_EMAIL
Set the NOTIFICATION_EMAIL daemon option to send email notifications to the recipients you specify.

  • collection_retention

Set the collection_retention daemon option to purge health check collection results that are older than a specified number of days.
  • PASSWORD_CHECK_INTERVAL
The PASSWORD_CHECK_INTERVAL daemon option defines the frequency, in hours, for the daemon to validate the passwords entered when the daemon was started the first time.
  • AUTORUN_INTERVAL
The AUTORUN_INTERVAL daemon option provides an alternative method of regularly running health checks.
  • Setting Multiple Option Profiles for the Daemon
Use only one daemon process for each server. Do not start a single daemon on multiple databases in a cluster, or multiple daemons on the same database.
  • Getting Existing Options for the Daemon
Query the values that you set for the daemon options.


2.4.2.1 AUTORUN_SCHEDULE


Schedule recurring health check runs using the AUTORUN_SCHEDULE daemon option.

To schedule recurring health check runs:


  1. Set the AUTORUN_SCHEDULE option, as follows:

AUTORUN_SCHEDULE=hour day month day_of_week

where:
  • hour is 0–23
  • day is 1–31
  • month is 1–12

day_of_week is 0–6, where 0=Sunday and 6=Saturday

Use the asterisk (*) as a wildcard to specify multiple values separated by commas.

Table 2-1 AUTORUN_SCHEDULE




For example:


Command:

$ ./orachk –set "AUTORUN_SCHEDULE=3 * * 0"

$ ./exachk –set "AUTORUN_SCHEDULE=3 * * 0"


2.4.2.2 AUTORUN_FLAGS

The AUTORUN_FLAGS daemon option determines how health checks are run.

To configure how health checks should run:


  1. Set the AUTORUN_FLAGS option as follows:

Command:

AUTORUN_FLAGS=flags

where, flags can be any combination of valid command-line flags.


Table 2-2 AUTORUN_FLAGS


For Example:

Command:

      $ ./orachk –set "AUTORUN_FLAGS=-profile sysadmin –tag sysadmin"

     $ ./exachk –set "AUTORUN_FLAGS=-profile sysadmin –tag sysadmin"

2.4.2.3 NOTIFICATION_EMAIL

Set the NOTIFICATION_EMAIL daemon option to send email notifications to the recipients you specify.

To configure email notifications:

  1. Specify a comma-delimited list of email addresses, as follows:
$ ./orachk –set "NOTIFICATION_EMAIL=some.person@acompany.com,another.person@acompany.com"

$ ./exachk –set "NOTIFICATION_EMAIL=some.person@acompany.com,another.person@acompany.com"


2. Test the email notification configuration using the –testemail option, as follows:

Commands:

$ ./orachk -testemail all


$ ./exachk -testemail all


After the first health check run, the daemon notifies the recipients with report output attached.

For the subsequent health check runs after the first email notification, the daemon emails the summary of differences between the most recent runs to all recipients specified in the NOTIFICATION_EMAIL list.

2.4.2.4 collection_retention

Set the collection_retention daemon option to purge health check collection results that are older than a specified number of days.

 ✎Note: Specify the collection_retention option in lower case.

To configure collection retention period:

1. Set the collection_retention option, as follows:

Command:

collection_retention=number_of_days

If you do not set this option, then the daemon does not purge the stale collection.

2. Set the collection_retention option to an appropriate number of days based on:

  • Frequency of your scheduled collections
  • Size of the collection results
  • Available disk space

For example:


$ ./orachk –set "collection_retention=60"


$ ./exachk –set "collection_retention=60"

2.4.2.5 PASSWORD_CHECK_INTERVAL


The PASSWORD_CHECK_INTERVAL daemon option defines the frequency, in hours, for the daemon to validate the passwords entered when the daemon was started the first time.

If an invalid password is found due to a password change, then the daemon stops, makes an entry in the daemon log, and then sends an email notification message to the recipients specified in the NOTIFICATION_EMAIL option.

To configure password validation frequency:


1. Set the PASSWORD_CHECK_INTERVAL option, as follows:

Command:
PASSWORD_CHECK_INTERVAL=number_of_hours

If you do not set the PASSWORD_CHECK_INTERVAL option, then the daemon cannot actively check password validity and fails the next time the daemon tries to run after a password change. Using the PASSWORD_CHECK_INTERVAL option enables you to take corrective action and restart the daemon with the correct password rather than having failed collections.

2. Set the PASSWORD_CHECK_INTERVAL option to an appropriate number of hours based on:

  • Frequency of your scheduled collections
  • Password change policies

For example:


$ ./orachk –set "PASSWORD_CHECK_INTERVAL=1"

$ ./exachk –set "PASSWORD_CHECK_INTERVAL=1"

2.4.2.6 AUTORUN_INTERVAL

The AUTORUN_INTERVAL daemon option provides an alternative method of regularly running health checks.

✎Note:The AUTORUN_SCHEDULE option supersedes the AUTORUN_INTERVAL option. The AUTORUN_INTERVAL option is retained for backwards compatibility. Oracle recommends that you use the AUTORUN_SCHEDULE option.

To configure recurring health check runs:


Set the AUTORUN_INTERVAL option, as follows:

AUTORUN_INTERVAL=n [d | h]

  where:
    • n is a number
    • d is days
    • h is hours

Table 2-3 AUTORUN_INTERVAL








2.4.2.7 Setting Multiple Option Profiles for the Daemon

Use only one daemon process for each server. Do not start a single daemon on multiple databases in a cluster, or multiple daemons on the same database.

The daemon does not start, if the daemon detects another Oracle ORAchk or Oracle EXAchk daemon process running locally.

Define multiple different run profiles using the same daemon. Defining multiple different run profiles enables you to run multiple different health checks with different daemon options, such as different schedules, email notifications, and automatic run flags. The daemon manages all profiles.

To set multiple option profiles for the daemon:


1. Define daemon option profiles using the –id id option before the –set option.

Where, id is the name of the profile


$ ./orachk –id id –set "option=value"

$ ./exachk –id id –set "option=value"

For example, if the database administrator wants to run checks within the dba profile and the system administrator wants to run checks in the sysadmin profile, then configure the daemon using the profiles option.

Define the database administrator profile as follows:


$ ./orachk –id dba –set "NOTIFICATION_EMAIL=dba@example.com;\
   AUTORUN_SCHEDULE=4,8,12,16,20 * * *;AUTORUN_FLAGS=-profile dba –tag dba;\
   collection_retention=30"

Created notification_email for ID[dba]
Created autorun_schedule for ID[dba]
Created autorun_flags for ID[dba]
Created collection_retention for ID[dba]



$ ./exachk –id dba –set "NOTIFICATION_EMAIL=dba@example.com;\
   AUTORUN_SCHEDULE=4,8,12,16,20 * * *; AUTORUN_FLAGS=-profile dba –tag dba;\
   collection_retention=30"

Created notification_email for ID[dba]
Created autorun_schedule for ID[dba]
Created autorun_flags for ID[dba]
Created collection_retention for ID[dba]

Define the system administrator profile as follows:

$ ./orachk –id sysadmin –set "NOTIFICATION_EMAIL=sysadmin@example.com;\
   AUTORUN_SCHEDULE=3 * * 1,3,5; AUTORUN_FLAGS=-profile sysadmin –tag sysadmin;\
   collection_retention=60"

Created notification_email for ID[sysadmin]
Created autorun_schedule for ID[sysadmin]
Created autorun_flags for ID[sysadmin]
Created collection_retention for ID[sysadmin]



$ ./exachk –id sysadmin –set "NOTIFICATION_EMAIL=sysadmin@example.com;\
   AUTORUN_SCHEDULE=3 * * 1,3,5; AUTORUN_FLAGS=-profile sysadmin –tag sysadmin;\
   collection_retention=60"

Created notification_email for ID[sysadmin]
Created autorun_schedule for ID[sysadmin]
Created autorun_flags for ID[sysadmin]
Created collection_retention for ID[sysadmin]


2.4.2.7 Getting Existing Options for the Daemon

Query the values that you set for the daemon options.

To query the values, use


[-id ID] -get option | all

  where:
    • ID is a daemon option profile
    • option is a specific daemon option you want to retrieve
    • all returns values of all options

To get existing options for the daemon:


1. To get a specific daemon option:

For example:

$ ./orachk –get NOTIFICATION_EMAIL

ID: orachk.default
------------------------------------------
notification_email = some.body@example.com


$ ./exachk –get NOTIFICATION_EMAIL

ID: exachk.default
------------------------------------------
notification_email = some.body@example.com


2. To query multiple daemon option profiles:

For example:

$ ./orachk –get NOTIFICATION_EMAIL

ID: orachk.default
------------------------------------------
notification_email = some.body@example.com

ID: dba
------------------------------------------
notification_email = dba@example.com


ID: sysadmin
------------------------------------------
notification_email = sysadmin@example.com



$ ./exachk –get NOTIFICATION_EMAIL

ID: exachk.default
------------------------------------------
notification_email = some.person@example.com

ID: dba
------------------------------------------
notification_email = dba@example.com


ID: sysadmin
------------------------------------------
notification_email = sysadmin@example.com

3. To limit the request to a specific daemon option profile, use the –id ID -get option option:

For example:

To get the NOTIFICATION_EMAIL  for a daemon profile called dba :



$ ./orachk –id dba –get NOTIFICATION_EMAIL

ID: dba
------------------------------------------
notification_email = dba@example.com

Copy
$ ./exachk –id dba –get NOTIFICATION_EMAIL

ID: dba
------------------------------------------
notification_email = dba@example.com

4. To get all options set, use the –get all option:

For example:

$ ./orachk –get all

ID: orachk.default
------------------------------------------
notification_email = some.body@example.com
autorun_schedule = 3 * * 0
collection_retention = 30
password_check_interval = 1


$ ./exachk –get all

ID: exachk.default
------------------------------------------
notification_email = some.body@example.com
autorun_schedule = 3 * * 0
collection_retention = 30
password_check_interval = 1

5. To query all daemon option profiles:

For example:

$ ./orachk –get all

ID: orachk.default
------------------------------------------
notification_email = some.body@example.com
autorun_schedule = 3 * * 0
collection_retention = 30
password_check_interval = 12

ID: dba
------------------------------------------
notification_email = dba@example.com
autorun_schedule = 4,8,12,16,20 * * *
autorun_flags = -profile dba – tag dba
collection_retention = 30
password_check_interval = 1

ID: sysadmin
------------------------------------------
notification_email = sysadmin@example.com
autorun_schedule = 3 * * 1,3,5
autorun_flags = -profile sysadmin –tag sysadmin
collection_retension = 60
password_check_interval = 1


$ ./exachk –get all

ID: exachk.default
------------------------------------------
notification_email = some.body@example.com
autorun_schedule = 3 * * 0
collection_retention = 30
password_check_interval = 1

ID: dba
------------------------------------------
notification_email = dba@example.com
autorun_schedule = 4,8,12,16,20 * * *
autorun_flags = -profile dba – tag dba
collection_retention = 30
password_check_interval = 1

ID: sysadmin
------------------------------------------
notification_email = sysadmin@example.com
autorun_schedule = 3 * * 1,3,5
autorun_flags = -profile sysadmin –tag sysadmin
collection_retension = 60
password_check_interval = 1

6. To get all the options set for a daemon profile, for example, a daemon profile called dba:

$ ./orachk –id dba –get all

ID: dba
------------------------------------------
notification_email = dba@example.com
autorun_schedule = 4,8,12,16,20 * * *
autorun_flags = -profile dba – tag dba
collection_retention = 30
password_check_interval = 1


$ ./exachk –id dba –get all

ID: dba
------------------------------------------
notification_email = dba@example.com
autorun_schedule = 4,8,12,16,20 * * *
autorun_flags = -profile dba – tag dba
collection_retention = 30
password_check_interval = 1

2.4.4 Querying the Status and Next Planned Daemon Run

Query the status and next automatic run schedule of the running daemon.


-d status|info|nextautorun

  • -d status: Checks if the daemon is running.

  • -d info: Displays information about the running daemon.

  • -d nextautorun [-id ID]: Displays the next automatic run time.

To query the status and next planned daemon run:

1. To check if the daemon is running, use –d status:


$ ./orachk –d status

$ ./exachk –d status


If the daemon is running, then the daemon confirms and displays the PID.

2. To query more detailed information about the daemon, use –d info:

$ ./orachk –d info

$ ./exachk –d info

The daemon responds with the following information:

    • Node on which the daemon is installed

    • Version

    • Install location

    • Time when the daemon was started

3. To query the next scheduled health check run, use –d nextautorun:

$ ./orachk –d nextautorun

$ ./exachk –d nextautorun

The daemon responds with details of schedule.

If you have configured multiple daemon option profiles, then the output shows whichever is scheduled to run next.

If you have configured multiple daemon option profiles, then query the next scheduled health check run of a specific profile using –id ID -d nextautorun:


$ ./orachk –d ID –d nextautorun

$ ./exachk –d ID –d nextautorun

The daemon responds with details of the schedule for the daemon options profile ID you have specified.

For Best Visual Video on this topic Click on this link https://www.youtube.com/watch?v=Hrggf1tZHws&t=90s


Thanks For Reading

Do Comments for next blog on hacking and cyber security

About me

I am Saoz,  B.Tech IT Specialist  ,  Member at Web Development 

    Comments

    Post a Comment

    Popular posts from this blog

    10 Lines of Code For Your Own AI Assistant ( Jarvis )

      program is a very basic implementation of a virtual assistant and can be expanded upon with more functions and features. pythonCopy code import speech_recognition as sr import pyttsx3 import webbrowser import datetime # Set up speech recognition r = sr.Recognizer() with sr.Microphone() as source: print("Listening...") r.pause_threshold = 1 audio = r.listen(source) # Initialize text-to-speech engine engine = pyttsx3.init() # Set up wake-up keyword wake_word = "Jarvis" # Define function to convert text to speech def speak(text): engine.say(text) engine.runAndWait() # Define function for opening a website def open_website(url): webbrowser.open(url) speak("Opening website.") # Define function for telling the time def tell_time(): time = datetime.datetime.now().strftime("%I:%M %p") speak(f"The time is {time}.") # Check if wake-up keyword is detected if wake_word in r.recognize_google(audio): speak(...
    Read more

    How to Scan ANY Website for Vulnerabilities Like a PRO

    Image
      Topics: Understanding Website Vulnerabilities 2024 What Are Website Vulnerabilities? Key Vulnerabilities in 2024 Essential Tools for Vulnerability Scanning How to scan your website for vulnerabilities Installation of Nikto 2024 How to Scan with Nikto Step bt Step Guide Understanding the Importance of Regular Scans Advanced Vulnerability Scanning Techniques Preparing for Nikto Installation Installation of Nikto Mastering Nikto for Comprehensive Website Scanning Choosing the Right Tool Understanding Website Vulnerabilities 2024 In the rapidly evolving digital landscape of 2024, website vulnerabilities continue to be a major concern for businesses, governments, and individuals alike. With increasing reliance on web applications, the consequences of a compromised website—whether through data breaches, financial loss, or reputational damage—are severe. As hackers deploy more sophisticated and diverse methods of attack, it is crucial for website owners, developers, and cybersecurity pr...
    Read more

    Top 10 Powerfull Hacking Tools in Kali Linux to Hack Anything

    Image
     Kali Linux is a Linux distribution based on Debian, managed by Offensive Security. It was created by Mati Aharoni and Devon Kearns. This operating system is specifically designed for network analysts, penetration testers, and those involved in cybersecurity and analysis.  You can visit its official website at Kali.org. The OS gained widespread recognition after being featured in the  Mr. Robot  series. It is not intended for general use; instead, it's meant for professionals or individuals familiar with Linux/Kali. For installation guidance, refer to the official documentation. Often, tasks during penetration testing or hacking need to be automated because there are countless conditions and payloads to test, making manual testing inefficient. To boost productivity, Kali Linux comes pre-loaded with tools that help capture accurate data and provide precise results. With over 350 included tools, Kali Linux offers a valuable toolkit for hacking and penetration testing, ...
    Read more