Bonsoir,
I try to enable rc-local service:
1- I created /etc/rc.d/rc.local file:
#!/bin/bash
iptables -I INPUT -p udp --sport 1900 -j ACCEPT
2- I chmoded /etc/rc.d/rc.local
chmod u+x /etc/rc.d/rc.local
But the service won't start:
# systemctl status rc-local.service ● rc-local.service - /etc/rc.d/rc.local Compatibility Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static; vendor preset: disabled) Active: failed (Result: exit-code) since sam. 2016-09-03 22:49:00 CEST; 25s ago Process: 8189 ExecStart=/etc/rc.d/rc.local start (code=exited, status=203/EXEC)
sept. 03 22:49:00 berrichon systemd[1]: Starting /etc/rc.d/rc.local Compatibility... sept. 03 22:49:00 berrichon systemd[1]: rc-local.service: Control process exited, code=exited ...203 sept. 03 22:49:00 berrichon systemd[1]: Failed to start /etc/rc.d/rc.local Compatibility. sept. 03 22:49:00 berrichon systemd[1]: rc-local.service: Unit entered failed state. sept. 03 22:49:00 berrichon systemd[1]: rc-local.service: Failed with result 'exit-code'. Hint: Some lines were ellipsized, use -l to show in full.
On other nstall of fedora 23 this works.... Why not on this computer?
Thank you.
On 09/03/2016 01:59 PM, François Patte wrote:
On other nstall of fedora 23 this works.... Why not on this computer?
Have you compared that command line with the one used on the other computer to make sure there are no typos? I know it sounds obvious, but it's better to check now, than after days of ineffective troubleshooting.
On 09/03/2016 01:59 PM, François Patte wrote:
Bonsoir,
I try to enable rc-local service:
1- I created /etc/rc.d/rc.local file:
#!/bin/bash
iptables -I INPUT -p udp --sport 1900 -j ACCEPT
2- I chmoded /etc/rc.d/rc.local
chmod u+x /etc/rc.d/rc.local
But the service won't start:
# systemctl status rc-local.service ● rc-local.service - /etc/rc.d/rc.local Compatibility Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static; vendor preset: disabled) Active: failed (Result: exit-code) since sam. 2016-09-03 22:49:00
Another useless systemd message. This usually indicates an error in the script contained in rc.local. Try executing rc.local manually to see if there are any errors. If there are bash will provide much more useful information.
On 09/03/2016 03:09 PM, Joe Zeff wrote:
On 09/03/2016 01:59 PM, François Patte wrote:
On other nstall of fedora 23 this works.... Why not on this computer?
Have you compared that command line with the one used on the other computer to make sure there are no typos? I know it sounds obvious, but it's better to check now, than after days of ineffective troubleshooting.
rc-local.service is not supposed to be invoked by the command line. It is invoked by another service that wishes to be invoked AFTER rc-local. To wit: grep -r local.service /lib/systemd Binary file /lib/systemd/system-generators/systemd-rc-local-generator matches /lib/systemd/system/console-getty.service:After=rc-local.service /lib/systemd/system/serial-getty@.service:After=rc-local.service /lib/systemd/system/getty@.service:After=rc-local.service /lib/systemd/system/plymouth-quit-wait.service:After=rc-local.service plymouth-start.service systemd-user-sessions.service /lib/systemd/system/plymouth-quit.service:After=rc-local.service plymouth-start.service systemd-user-sessions.service /lib/systemd/system/console-shell.service:After=rc-local.service
On 09/03/16 16:59, François Patte wrote:
Bonsoir,
I try to enable rc-local service:
1- I created /etc/rc.d/rc.local file:
#!/bin/bash
iptables -I INPUT -p udp --sport 1900 -j ACCEPT
2- I chmoded /etc/rc.d/rc.local
chmod u+x /etc/rc.d/rc.local
Is the file owned by root.root?
On one of my systems:
# ls -l /etc/rc.d/rc.local -rwxr-xr-x. 1 root root 505 Aug 18 23:31 /etc/rc.d/rc.local
On 09/03/2016 05:22 PM, jd1008 wrote:
On 09/03/2016 03:09 PM, Joe Zeff wrote:
On 09/03/2016 01:59 PM, François Patte wrote:
On other nstall of fedora 23 this works.... Why not on this computer?
Have you compared that command line with the one used on the other computer to make sure there are no typos? I know it sounds obvious, but it's better to check now, than after days of ineffective troubleshooting.
rc-local.service is not supposed to be invoked by the command line.
Maybe I mis-phrased my question: is the one executable line in /etc/rc.d/rc.local identical to the one on the box that works, and if not, is the difference a possible cause of problems?
If that's not an issue, consider adding 2>/var/log/rc_errors.txt to that line to preserve the exact error messages.
Le 03/09/2016 23:17, Mike Wright a écrit :
On 09/03/2016 01:59 PM, François Patte wrote:
Bonsoir,
I try to enable rc-local service:
1- I created /etc/rc.d/rc.local file:
#!/bin/bash
iptables -I INPUT -p udp --sport 1900 -j ACCEPT
2- I chmoded /etc/rc.d/rc.local
chmod u+x /etc/rc.d/rc.local
But the service won't start:
# systemctl status rc-local.service ● rc-local.service - /etc/rc.d/rc.local Compatibility Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static; vendor preset: disabled) Active: failed (Result: exit-code) since sam. 2016-09-03 22:49:00
Another useless systemd message. This usually indicates an error in the script contained in rc.local. Try executing rc.local manually to see if there are any errors. If there are bash will provide much more useful information.
Executing rc.local file "by hand" works without errors and moreover the required command is fulfilled.... ie. in my case:
# iptables -L | grep ssdp ACCEPT udp -- anywhere anywhere udp spt:ssdp
In the /usr/lib/systemd/system/rc-local.service I can read: <quote> # This unit gets pulled automatically into multi-user.target by # systemd-rc-local-generator if /etc/rc.d/rc.local is executable. </quote>
It is exactly what I have done: making /etc/rc.d/rc.local executable (and owned by root.root) and it does not work!
Is there somewhere a place where I can get some information about the error? "Active: failed (Result: exit-code) since sam. 2016-09-03 22:49:00" is a very tiny explanation!
Thank You
On 4 September 2016 at 09:45, François Patte francois.patte@mi.parisdescartes.fr wrote:
Le 03/09/2016 23:17, Mike Wright a écrit :
On 09/03/2016 01:59 PM, François Patte wrote:
Bonsoir,
I try to enable rc-local service:
1- I created /etc/rc.d/rc.local file:
#!/bin/bash
iptables -I INPUT -p udp --sport 1900 -j ACCEPT
2- I chmoded /etc/rc.d/rc.local
chmod u+x /etc/rc.d/rc.local
But the service won't start:
# systemctl status rc-local.service ● rc-local.service - /etc/rc.d/rc.local Compatibility Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static; vendor preset: disabled) Active: failed (Result: exit-code) since sam. 2016-09-03 22:49:00
Another useless systemd message. This usually indicates an error in the script contained in rc.local. Try executing rc.local manually to see if there are any errors. If there are bash will provide much more useful information.
Executing rc.local file "by hand" works without errors and moreover the required command is fulfilled.... ie. in my case:
# iptables -L | grep ssdp ACCEPT udp -- anywhere anywhere udp spt:ssdp
In the /usr/lib/systemd/system/rc-local.service I can read:
<quote> # This unit gets pulled automatically into multi-user.target by # systemd-rc-local-generator if /etc/rc.d/rc.local is executable. </quote>
It is exactly what I have done: making /etc/rc.d/rc.local executable (and owned by root.root) and it does not work!
Is there somewhere a place where I can get some information about the error? "Active: failed (Result: exit-code) since sam. 2016-09-03 22:49:00" is a very tiny explanation!
I'd try this; in rc.local, put this on the line before the command line you want to execute: set -x
and put this on the line after the command line: set +x
cat /etc/rd.d/rc.local : ===============
#!/bin/bash touch /var/lock/subsys/local ... exit 0;
don't know if /var/lock line is needed today, but I get no error's ...
ls -l /etc/rd.d.&rc.local : ================= -rwx------. 1 root root 4,6K 4. Jun 19:56 rc.local
On 09/03/2016 08:41 PM, Kevin Cummings wrote:
On 09/03/16 16:59, François Patte wrote:
Bonsoir,
I try to enable rc-local service:
1- I created /etc/rc.d/rc.local file:
#!/bin/bash
iptables -I INPUT -p udp --sport 1900 -j ACCEPT
2- I chmoded /etc/rc.d/rc.local
chmod u+x /etc/rc.d/rc.local
Is the file owned by root.root?
On one of my systems:
# ls -l /etc/rc.d/rc.local -rwxr-xr-x. 1 root root 505 Aug 18 23:31 /etc/rc.d/rc.local
Does it not need to have logic to differentiate between start and stop ala
#!/bin/bash
case $1 in start) start some stuff and save exit_code ;; stop) stop some stuff and save exit_code ;; *) issue some error message and set exit_code to 1 esac
exit $exit_code
-jd
On 09/03/2016 11:42 PM, Joe Zeff wrote:
On 09/03/2016 05:22 PM, jd1008 wrote:
On 09/03/2016 03:09 PM, Joe Zeff wrote:
On 09/03/2016 01:59 PM, François Patte wrote:
On other nstall of fedora 23 this works.... Why not on this computer?
Have you compared that command line with the one used on the other computer to make sure there are no typos? I know it sounds obvious, but it's better to check now, than after days of ineffective troubleshooting.
rc-local.service is not supposed to be invoked by the command line.
Maybe I mis-phrased my question: is the one executable line in /etc/rc.d/rc.local identical to the one on the box that works, and if not, is the difference a possible cause of problems?
If that's not an issue, consider adding 2>/var/log/rc_errors.txt to that line to preserve the exact error messages.
Well I am at a loss re: "the on the box" Which one?
On 09/04/2016 01:45 AM, François Patte wrote:
Le 03/09/2016 23:17, Mike Wright a écrit :
On 09/03/2016 01:59 PM, François Patte wrote:
Bonsoir,
I try to enable rc-local service:
1- I created /etc/rc.d/rc.local file:
#!/bin/bash
iptables -I INPUT -p udp --sport 1900 -j ACCEPT
2- I chmoded /etc/rc.d/rc.local
chmod u+x /etc/rc.d/rc.local
But the service won't start:
# systemctl status rc-local.service ● rc-local.service - /etc/rc.d/rc.local Compatibility Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static; vendor preset: disabled) Active: failed (Result: exit-code) since sam. 2016-09-03 22:49:00
Another useless systemd message. This usually indicates an error in the script contained in rc.local. Try executing rc.local manually to see if there are any errors. If there are bash will provide much more useful information.
Executing rc.local file "by hand" works without errors and moreover the required command is fulfilled.... ie. in my case:
# iptables -L | grep ssdp ACCEPT udp -- anywhere anywhere udp spt:ssdp
In the /usr/lib/systemd/system/rc-local.service I can read:
<quote> # This unit gets pulled automatically into multi-user.target by # systemd-rc-local-generator if /etc/rc.d/rc.local is executable. </quote>
It is exactly what I have done: making /etc/rc.d/rc.local executable (and owned by root.root) and it does not work!
Is there somewhere a place where I can get some information about the error? "Active: failed (Result: exit-code) since sam. 2016-09-03 22:49:00" is a very tiny explanation!
Thank You
Can you post it's contents? Please feel free to omit stuff you deem would expose something private.
On 09/04/2016 11:45 AM, jd1008 wrote:
On 09/03/2016 11:42 PM, Joe Zeff wrote:
On 09/03/2016 05:22 PM, jd1008 wrote:
On 09/03/2016 03:09 PM, Joe Zeff wrote:
On 09/03/2016 01:59 PM, François Patte wrote:
On other nstall of fedora 23 this works.... Why not on this computer?
Have you compared that command line with the one used on the other computer to make sure there are no typos? I know it sounds obvious, but it's better to check now, than after days of ineffective troubleshooting.
rc-local.service is not supposed to be invoked by the command line.
Maybe I mis-phrased my question: is the one executable line in /etc/rc.d/rc.local identical to the one on the box that works, and if not, is the difference a possible cause of problems?
If that's not an issue, consider adding 2>/var/log/rc_errors.txt to that line to preserve the exact error messages.
Well I am at a loss re: "the on the box" Which one?
*Sigh!* Is the line in the file on the computer where it works identical to the one on the computer where it fails? I would have thought that the question was trivially obvious, but I've clearly over-estimated your ability to understand simple questions. And, just to avoid similar assumptions, add that text to the end of the line *on the computer where it fails* to preserve the exact error message.
On 09/04/2016 12:49 PM, Joe Zeff wrote:
On 09/04/2016 11:39 AM, jd1008 wrote:
Does it not need to have logic to differentiate between start and stop ala
No. The file is only used during boot, not shutdown or restart.
That's interesting. Then how does a script that IS startable and stoppable from the command line invoked as systemctl <start|stop> some-file.service
work?
On 09/04/2016 11:59 AM, jd1008 wrote:
That's interesting. Then how does a script that IS startable and stoppable from the command line invoked as systemctl <start|stop> some-file.service
The service may need to be stopped, started or restarted manually, but it's normally only invoked during boot.
On 09/04/2016 01:28 PM, Joe Zeff wrote:
On 09/04/2016 11:59 AM, jd1008 wrote:
That's interesting. Then how does a script that IS startable and stoppable from the command line invoked as systemctl <start|stop> some-file.service
The service may need to be stopped, started or restarted manually, but it's normally only invoked during boot.
Starting and shutting down specific services should be totally at the discretion of the user/administrator even during system normal operations.
Apparently you did not know about the stop command and are making incorrect assertion.
From the man page of systemctl, unit commands can be:
start NAME... Start (activate) one or more units specified on the command line.
stop NAME... Stop (deactivate) one or more units specified on the command line.
reload NAME... Asks all units listed on the command line to reload their configuration. Note that this will reload the service-specific configuration, not the unit configuration file of systemd. If you want systemd to reload the configuration file of a unit, use the daemon-reload command. In other words: for the example case of Apache, this will reload Apache's httpd.conf in the web server, not the apache.service systemd unit file.
This command should not be confused with the daemon-reload command.
restart NAME... Restart one or more units specified on the command line. If the units are not running yet, they will be started.
try-restart NAME... Restart one or more units specified on the command line if the units are running. This does nothing if units are not running. Note that, for compatibility with Red Hat init scripts, condrestart is equivalent to this command.
reload-or-restart NAME... Reload one or more units if they support it. If not, restart them instead. If the units are not running yet, they will be started.
reload-or-try-restart NAME...
On 09/04/2016 12:36 PM, jd1008 wrote:
Starting and shutting down specific services should be totally at the discretion of the user/administrator even during system normal operations.
Thank you for your blinding glimpse of the obvious. Clearly, you're not interested in my attempts to help you, so I'll stop, and let you work your own way out of your paper bag. (Hint: you're doing this the hard way.)
Le 03/09/2016 22:59, François Patte a écrit :
Bonsoir,
I try to enable rc-local service:
1- I created /etc/rc.d/rc.local file:
#!/bin/bash
iptables -I INPUT -p udp --sport 1900 -j ACCEPT
2- I chmoded /etc/rc.d/rc.local
chmod u+x /etc/rc.d/rc.local
But the service won't start:
# systemctl status rc-local.service ● rc-local.service - /etc/rc.d/rc.local Compatibility Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static; vendor preset: disabled) Active: failed (Result: exit-code) since sam. 2016-09-03 22:49:00 CEST; 25s ago Process: 8189 ExecStart=/etc/rc.d/rc.local start (code=exited, status=203/EXEC)
sept. 03 22:49:00 berrichon systemd[1]: Starting /etc/rc.d/rc.local Compatibility... sept. 03 22:49:00 berrichon systemd[1]: rc-local.service: Control process exited, code=exited ...203 sept. 03 22:49:00 berrichon systemd[1]: Failed to start /etc/rc.d/rc.local Compatibility. sept. 03 22:49:00 berrichon systemd[1]: rc-local.service: Unit entered failed state. sept. 03 22:49:00 berrichon systemd[1]: rc-local.service: Failed with result 'exit-code'. Hint: Some lines were ellipsized, use -l to show in full.
On other nstall of fedora 23 this works.... Why not on this computer?
Just unwanted spaces before and after #!/bin/bash
The script works when executed for itself, but it seems that systemd is quite supercilious about that spaces and very avaricious to give some hints about the error encountered!
Thank you for helping.
On 09/04/2016 01:34 PM, François Patte wrote:
Just unwanted spaces before and after #!/bin/bash
The script works when executed for itself, but it seems that systemd is quite supercilious about that spaces and very avaricious to give some hints about the error encountered!
Thank you for helping.
Interesting. I have some blank lines in mine, to improve readability, but not there. I'll have to keep that in mind for future reference. It's rather like mount insisting that every line in /etc/fstab end in a newline, even the last one, but not giving a clear error message if you forget it.
And, it's occurred to me that there's a way to get what's needed here done that's easier because it doesn't try to make the same change during every boot. Alas, I've gotten the impression that my advice isn't wanted in this thread, so I'll leave it as an exercise for the reader.
On Sun, Sep 04, 2016 at 10:34:20PM +0200, François Patte wrote:
Le 03/09/2016 22:59, François Patte a écrit :
On other nstall of fedora 23 this works.... Why not on this computer?
Just unwanted spaces before and after #!/bin/bash
The script works when executed for itself, but it seems that systemd is quite supercilious about that spaces and very avaricious to give some hints about the error encountered!
Thank you for helping.
The '#!' notation has meaning ONLY if it is the first two characters of the file. Otherwise it is just a shell comment.
From the command line you are probably running bash. Thus the script gets executed by the shell you want. But during boot it may be executed by a different shell and that shell may not deal with some constructs the same as bash.
Jon
-
Ahmad Samir -
François Patte -
JD -
Joe Zeff -
Jon LaBadie -
Kevin Cummings -
Mike Wright -
sixpack13