How do I figure out why my systemctl service didn't start on CentOS 7?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite












I'm using CentOS 7. How do I figure out why a service is failing to start? I have created this service



[rails@server ~]$ sudo cat /usr/lib/systemd/system/nodejs.service
[Unit]
Description=nodejs server

[Service]
User=rails
Group=rails
ExecStart=/home/rails/NodeJSserver/start.sh
ExecStop=/home/rails/NodeJSserver/stop.sh

[Install]
WantedBy=multi-user.target


The file points to this



[rails@server ~]$ cat /home/rails/NodeJSserver/start.sh
#!/bin/bash

forever start /home/rails/NodeJSserver/server.js


I can run this file just fine by itself. But when I try and run it as part of the service, I notice my nodeJS server isn't started. Even when I check "sudo systemctl --state=failed," I don't see any errors ...



[rails@server ~]$ sudo systemctl enable NodeJSserver
[rails@server ~]$ sudo systemctl start NodeJSserver
[rails@server ~]$
[rails@server ~]$
[rails@server ~]$ forever list
info: No forever processes running
[rails@server ~]$
[rails@server ~]$
[rails@server ~]$ sudo systemctl --state=failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● nginx.service loaded failed failed The nginx HTTP and reverse proxy server
● systemd-sysctl.service loaded failed failed Apply Kernel Variables
● systemd-vconsole-setup.service loaded failed failed Setup Virtual Console

LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.

3 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.


How do I figure out why my service failed to start?







share|improve this question



















  • journalctl -u nodejs should give you a more meaningful error message.
    – Federico klez Culloca
    May 8 at 15:27











  • I get the message "No journal files were found."
    – Dave
    May 8 at 16:00














up vote
1
down vote

favorite












I'm using CentOS 7. How do I figure out why a service is failing to start? I have created this service



[rails@server ~]$ sudo cat /usr/lib/systemd/system/nodejs.service
[Unit]
Description=nodejs server

[Service]
User=rails
Group=rails
ExecStart=/home/rails/NodeJSserver/start.sh
ExecStop=/home/rails/NodeJSserver/stop.sh

[Install]
WantedBy=multi-user.target


The file points to this



[rails@server ~]$ cat /home/rails/NodeJSserver/start.sh
#!/bin/bash

forever start /home/rails/NodeJSserver/server.js


I can run this file just fine by itself. But when I try and run it as part of the service, I notice my nodeJS server isn't started. Even when I check "sudo systemctl --state=failed," I don't see any errors ...



[rails@server ~]$ sudo systemctl enable NodeJSserver
[rails@server ~]$ sudo systemctl start NodeJSserver
[rails@server ~]$
[rails@server ~]$
[rails@server ~]$ forever list
info: No forever processes running
[rails@server ~]$
[rails@server ~]$
[rails@server ~]$ sudo systemctl --state=failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● nginx.service loaded failed failed The nginx HTTP and reverse proxy server
● systemd-sysctl.service loaded failed failed Apply Kernel Variables
● systemd-vconsole-setup.service loaded failed failed Setup Virtual Console

LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.

3 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.


How do I figure out why my service failed to start?







share|improve this question



















  • journalctl -u nodejs should give you a more meaningful error message.
    – Federico klez Culloca
    May 8 at 15:27











  • I get the message "No journal files were found."
    – Dave
    May 8 at 16:00












up vote
1
down vote

favorite









up vote
1
down vote

favorite











I'm using CentOS 7. How do I figure out why a service is failing to start? I have created this service



[rails@server ~]$ sudo cat /usr/lib/systemd/system/nodejs.service
[Unit]
Description=nodejs server

[Service]
User=rails
Group=rails
ExecStart=/home/rails/NodeJSserver/start.sh
ExecStop=/home/rails/NodeJSserver/stop.sh

[Install]
WantedBy=multi-user.target


The file points to this



[rails@server ~]$ cat /home/rails/NodeJSserver/start.sh
#!/bin/bash

forever start /home/rails/NodeJSserver/server.js


I can run this file just fine by itself. But when I try and run it as part of the service, I notice my nodeJS server isn't started. Even when I check "sudo systemctl --state=failed," I don't see any errors ...



[rails@server ~]$ sudo systemctl enable NodeJSserver
[rails@server ~]$ sudo systemctl start NodeJSserver
[rails@server ~]$
[rails@server ~]$
[rails@server ~]$ forever list
info: No forever processes running
[rails@server ~]$
[rails@server ~]$
[rails@server ~]$ sudo systemctl --state=failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● nginx.service loaded failed failed The nginx HTTP and reverse proxy server
● systemd-sysctl.service loaded failed failed Apply Kernel Variables
● systemd-vconsole-setup.service loaded failed failed Setup Virtual Console

LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.

3 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.


How do I figure out why my service failed to start?







share|improve this question











I'm using CentOS 7. How do I figure out why a service is failing to start? I have created this service



[rails@server ~]$ sudo cat /usr/lib/systemd/system/nodejs.service
[Unit]
Description=nodejs server

[Service]
User=rails
Group=rails
ExecStart=/home/rails/NodeJSserver/start.sh
ExecStop=/home/rails/NodeJSserver/stop.sh

[Install]
WantedBy=multi-user.target


The file points to this



[rails@server ~]$ cat /home/rails/NodeJSserver/start.sh
#!/bin/bash

forever start /home/rails/NodeJSserver/server.js


I can run this file just fine by itself. But when I try and run it as part of the service, I notice my nodeJS server isn't started. Even when I check "sudo systemctl --state=failed," I don't see any errors ...



[rails@server ~]$ sudo systemctl enable NodeJSserver
[rails@server ~]$ sudo systemctl start NodeJSserver
[rails@server ~]$
[rails@server ~]$
[rails@server ~]$ forever list
info: No forever processes running
[rails@server ~]$
[rails@server ~]$
[rails@server ~]$ sudo systemctl --state=failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● nginx.service loaded failed failed The nginx HTTP and reverse proxy server
● systemd-sysctl.service loaded failed failed Apply Kernel Variables
● systemd-vconsole-setup.service loaded failed failed Setup Virtual Console

LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.

3 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.


How do I figure out why my service failed to start?









share|improve this question










share|improve this question




share|improve this question









asked May 8 at 15:24









Dave

363827




363827











  • journalctl -u nodejs should give you a more meaningful error message.
    – Federico klez Culloca
    May 8 at 15:27











  • I get the message "No journal files were found."
    – Dave
    May 8 at 16:00
















  • journalctl -u nodejs should give you a more meaningful error message.
    – Federico klez Culloca
    May 8 at 15:27











  • I get the message "No journal files were found."
    – Dave
    May 8 at 16:00















journalctl -u nodejs should give you a more meaningful error message.
– Federico klez Culloca
May 8 at 15:27





journalctl -u nodejs should give you a more meaningful error message.
– Federico klez Culloca
May 8 at 15:27













I get the message "No journal files were found."
– Dave
May 8 at 16:00




I get the message "No journal files were found."
– Dave
May 8 at 16:00










1 Answer
1






active

oldest

votes

















up vote
0
down vote



accepted










Your service has no Type= specified in the [Service] section, so systemd assumes you meant Type=simple.



That means systemd will expect the process that was started with ExecStart= to keep running as long as the service is running. But it looks like your start.sh only runs one command and then exits. That is the forever command: forever start starts the target command as a daemon, or in other words, in the background. As soon as the forever start command completes, the shell running start.sh will exit.



At that point, systemd considers this service as failed. But wait, the control group assigned for that service still has a running process in it. "So," thinks systemd, "not only did it fail, but it also left a mess after itself. Can't have that." Since there is no KillMode= nor KillSignal= specified, systemd goes on with its defaults and sends a SIGTERM for any remaining processes in that control group, and if they don't stop in a timely manner, follows up with a SIGKILL. After that, your actual NodeJS process will be dead, guaranteed.



How to fix it



Since the command you run with ExecStart= will exit as soon as the actual server is started, you cannot use the default Type=simple. You must specify another service type.



You could use the Type=forking. With this type, man systemd.service recommends using a PIDFile= option, so if your NodeJS server creates a PID file for itself (or you add options to the forever command to make it create one for it), you should let systemd know where it will be.



[Service]
Type=forking
PIDFile=/absolute/path/to/nodejs.pid
User=rails
... <the rest as before>



If Type=forking does not work for you, then you could specify Type=oneshot with RemainAfterExit=yes.



That makes systemd just run the ExecStart= command when starting your service and ExecStop= when stopping it, and not care about anything else.



systemd will still remember whether the service was last set in a stopped or started state, though. So if you set another service to depend on this service, and then stop your NodeJS service manually, the other service won't stop automatically and will no doubt return errors when it cannot use your NodeJS service.




The third option is to skip the forever command entirely and let systemd do the job of restarting the NodeJS process. In that case, your entire nodejs.service unit would be:



[Unit]
Description=nodejs server

[Service]
User=rails
Group=rails
ExecStart=/home/rails/NodeJSserver/server.js
Restart=always

[Install]
WantedBy=multi-user.target


You could add other options.



For example, you could specify RestartSec=5 to specify a 5-second sleep before attempting to restart the service if it unexpectedly dies, to avoid hogging system resources by frequent restart attempts if your service keeps dying immediately after being restarted for some reason. (The default RestartSec= value is 100 ms.)



Or if you want the service to be restarted if it returns some specific exit status values, but consider it failed on others, there are options for that too.






share|improve this answer





















    Your Answer







    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );








     

    draft saved


    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f442575%2fhow-do-i-figure-out-why-my-systemctl-service-didnt-start-on-centos-7%23new-answer', 'question_page');

    );

    Post as a guest






























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    0
    down vote



    accepted










    Your service has no Type= specified in the [Service] section, so systemd assumes you meant Type=simple.



    That means systemd will expect the process that was started with ExecStart= to keep running as long as the service is running. But it looks like your start.sh only runs one command and then exits. That is the forever command: forever start starts the target command as a daemon, or in other words, in the background. As soon as the forever start command completes, the shell running start.sh will exit.



    At that point, systemd considers this service as failed. But wait, the control group assigned for that service still has a running process in it. "So," thinks systemd, "not only did it fail, but it also left a mess after itself. Can't have that." Since there is no KillMode= nor KillSignal= specified, systemd goes on with its defaults and sends a SIGTERM for any remaining processes in that control group, and if they don't stop in a timely manner, follows up with a SIGKILL. After that, your actual NodeJS process will be dead, guaranteed.



    How to fix it



    Since the command you run with ExecStart= will exit as soon as the actual server is started, you cannot use the default Type=simple. You must specify another service type.



    You could use the Type=forking. With this type, man systemd.service recommends using a PIDFile= option, so if your NodeJS server creates a PID file for itself (or you add options to the forever command to make it create one for it), you should let systemd know where it will be.



    [Service]
    Type=forking
    PIDFile=/absolute/path/to/nodejs.pid
    User=rails
    ... <the rest as before>



    If Type=forking does not work for you, then you could specify Type=oneshot with RemainAfterExit=yes.



    That makes systemd just run the ExecStart= command when starting your service and ExecStop= when stopping it, and not care about anything else.



    systemd will still remember whether the service was last set in a stopped or started state, though. So if you set another service to depend on this service, and then stop your NodeJS service manually, the other service won't stop automatically and will no doubt return errors when it cannot use your NodeJS service.




    The third option is to skip the forever command entirely and let systemd do the job of restarting the NodeJS process. In that case, your entire nodejs.service unit would be:



    [Unit]
    Description=nodejs server

    [Service]
    User=rails
    Group=rails
    ExecStart=/home/rails/NodeJSserver/server.js
    Restart=always

    [Install]
    WantedBy=multi-user.target


    You could add other options.



    For example, you could specify RestartSec=5 to specify a 5-second sleep before attempting to restart the service if it unexpectedly dies, to avoid hogging system resources by frequent restart attempts if your service keeps dying immediately after being restarted for some reason. (The default RestartSec= value is 100 ms.)



    Or if you want the service to be restarted if it returns some specific exit status values, but consider it failed on others, there are options for that too.






    share|improve this answer

























      up vote
      0
      down vote



      accepted










      Your service has no Type= specified in the [Service] section, so systemd assumes you meant Type=simple.



      That means systemd will expect the process that was started with ExecStart= to keep running as long as the service is running. But it looks like your start.sh only runs one command and then exits. That is the forever command: forever start starts the target command as a daemon, or in other words, in the background. As soon as the forever start command completes, the shell running start.sh will exit.



      At that point, systemd considers this service as failed. But wait, the control group assigned for that service still has a running process in it. "So," thinks systemd, "not only did it fail, but it also left a mess after itself. Can't have that." Since there is no KillMode= nor KillSignal= specified, systemd goes on with its defaults and sends a SIGTERM for any remaining processes in that control group, and if they don't stop in a timely manner, follows up with a SIGKILL. After that, your actual NodeJS process will be dead, guaranteed.



      How to fix it



      Since the command you run with ExecStart= will exit as soon as the actual server is started, you cannot use the default Type=simple. You must specify another service type.



      You could use the Type=forking. With this type, man systemd.service recommends using a PIDFile= option, so if your NodeJS server creates a PID file for itself (or you add options to the forever command to make it create one for it), you should let systemd know where it will be.



      [Service]
      Type=forking
      PIDFile=/absolute/path/to/nodejs.pid
      User=rails
      ... <the rest as before>



      If Type=forking does not work for you, then you could specify Type=oneshot with RemainAfterExit=yes.



      That makes systemd just run the ExecStart= command when starting your service and ExecStop= when stopping it, and not care about anything else.



      systemd will still remember whether the service was last set in a stopped or started state, though. So if you set another service to depend on this service, and then stop your NodeJS service manually, the other service won't stop automatically and will no doubt return errors when it cannot use your NodeJS service.




      The third option is to skip the forever command entirely and let systemd do the job of restarting the NodeJS process. In that case, your entire nodejs.service unit would be:



      [Unit]
      Description=nodejs server

      [Service]
      User=rails
      Group=rails
      ExecStart=/home/rails/NodeJSserver/server.js
      Restart=always

      [Install]
      WantedBy=multi-user.target


      You could add other options.



      For example, you could specify RestartSec=5 to specify a 5-second sleep before attempting to restart the service if it unexpectedly dies, to avoid hogging system resources by frequent restart attempts if your service keeps dying immediately after being restarted for some reason. (The default RestartSec= value is 100 ms.)



      Or if you want the service to be restarted if it returns some specific exit status values, but consider it failed on others, there are options for that too.






      share|improve this answer























        up vote
        0
        down vote



        accepted







        up vote
        0
        down vote



        accepted






        Your service has no Type= specified in the [Service] section, so systemd assumes you meant Type=simple.



        That means systemd will expect the process that was started with ExecStart= to keep running as long as the service is running. But it looks like your start.sh only runs one command and then exits. That is the forever command: forever start starts the target command as a daemon, or in other words, in the background. As soon as the forever start command completes, the shell running start.sh will exit.



        At that point, systemd considers this service as failed. But wait, the control group assigned for that service still has a running process in it. "So," thinks systemd, "not only did it fail, but it also left a mess after itself. Can't have that." Since there is no KillMode= nor KillSignal= specified, systemd goes on with its defaults and sends a SIGTERM for any remaining processes in that control group, and if they don't stop in a timely manner, follows up with a SIGKILL. After that, your actual NodeJS process will be dead, guaranteed.



        How to fix it



        Since the command you run with ExecStart= will exit as soon as the actual server is started, you cannot use the default Type=simple. You must specify another service type.



        You could use the Type=forking. With this type, man systemd.service recommends using a PIDFile= option, so if your NodeJS server creates a PID file for itself (or you add options to the forever command to make it create one for it), you should let systemd know where it will be.



        [Service]
        Type=forking
        PIDFile=/absolute/path/to/nodejs.pid
        User=rails
        ... <the rest as before>



        If Type=forking does not work for you, then you could specify Type=oneshot with RemainAfterExit=yes.



        That makes systemd just run the ExecStart= command when starting your service and ExecStop= when stopping it, and not care about anything else.



        systemd will still remember whether the service was last set in a stopped or started state, though. So if you set another service to depend on this service, and then stop your NodeJS service manually, the other service won't stop automatically and will no doubt return errors when it cannot use your NodeJS service.




        The third option is to skip the forever command entirely and let systemd do the job of restarting the NodeJS process. In that case, your entire nodejs.service unit would be:



        [Unit]
        Description=nodejs server

        [Service]
        User=rails
        Group=rails
        ExecStart=/home/rails/NodeJSserver/server.js
        Restart=always

        [Install]
        WantedBy=multi-user.target


        You could add other options.



        For example, you could specify RestartSec=5 to specify a 5-second sleep before attempting to restart the service if it unexpectedly dies, to avoid hogging system resources by frequent restart attempts if your service keeps dying immediately after being restarted for some reason. (The default RestartSec= value is 100 ms.)



        Or if you want the service to be restarted if it returns some specific exit status values, but consider it failed on others, there are options for that too.






        share|improve this answer













        Your service has no Type= specified in the [Service] section, so systemd assumes you meant Type=simple.



        That means systemd will expect the process that was started with ExecStart= to keep running as long as the service is running. But it looks like your start.sh only runs one command and then exits. That is the forever command: forever start starts the target command as a daemon, or in other words, in the background. As soon as the forever start command completes, the shell running start.sh will exit.



        At that point, systemd considers this service as failed. But wait, the control group assigned for that service still has a running process in it. "So," thinks systemd, "not only did it fail, but it also left a mess after itself. Can't have that." Since there is no KillMode= nor KillSignal= specified, systemd goes on with its defaults and sends a SIGTERM for any remaining processes in that control group, and if they don't stop in a timely manner, follows up with a SIGKILL. After that, your actual NodeJS process will be dead, guaranteed.



        How to fix it



        Since the command you run with ExecStart= will exit as soon as the actual server is started, you cannot use the default Type=simple. You must specify another service type.



        You could use the Type=forking. With this type, man systemd.service recommends using a PIDFile= option, so if your NodeJS server creates a PID file for itself (or you add options to the forever command to make it create one for it), you should let systemd know where it will be.



        [Service]
        Type=forking
        PIDFile=/absolute/path/to/nodejs.pid
        User=rails
        ... <the rest as before>



        If Type=forking does not work for you, then you could specify Type=oneshot with RemainAfterExit=yes.



        That makes systemd just run the ExecStart= command when starting your service and ExecStop= when stopping it, and not care about anything else.



        systemd will still remember whether the service was last set in a stopped or started state, though. So if you set another service to depend on this service, and then stop your NodeJS service manually, the other service won't stop automatically and will no doubt return errors when it cannot use your NodeJS service.




        The third option is to skip the forever command entirely and let systemd do the job of restarting the NodeJS process. In that case, your entire nodejs.service unit would be:



        [Unit]
        Description=nodejs server

        [Service]
        User=rails
        Group=rails
        ExecStart=/home/rails/NodeJSserver/server.js
        Restart=always

        [Install]
        WantedBy=multi-user.target


        You could add other options.



        For example, you could specify RestartSec=5 to specify a 5-second sleep before attempting to restart the service if it unexpectedly dies, to avoid hogging system resources by frequent restart attempts if your service keeps dying immediately after being restarted for some reason. (The default RestartSec= value is 100 ms.)



        Or if you want the service to be restarted if it returns some specific exit status values, but consider it failed on others, there are options for that too.







        share|improve this answer













        share|improve this answer



        share|improve this answer











        answered May 8 at 19:19









        telcoM

        10.2k11032




        10.2k11032






















             

            draft saved


            draft discarded


























             


            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f442575%2fhow-do-i-figure-out-why-my-systemctl-service-didnt-start-on-centos-7%23new-answer', 'question_page');

            );

            Post as a guest













































































            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Displaying single band from multi-band raster using QGIS

            How many registers does an x86_64 CPU actually have?