Unknown lvalue 'After network.target' in section 'Unit' Centos 7

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











up vote
0
down vote

favorite












I modified unit files according to your post:



[Unit]
Description=My Portal Service
After=network.target

[Service]
SyslogIdentifier=my-portal
Environment=SERVICE_NAME=my-portal
Environment=PATH_TO_TARGET=/opt/apps/egp/stage/my-portal/target
ExecStart=/usr/bin/env java -jar $PATH_TO_TARGET/$SERVICE_NAME.jar server $PATH_TO_TARGET/$SERVICE_NAME.yml

[Install]
WantedBy=multi-user.target


I also run command:



systemctl daemon-reload


to reload systemd manager configuration.



All is working fine - I can successfully start, stop and see the status of the service using:



 systemctl start my-portal
systemctl status my-portal -l
systemctl stop my-portal


And after I fix the problem with Java env variables - I will run this command:



systemctl enable service-name


to start service (services- 5 in total) on boot.



The problem I have is setting Java env variables. I tried various versions: adding them in .bash_profile and using source command,then writing Java env in separate javaenv.sh file in /etc/profile.d folder:



export JAVA_HOME=/opt/jdk1.7.0_80
export PATH=/opt/jdk1.7.0_80/bin:$PATH


Gave permission:



chmod +x /etc/profile.d/javaenv.sh


and modified unit file adding $JAVA_HOME/bin in ExecStart line...
It does not finding Java. I had the same problem before, when I was using sh scripts getting the error:



nohup: failed to run command ‘java’: No such file or directory 


I read many posts on that issue - but cannot find the solution to set Java variables in one place and use them in other units or script files as $JAVA_HOME variables.



Where to set Java env variables to be used in various places permanently without logging?







share|improve this question






















  • Solved. I added Java env (JAVA_HOME and $JAVA_HOME/bin) to to /etc/environment file and added sym link to my java in usr/bin: ln -s /opt/jdk1.7.0_80/bin/java /usr/bin/java
    – ganna07
    May 26 at 15:21















up vote
0
down vote

favorite












I modified unit files according to your post:



[Unit]
Description=My Portal Service
After=network.target

[Service]
SyslogIdentifier=my-portal
Environment=SERVICE_NAME=my-portal
Environment=PATH_TO_TARGET=/opt/apps/egp/stage/my-portal/target
ExecStart=/usr/bin/env java -jar $PATH_TO_TARGET/$SERVICE_NAME.jar server $PATH_TO_TARGET/$SERVICE_NAME.yml

[Install]
WantedBy=multi-user.target


I also run command:



systemctl daemon-reload


to reload systemd manager configuration.



All is working fine - I can successfully start, stop and see the status of the service using:



 systemctl start my-portal
systemctl status my-portal -l
systemctl stop my-portal


And after I fix the problem with Java env variables - I will run this command:



systemctl enable service-name


to start service (services- 5 in total) on boot.



The problem I have is setting Java env variables. I tried various versions: adding them in .bash_profile and using source command,then writing Java env in separate javaenv.sh file in /etc/profile.d folder:



export JAVA_HOME=/opt/jdk1.7.0_80
export PATH=/opt/jdk1.7.0_80/bin:$PATH


Gave permission:



chmod +x /etc/profile.d/javaenv.sh


and modified unit file adding $JAVA_HOME/bin in ExecStart line...
It does not finding Java. I had the same problem before, when I was using sh scripts getting the error:



nohup: failed to run command ‘java’: No such file or directory 


I read many posts on that issue - but cannot find the solution to set Java variables in one place and use them in other units or script files as $JAVA_HOME variables.



Where to set Java env variables to be used in various places permanently without logging?







share|improve this question






















  • Solved. I added Java env (JAVA_HOME and $JAVA_HOME/bin) to to /etc/environment file and added sym link to my java in usr/bin: ln -s /opt/jdk1.7.0_80/bin/java /usr/bin/java
    – ganna07
    May 26 at 15:21













up vote
0
down vote

favorite









up vote
0
down vote

favorite











I modified unit files according to your post:



[Unit]
Description=My Portal Service
After=network.target

[Service]
SyslogIdentifier=my-portal
Environment=SERVICE_NAME=my-portal
Environment=PATH_TO_TARGET=/opt/apps/egp/stage/my-portal/target
ExecStart=/usr/bin/env java -jar $PATH_TO_TARGET/$SERVICE_NAME.jar server $PATH_TO_TARGET/$SERVICE_NAME.yml

[Install]
WantedBy=multi-user.target


I also run command:



systemctl daemon-reload


to reload systemd manager configuration.



All is working fine - I can successfully start, stop and see the status of the service using:



 systemctl start my-portal
systemctl status my-portal -l
systemctl stop my-portal


And after I fix the problem with Java env variables - I will run this command:



systemctl enable service-name


to start service (services- 5 in total) on boot.



The problem I have is setting Java env variables. I tried various versions: adding them in .bash_profile and using source command,then writing Java env in separate javaenv.sh file in /etc/profile.d folder:



export JAVA_HOME=/opt/jdk1.7.0_80
export PATH=/opt/jdk1.7.0_80/bin:$PATH


Gave permission:



chmod +x /etc/profile.d/javaenv.sh


and modified unit file adding $JAVA_HOME/bin in ExecStart line...
It does not finding Java. I had the same problem before, when I was using sh scripts getting the error:



nohup: failed to run command ‘java’: No such file or directory 


I read many posts on that issue - but cannot find the solution to set Java variables in one place and use them in other units or script files as $JAVA_HOME variables.



Where to set Java env variables to be used in various places permanently without logging?







share|improve this question














I modified unit files according to your post:



[Unit]
Description=My Portal Service
After=network.target

[Service]
SyslogIdentifier=my-portal
Environment=SERVICE_NAME=my-portal
Environment=PATH_TO_TARGET=/opt/apps/egp/stage/my-portal/target
ExecStart=/usr/bin/env java -jar $PATH_TO_TARGET/$SERVICE_NAME.jar server $PATH_TO_TARGET/$SERVICE_NAME.yml

[Install]
WantedBy=multi-user.target


I also run command:



systemctl daemon-reload


to reload systemd manager configuration.



All is working fine - I can successfully start, stop and see the status of the service using:



 systemctl start my-portal
systemctl status my-portal -l
systemctl stop my-portal


And after I fix the problem with Java env variables - I will run this command:



systemctl enable service-name


to start service (services- 5 in total) on boot.



The problem I have is setting Java env variables. I tried various versions: adding them in .bash_profile and using source command,then writing Java env in separate javaenv.sh file in /etc/profile.d folder:



export JAVA_HOME=/opt/jdk1.7.0_80
export PATH=/opt/jdk1.7.0_80/bin:$PATH


Gave permission:



chmod +x /etc/profile.d/javaenv.sh


and modified unit file adding $JAVA_HOME/bin in ExecStart line...
It does not finding Java. I had the same problem before, when I was using sh scripts getting the error:



nohup: failed to run command ‘java’: No such file or directory 


I read many posts on that issue - but cannot find the solution to set Java variables in one place and use them in other units or script files as $JAVA_HOME variables.



Where to set Java env variables to be used in various places permanently without logging?









share|improve this question













share|improve this question




share|improve this question








edited May 25 at 9:38

























asked Mar 31 at 17:42









ganna07

142




142











  • Solved. I added Java env (JAVA_HOME and $JAVA_HOME/bin) to to /etc/environment file and added sym link to my java in usr/bin: ln -s /opt/jdk1.7.0_80/bin/java /usr/bin/java
    – ganna07
    May 26 at 15:21

















  • Solved. I added Java env (JAVA_HOME and $JAVA_HOME/bin) to to /etc/environment file and added sym link to my java in usr/bin: ln -s /opt/jdk1.7.0_80/bin/java /usr/bin/java
    – ganna07
    May 26 at 15:21
















Solved. I added Java env (JAVA_HOME and $JAVA_HOME/bin) to to /etc/environment file and added sym link to my java in usr/bin: ln -s /opt/jdk1.7.0_80/bin/java /usr/bin/java
– ganna07
May 26 at 15:21





Solved. I added Java env (JAVA_HOME and $JAVA_HOME/bin) to to /etc/environment file and added sym link to my java in usr/bin: ln -s /opt/jdk1.7.0_80/bin/java /usr/bin/java
– ganna07
May 26 at 15:21











2 Answers
2






active

oldest

votes

















up vote
3
down vote














.INI file syntax basics



[Unit]
Description = My Portal Service
After network.target = my-portal.service


In the section Unit the key is supposed to be After and the value is (for example) network.target my-portal.service. You have a key of After network.target and a value my-portal.service. That key means nothing to systemd, as the message told you.



Outright systemd House of Horror stuff



Making a service ordered to start after itself is ludicrous. But that's just the tip of the iceberg here.



Type = forking
ExecStart = /usr/local/bin/my-portal.sh start
ExecStop = /usr/local/bin/my-portal.sh stop
ExecReload = /usr/local/bin/my-portal.sh reload
…
PATH_TO_LOG="/var/log/egp"
…
PID_PATH_NAME=/var/run/$SERVICE_NAME-pid
nohup … >> $PATH_TO_LOG/$SERVICE_NAME.out 2>&1&


All of this is just the classic pattern, strangely predominant with Java, of erecting a foolish mess of wholly unnecessary and erroneous scaffolding.



You don't need the shell script at all. You certainly don't need the rickety and dangerous PID file mechanism that it tries to employ. Nor do you need a hand-rolled logging mechanism that relies upon a rickety logrotate/newsyslog mechanism, and cannot prevent your disc volume from filling up with log output (written by a process with superuser privileges, so it will even eat into the superuser-reserved emergency disc space) in many cases.



Use the service manager features that exist:



#/etc/systemd/system/my-portal.service
[Unit]
Description=My Portal Service
Documentation=https://unix.stackexchange.com/a/434726/5132
After=network.target

[Service]
SyslogIdentifier=my-service
Environment=SERVICE_NAME=my-service
Environment=PATH_TO_TARGET="/opt/apps/egp/stage/my-service/target"
ExecStart=/usr/bin/env java -jar $PATH_TO_TARGET/$SERVICE_NAME.jar server $PATH_TO_TARGET/$SERVICE_NAME.yml

[Install]
WantedBy=multi-user.target


To read the service's log, just use journalctl in the usual way. A service manager tracks processes by remembering their process IDs from when it spawned them, and has no need of the rickety and dangerous PID file mechanism.



Further reading



  • Jonathan de Boyne Pollard (2015). Wrapping Apache Tomcat in many pointless extra layers The systemd House of Horror.

  • Jonathan de Boyne Pollard (2015). The systemd House of Horror. Frequently Given Answers.

  • How to avoid /usr/bin/env being marked in systemd logs as the executable

  • configure java daemon with systemd

  • Jonathan de Boyne Pollard (2016). Don't use logrotate or newsyslog in this century.. Frequently Given Answers.





share|improve this answer




















  • Thank you very much for your answer. I inherited the scripts and SW service. I follow the instructions and could start the services (5 in total) in VBox (Centos 7 min) and they were working fine. - that is strange. On another cloud instance it gives this error. I am new to services, but started reading systemd docs. My apology for not answering before, I am literary forced to do some other tasks and soon I will be back - and write the feedback. Thanks again.
    – ganna07
    Apr 4 at 21:51

















up vote
1
down vote













You misplaced an equals character in my-portal.service. Also, you should get rid of the shell script and get SystemD to manage the process directly.



Try this:



[Unit]
Description=My Portal Service
After=network.target

[Service]
Type=Simple
ExecStart=/usr/bin/java -jar /opt/apps/egp/stage/my-portal/target/my-portal.jar server /opt/apps/egp/stage/my-portal/target/my-portal.yml

[Install]
WantedBy=multi-user.target





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%2f434709%2funknown-lvalue-after-network-target-in-section-unit-centos-7%23new-answer', 'question_page');

    );

    Post as a guest






























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    3
    down vote














    .INI file syntax basics



    [Unit]
    Description = My Portal Service
    After network.target = my-portal.service


    In the section Unit the key is supposed to be After and the value is (for example) network.target my-portal.service. You have a key of After network.target and a value my-portal.service. That key means nothing to systemd, as the message told you.



    Outright systemd House of Horror stuff



    Making a service ordered to start after itself is ludicrous. But that's just the tip of the iceberg here.



    Type = forking
    ExecStart = /usr/local/bin/my-portal.sh start
    ExecStop = /usr/local/bin/my-portal.sh stop
    ExecReload = /usr/local/bin/my-portal.sh reload
    …
    PATH_TO_LOG="/var/log/egp"
    …
    PID_PATH_NAME=/var/run/$SERVICE_NAME-pid
    nohup … >> $PATH_TO_LOG/$SERVICE_NAME.out 2>&1&


    All of this is just the classic pattern, strangely predominant with Java, of erecting a foolish mess of wholly unnecessary and erroneous scaffolding.



    You don't need the shell script at all. You certainly don't need the rickety and dangerous PID file mechanism that it tries to employ. Nor do you need a hand-rolled logging mechanism that relies upon a rickety logrotate/newsyslog mechanism, and cannot prevent your disc volume from filling up with log output (written by a process with superuser privileges, so it will even eat into the superuser-reserved emergency disc space) in many cases.



    Use the service manager features that exist:



    #/etc/systemd/system/my-portal.service
    [Unit]
    Description=My Portal Service
    Documentation=https://unix.stackexchange.com/a/434726/5132
    After=network.target

    [Service]
    SyslogIdentifier=my-service
    Environment=SERVICE_NAME=my-service
    Environment=PATH_TO_TARGET="/opt/apps/egp/stage/my-service/target"
    ExecStart=/usr/bin/env java -jar $PATH_TO_TARGET/$SERVICE_NAME.jar server $PATH_TO_TARGET/$SERVICE_NAME.yml

    [Install]
    WantedBy=multi-user.target


    To read the service's log, just use journalctl in the usual way. A service manager tracks processes by remembering their process IDs from when it spawned them, and has no need of the rickety and dangerous PID file mechanism.



    Further reading



    • Jonathan de Boyne Pollard (2015). Wrapping Apache Tomcat in many pointless extra layers The systemd House of Horror.

    • Jonathan de Boyne Pollard (2015). The systemd House of Horror. Frequently Given Answers.

    • How to avoid /usr/bin/env being marked in systemd logs as the executable

    • configure java daemon with systemd

    • Jonathan de Boyne Pollard (2016). Don't use logrotate or newsyslog in this century.. Frequently Given Answers.





    share|improve this answer




















    • Thank you very much for your answer. I inherited the scripts and SW service. I follow the instructions and could start the services (5 in total) in VBox (Centos 7 min) and they were working fine. - that is strange. On another cloud instance it gives this error. I am new to services, but started reading systemd docs. My apology for not answering before, I am literary forced to do some other tasks and soon I will be back - and write the feedback. Thanks again.
      – ganna07
      Apr 4 at 21:51














    up vote
    3
    down vote














    .INI file syntax basics



    [Unit]
    Description = My Portal Service
    After network.target = my-portal.service


    In the section Unit the key is supposed to be After and the value is (for example) network.target my-portal.service. You have a key of After network.target and a value my-portal.service. That key means nothing to systemd, as the message told you.



    Outright systemd House of Horror stuff



    Making a service ordered to start after itself is ludicrous. But that's just the tip of the iceberg here.



    Type = forking
    ExecStart = /usr/local/bin/my-portal.sh start
    ExecStop = /usr/local/bin/my-portal.sh stop
    ExecReload = /usr/local/bin/my-portal.sh reload
    …
    PATH_TO_LOG="/var/log/egp"
    …
    PID_PATH_NAME=/var/run/$SERVICE_NAME-pid
    nohup … >> $PATH_TO_LOG/$SERVICE_NAME.out 2>&1&


    All of this is just the classic pattern, strangely predominant with Java, of erecting a foolish mess of wholly unnecessary and erroneous scaffolding.



    You don't need the shell script at all. You certainly don't need the rickety and dangerous PID file mechanism that it tries to employ. Nor do you need a hand-rolled logging mechanism that relies upon a rickety logrotate/newsyslog mechanism, and cannot prevent your disc volume from filling up with log output (written by a process with superuser privileges, so it will even eat into the superuser-reserved emergency disc space) in many cases.



    Use the service manager features that exist:



    #/etc/systemd/system/my-portal.service
    [Unit]
    Description=My Portal Service
    Documentation=https://unix.stackexchange.com/a/434726/5132
    After=network.target

    [Service]
    SyslogIdentifier=my-service
    Environment=SERVICE_NAME=my-service
    Environment=PATH_TO_TARGET="/opt/apps/egp/stage/my-service/target"
    ExecStart=/usr/bin/env java -jar $PATH_TO_TARGET/$SERVICE_NAME.jar server $PATH_TO_TARGET/$SERVICE_NAME.yml

    [Install]
    WantedBy=multi-user.target


    To read the service's log, just use journalctl in the usual way. A service manager tracks processes by remembering their process IDs from when it spawned them, and has no need of the rickety and dangerous PID file mechanism.



    Further reading



    • Jonathan de Boyne Pollard (2015). Wrapping Apache Tomcat in many pointless extra layers The systemd House of Horror.

    • Jonathan de Boyne Pollard (2015). The systemd House of Horror. Frequently Given Answers.

    • How to avoid /usr/bin/env being marked in systemd logs as the executable

    • configure java daemon with systemd

    • Jonathan de Boyne Pollard (2016). Don't use logrotate or newsyslog in this century.. Frequently Given Answers.





    share|improve this answer




















    • Thank you very much for your answer. I inherited the scripts and SW service. I follow the instructions and could start the services (5 in total) in VBox (Centos 7 min) and they were working fine. - that is strange. On another cloud instance it gives this error. I am new to services, but started reading systemd docs. My apology for not answering before, I am literary forced to do some other tasks and soon I will be back - and write the feedback. Thanks again.
      – ganna07
      Apr 4 at 21:51












    up vote
    3
    down vote










    up vote
    3
    down vote










    .INI file syntax basics



    [Unit]
    Description = My Portal Service
    After network.target = my-portal.service


    In the section Unit the key is supposed to be After and the value is (for example) network.target my-portal.service. You have a key of After network.target and a value my-portal.service. That key means nothing to systemd, as the message told you.



    Outright systemd House of Horror stuff



    Making a service ordered to start after itself is ludicrous. But that's just the tip of the iceberg here.



    Type = forking
    ExecStart = /usr/local/bin/my-portal.sh start
    ExecStop = /usr/local/bin/my-portal.sh stop
    ExecReload = /usr/local/bin/my-portal.sh reload
    …
    PATH_TO_LOG="/var/log/egp"
    …
    PID_PATH_NAME=/var/run/$SERVICE_NAME-pid
    nohup … >> $PATH_TO_LOG/$SERVICE_NAME.out 2>&1&


    All of this is just the classic pattern, strangely predominant with Java, of erecting a foolish mess of wholly unnecessary and erroneous scaffolding.



    You don't need the shell script at all. You certainly don't need the rickety and dangerous PID file mechanism that it tries to employ. Nor do you need a hand-rolled logging mechanism that relies upon a rickety logrotate/newsyslog mechanism, and cannot prevent your disc volume from filling up with log output (written by a process with superuser privileges, so it will even eat into the superuser-reserved emergency disc space) in many cases.



    Use the service manager features that exist:



    #/etc/systemd/system/my-portal.service
    [Unit]
    Description=My Portal Service
    Documentation=https://unix.stackexchange.com/a/434726/5132
    After=network.target

    [Service]
    SyslogIdentifier=my-service
    Environment=SERVICE_NAME=my-service
    Environment=PATH_TO_TARGET="/opt/apps/egp/stage/my-service/target"
    ExecStart=/usr/bin/env java -jar $PATH_TO_TARGET/$SERVICE_NAME.jar server $PATH_TO_TARGET/$SERVICE_NAME.yml

    [Install]
    WantedBy=multi-user.target


    To read the service's log, just use journalctl in the usual way. A service manager tracks processes by remembering their process IDs from when it spawned them, and has no need of the rickety and dangerous PID file mechanism.



    Further reading



    • Jonathan de Boyne Pollard (2015). Wrapping Apache Tomcat in many pointless extra layers The systemd House of Horror.

    • Jonathan de Boyne Pollard (2015). The systemd House of Horror. Frequently Given Answers.

    • How to avoid /usr/bin/env being marked in systemd logs as the executable

    • configure java daemon with systemd

    • Jonathan de Boyne Pollard (2016). Don't use logrotate or newsyslog in this century.. Frequently Given Answers.





    share|improve this answer













    .INI file syntax basics



    [Unit]
    Description = My Portal Service
    After network.target = my-portal.service


    In the section Unit the key is supposed to be After and the value is (for example) network.target my-portal.service. You have a key of After network.target and a value my-portal.service. That key means nothing to systemd, as the message told you.



    Outright systemd House of Horror stuff



    Making a service ordered to start after itself is ludicrous. But that's just the tip of the iceberg here.



    Type = forking
    ExecStart = /usr/local/bin/my-portal.sh start
    ExecStop = /usr/local/bin/my-portal.sh stop
    ExecReload = /usr/local/bin/my-portal.sh reload
    …
    PATH_TO_LOG="/var/log/egp"
    …
    PID_PATH_NAME=/var/run/$SERVICE_NAME-pid
    nohup … >> $PATH_TO_LOG/$SERVICE_NAME.out 2>&1&


    All of this is just the classic pattern, strangely predominant with Java, of erecting a foolish mess of wholly unnecessary and erroneous scaffolding.



    You don't need the shell script at all. You certainly don't need the rickety and dangerous PID file mechanism that it tries to employ. Nor do you need a hand-rolled logging mechanism that relies upon a rickety logrotate/newsyslog mechanism, and cannot prevent your disc volume from filling up with log output (written by a process with superuser privileges, so it will even eat into the superuser-reserved emergency disc space) in many cases.



    Use the service manager features that exist:



    #/etc/systemd/system/my-portal.service
    [Unit]
    Description=My Portal Service
    Documentation=https://unix.stackexchange.com/a/434726/5132
    After=network.target

    [Service]
    SyslogIdentifier=my-service
    Environment=SERVICE_NAME=my-service
    Environment=PATH_TO_TARGET="/opt/apps/egp/stage/my-service/target"
    ExecStart=/usr/bin/env java -jar $PATH_TO_TARGET/$SERVICE_NAME.jar server $PATH_TO_TARGET/$SERVICE_NAME.yml

    [Install]
    WantedBy=multi-user.target


    To read the service's log, just use journalctl in the usual way. A service manager tracks processes by remembering their process IDs from when it spawned them, and has no need of the rickety and dangerous PID file mechanism.



    Further reading



    • Jonathan de Boyne Pollard (2015). Wrapping Apache Tomcat in many pointless extra layers The systemd House of Horror.

    • Jonathan de Boyne Pollard (2015). The systemd House of Horror. Frequently Given Answers.

    • How to avoid /usr/bin/env being marked in systemd logs as the executable

    • configure java daemon with systemd

    • Jonathan de Boyne Pollard (2016). Don't use logrotate or newsyslog in this century.. Frequently Given Answers.






    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Mar 31 at 19:03









    JdeBP

    28.2k459133




    28.2k459133











    • Thank you very much for your answer. I inherited the scripts and SW service. I follow the instructions and could start the services (5 in total) in VBox (Centos 7 min) and they were working fine. - that is strange. On another cloud instance it gives this error. I am new to services, but started reading systemd docs. My apology for not answering before, I am literary forced to do some other tasks and soon I will be back - and write the feedback. Thanks again.
      – ganna07
      Apr 4 at 21:51
















    • Thank you very much for your answer. I inherited the scripts and SW service. I follow the instructions and could start the services (5 in total) in VBox (Centos 7 min) and they were working fine. - that is strange. On another cloud instance it gives this error. I am new to services, but started reading systemd docs. My apology for not answering before, I am literary forced to do some other tasks and soon I will be back - and write the feedback. Thanks again.
      – ganna07
      Apr 4 at 21:51















    Thank you very much for your answer. I inherited the scripts and SW service. I follow the instructions and could start the services (5 in total) in VBox (Centos 7 min) and they were working fine. - that is strange. On another cloud instance it gives this error. I am new to services, but started reading systemd docs. My apology for not answering before, I am literary forced to do some other tasks and soon I will be back - and write the feedback. Thanks again.
    – ganna07
    Apr 4 at 21:51




    Thank you very much for your answer. I inherited the scripts and SW service. I follow the instructions and could start the services (5 in total) in VBox (Centos 7 min) and they were working fine. - that is strange. On another cloud instance it gives this error. I am new to services, but started reading systemd docs. My apology for not answering before, I am literary forced to do some other tasks and soon I will be back - and write the feedback. Thanks again.
    – ganna07
    Apr 4 at 21:51












    up vote
    1
    down vote













    You misplaced an equals character in my-portal.service. Also, you should get rid of the shell script and get SystemD to manage the process directly.



    Try this:



    [Unit]
    Description=My Portal Service
    After=network.target

    [Service]
    Type=Simple
    ExecStart=/usr/bin/java -jar /opt/apps/egp/stage/my-portal/target/my-portal.jar server /opt/apps/egp/stage/my-portal/target/my-portal.yml

    [Install]
    WantedBy=multi-user.target





    share|improve this answer
























      up vote
      1
      down vote













      You misplaced an equals character in my-portal.service. Also, you should get rid of the shell script and get SystemD to manage the process directly.



      Try this:



      [Unit]
      Description=My Portal Service
      After=network.target

      [Service]
      Type=Simple
      ExecStart=/usr/bin/java -jar /opt/apps/egp/stage/my-portal/target/my-portal.jar server /opt/apps/egp/stage/my-portal/target/my-portal.yml

      [Install]
      WantedBy=multi-user.target





      share|improve this answer






















        up vote
        1
        down vote










        up vote
        1
        down vote









        You misplaced an equals character in my-portal.service. Also, you should get rid of the shell script and get SystemD to manage the process directly.



        Try this:



        [Unit]
        Description=My Portal Service
        After=network.target

        [Service]
        Type=Simple
        ExecStart=/usr/bin/java -jar /opt/apps/egp/stage/my-portal/target/my-portal.jar server /opt/apps/egp/stage/my-portal/target/my-portal.yml

        [Install]
        WantedBy=multi-user.target





        share|improve this answer












        You misplaced an equals character in my-portal.service. Also, you should get rid of the shell script and get SystemD to manage the process directly.



        Try this:



        [Unit]
        Description=My Portal Service
        After=network.target

        [Service]
        Type=Simple
        ExecStart=/usr/bin/java -jar /opt/apps/egp/stage/my-portal/target/my-portal.jar server /opt/apps/egp/stage/my-portal/target/my-portal.yml

        [Install]
        WantedBy=multi-user.target






        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Mar 31 at 19:07









        Matthew Smith

        1111




        1111






















             

            draft saved


            draft discarded


























             


            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f434709%2funknown-lvalue-after-network-target-in-section-unit-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?

            Bahrain

            Postfix configuration issue with fips on centos 7; mailgun relay