Unknown lvalue 'After network.target' in section 'Unit' Centos 7
Clash 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?
centos services
add a comment |Â
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?
centos services
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
add a comment |Â
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?
centos services
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?
centos services
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
add a comment |Â
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
add a comment |Â
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
ornewsyslog
in this century.. Frequently Given Answers.
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
add a comment |Â
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
add a comment |Â
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
ornewsyslog
in this century.. Frequently Given Answers.
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
add a comment |Â
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
ornewsyslog
in this century.. Frequently Given Answers.
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
add a comment |Â
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
ornewsyslog
in this century.. Frequently Given Answers.
.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
ornewsyslog
in this century.. Frequently Given Answers.
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
add a comment |Â
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
add a comment |Â
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
add a comment |Â
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
add a comment |Â
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
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
answered Mar 31 at 19:07
Matthew Smith
1111
1111
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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