4:18 a.m.
I would say that this thread is the continuation of a my preceding thread :
“selecting some kind of files using the resync command”
There I got help in order to make the backup of some my critical files.
Now I am able to backing up these files using a shell script from the line
command.
But I would like also that this backup runs automatically when the computer
boots.
I know that this task is performed by the rc.local file, in Linux.
Ed Greshko gave me a link about an announcement of Fedora concerning
rc.local ....
there is wrote :
- - - - - - - - - -
The /etc/rc.d/rc.local local customization script is no longer included by
default. Administrators who need this functionality merely have to create
this file, make it executable, and it will run on boot.
- - - - - - - - - -
After I read this announcement, I create the the file rc.local and I made
it executable:
[angelo_dev@zorro rc.d]$ ls -l /etc/rc.d/rc.local
-rwxr-xr-x. 1 root root 1262 Oct 27 12:18 /etc/rc.d/rc.local
But, doing some tests, I saw that the scripts stored inside rc.local not
run at boot, ...on my computer.
I would like to have some advice concerning the way to manage tests, in
order to understand because the content of rc.local is not executed at the
start... and to obtain that scripts run at the boot
5:50 a.m.
Hi Frank,
I did it..,
Thank you
regards
On Mon, Nov 3, 2014 at 8:01 AM, Frank Murphy <frankly3d(a)gmail.com> wrote:
On Mon, 3 Nov 2014 07:47:30 +0200
Angelo Moreschini <mrangelo.fedora(a)gmail.com> wrote:
> Hi
> first of all I thank all those who have tried to help me.
> Now I have lost hope that this problem is currently solved by me.
> So I made a link to a command that * MANUALLY * starts the file
> /etc/rc.d/rc.init,; I can run this command via a graphical icon
> using Gnome interface.
>
Can you use gnome-schedule,
set it up to start at hour x every day?
As close as your boot-up time normally is?
___
Regards
Frank
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
12:01 a.m.
On Mon, 3 Nov 2014 07:47:30 +0200
Angelo Moreschini <mrangelo.fedora(a)gmail.com> wrote:
Hi
first of all I thank all those who have tried to help me.
Now I have lost hope that this problem is currently solved by me.
So I made a link to a command that * MANUALLY * starts the file
/etc/rc.d/rc.init,; I can run this command via a graphical icon
using Gnome interface.
Can you use gnome-schedule,
set it up to start at hour x every day?
As close as your boot-up time normally is?
___
Regards
Frank
11:47 p.m.
Hi
first of all I thank all those who have tried to help me.
Now I have lost hope that this problem is currently solved by me.
So I made a link to a command that * MANUALLY * starts the file
/etc/rc.d/rc.init,; I can run this command via a graphical icon using Gnome
interface.
This can be sufficient for my needs, at present ...
Perhaps, increasing my experience, I will be able to find a better solution in
the future.
Thanks mostly to Ed
Regards
Angelo
On Sat, Nov 1, 2014 at 10:12 PM, Bill Davidsen <davidsen(a)tmr.com> wrote:
Angelo Moreschini wrote:
> I would say that this thread is the continuation of a my preceding thread
> :
>
> “selecting some kind of files using the resync command”
>
>
> There I got help in order to make the backup of some my critical files.
>
> Now I am able to backing up these files using a shell script from the
> line command.
>
> But I would like also that this backup runs automatically when the
> computer boots.
>
>
> I know that this task is performed by the rc.local file, in Linux.
>
> Ed Greshko gave me a link about an announcement of Fedora concerning
> rc.local ....
>
> there is wrote :
>
> - - - - - - - - - -
>
> The |/etc/rc.d/rc.local| local customization script is no longer included
> by
> default. Administrators who need this functionality merely have to create
> this
> file, make it executable, and it will run on boot.
>
> - - - - - - - - - -
>
>
> After I read this announcement, I create the the file rc.local and I made
> it
> executable:
>
> [angelo_dev@zorro rc.d]$ ls -l /etc/rc.d/rc.local
>
> -rwxr-xr-x. 1 root root 1262 Oct 27 12:18 /etc/rc.d/rc.local
>
>
> But, doing some tests, I saw that the scripts stored inside rc.local not
> run at
> boot, ...on my computer.
>
>
> I would like to have some advice concerning the way to manage tests, in
> order to
> understand because the content of rc.local is not executed at the
> start... and
> toobtain thatscripts run atthe boot
>
> Having followed the thread as of the time of this message, a few
comments about scripts and such.
1 - redirection
You don't need to do separate redirects to put everything in the same
place,
exec &>/tmp/rc.local.log
will do it, and make it clear what your doing. Interestingly, if you are
running from a terminal, you can "echo foo >&0" and still write the
terminal
as long as STDIN is the terminal.
2 - directories
When you run a command, script or not, you may not be in the directory
you
expect, or have the right PATH. When running from rc.local, you will be
starting as root (unless you use su) in /root, using the root PATH.
The trick is to force a login as yourself:
su -c 'My cmd1; My cmd2' >My_log_optional - My-username
This will get you in your usual login directory, PATH, and UID.
3 - more on directories and PATH
when you run a command with the 'batch' or 'at' commands, they
start in the current directory, and in most cases the current
PATH and UID.
Sometimes when I create working files, logs, command output, I want
to save for a few days. I use the 'at' command to delete them in a few
days
so I leave less clutter if I don't use them. Starting in the current
directory is a benefit if you remember it will happen.
4 - logging
For crying out loud use the damn logger command to log stuff like
rc.local:
logger -t rc.local Started
# or on commands, use || to log fails:
My_cmd1 || logger -t rc.local "My_cmd1 exit with $! status"
# and when done:
logger -t rc.local "Complete, reached end"
Then you have a trail in the system log which you can find:
grep rc.local /var/log/messages
You can still put errors from a command in a file of its own, if
that provides documentation, but the note in the log remains you
it failed.
Hope this is going to help the original problem and some others as well.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
3:12 p.m.
Angelo Moreschini wrote:
I would say that this thread is the continuation of a my preceding
thread :
“selecting some kind of files using the resync command”
There I got help in order to make the backup of some my critical files.
Now I am able to backing up these files using a shell script from the line command.
But I would like also that this backup runs automatically when the computer boots.
I know that this task is performed by the rc.local file, in Linux.
Ed Greshko gave me a link about an announcement of Fedora concerning rc.local ....
there is wrote :
- - - - - - - - - -
The |/etc/rc.d/rc.local| local customization script is no longer included by
default. Administrators who need this functionality merely have to create this
file, make it executable, and it will run on boot.
- - - - - - - - - -
After I read this announcement, I create the the file rc.local and I made it
executable:
[angelo_dev@zorro rc.d]$ ls -l /etc/rc.d/rc.local
-rwxr-xr-x. 1 root root 1262 Oct 27 12:18 /etc/rc.d/rc.local
But, doing some tests, I saw that the scripts stored inside rc.local not run at
boot, ...on my computer.
I would like to have some advice concerning the way to manage tests, in order to
understand because the content of rc.local is not executed at the start... and
toobtain thatscripts run atthe boot
Having followed the thread as of the time of this message, a few comments about
scripts and such.
1 - redirection
You don't need to do separate redirects to put everything in the same place,
exec &>/tmp/rc.local.log
will do it, and make it clear what your doing. Interestingly, if you are
running from a terminal, you can "echo foo >&0" and still write the
terminal
as long as STDIN is the terminal.
2 - directories
When you run a command, script or not, you may not be in the directory you
expect, or have the right PATH. When running from rc.local, you will be
starting as root (unless you use su) in /root, using the root PATH.
The trick is to force a login as yourself:
su -c 'My cmd1; My cmd2' >My_log_optional - My-username
This will get you in your usual login directory, PATH, and UID.
3 - more on directories and PATH
when you run a command with the 'batch' or 'at' commands, they
start in the current directory, and in most cases the current
PATH and UID.
Sometimes when I create working files, logs, command output, I want
to save for a few days. I use the 'at' command to delete them in a few days
so I leave less clutter if I don't use them. Starting in the current
directory is a benefit if you remember it will happen.
4 - logging
For crying out loud use the damn logger command to log stuff like
rc.local:
logger -t rc.local Started
# or on commands, use || to log fails:
My_cmd1 || logger -t rc.local "My_cmd1 exit with $! status"
# and when done:
logger -t rc.local "Complete, reached end"
Then you have a trail in the system log which you can find:
grep rc.local /var/log/messages
You can still put errors from a command in a file of its own, if
that provides documentation, but the note in the log remains you
it failed.
Hope this is going to help the original problem and some others as well.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
5:21 p.m.
On 11/01/14 03:44, Angelo Moreschini wrote:
thank you for your patience Ed
I do not want to abuse your help .. maybe you can tell me what I can do.
If you show me a direction to follow, I will try to study also alone the problem ..
As I mentioned in my response to Joe, I think the symptoms have changed based on the
difference in exit codes reported on 10/29 and your most recent post. You've been
making changes and it is often easy to overlook or miss inserting new issues into the
mix.
Based on the new exit code, and the absence of a selinux AVC, I would go back in modify
the scripts to write their logs to files in /tmp to see if a good error message is now
being generated.
Note to Joe: Yes, now I do care about the output of "systemctl status
rc-local.service" :-) :-)
--
If you can't laugh at yourself, others will gladly oblige.
5:14 p.m.
On 11/01/14 03:01, Joe Zeff wrote:
On 10/31/2014 05:49 AM, Angelo Moreschini wrote:
> SELINUX=permissive =--> didn't work
>
> setsebool -P rsync_full_access 1 =--> didn't work too
Therefor SELinux isn't involved.
Yes, as it now stands selinux is not involved.
I would like to mention that I actually have had 2 test environments during this thread.
The first time that I "fixed" it I hadn't looked to see if there was a AVC.
Even though there were no error messages I considered it may be related to file
permissions or ownership. So, I called the script containing the rsync using "su
-c" to change to the user "programmers". This fixed the problem. It
also, resulted in being able to remove the"su -c". This was a head scratcher
for me.....but I didn't want to mention it he so as not to confuse things. But,
looking back, I suspect, running with the "su -c" may have had the effect of
changing the selinux context on the directory being written by rsync.
It was only in the second, newly built, environment that I spotted the AVC and fixed it as
I mentioned.
Now, all that being said, I think something has changed in the OPs environment. If you
look back on all the various messages and other threads you'll notice that he first
reported this on 10/29.
rc-local.service - /etc/rc.d/rc.local Compatibility
Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static)
Active: failed (Result: exit-code) since Tue 2014-10-28 17:07:57 IST; 3h 2min ago
Process: 877 ExecStart=/etc/rc.d/rc.local start (code=exited, status=3)
notice the exit status=3.
Most recently he reported this....
rc-local.service - /etc/rc.d/rc.local Compatibility
Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static)
Active: failed (Result: exit-code) since Fri 2014-10-31 20:43:44 IST; 2min 10s ago
Process: 891 ExecStart=/etc/rc.d/rc.local start (code=exited, status=1/FAILURE)
The exit status is now status=1/FAILURE.
Something has changed.
If I were doing the troubleshooting I would go back and fix the scripts to send their
logging information to files in /tmp to see if they are now generating usable error
messages.
--
If you can't laugh at yourself, others will gladly oblige.
4:59 p.m.
On 11/01/14 05:22, Joe Zeff wrote:
I also find it interesting that it was causing the command to fail
for you, but doesn't seem to be involved in the OP's case. I will be very
interested in learning just what's going on, and will continue to offer suggestions if
and when I have them.
Yes. There will be another response coming shortly to a message from you which *maybe*
will explain what I think is happening. (Like those hedges?)
--
If you can't laugh at yourself, others will gladly oblige.
4:22 p.m.
On 10/31/2014 02:09 PM, Ed Greshko wrote:
It was quite simple....
I replicated what I hoped to be the OP's environment in a VM. In doing so I also saw
a failure to successfully complete the execution of the rsync command. However, as you
saw, there were no error messages to be seen.
So, I simply looked in /var/log/audit/audit.log And saw this in AVC in the log...
type=AVC msg=audit(1414746668.306:107): avc: denied { search } for pid=805
comm="rsync" name="programmers" dev="dm-0" ino=786655
scontext=system_u:system_r:rsync_t:s0 tcontext=unconfined_u:object_r:user_home_dir_t:s0
tclass=dir permissive=0
Notice that the command in question is "rsync".
Then using the selinux tools available, determined that "setsebool -P
rsync_full_access 1" was a fix for the AVC.
I then rebooted and everything now works......for me.
Thank you. Asked and answered. The reason I asked in the first place
was because I've seen many people blame their Linux problems on SELinux
when there was absolutely no evidence that it was involved, and continue
to do so after they'd completely disabled it with no change to the
situation. In the lack of direct evidence, I tend to be skeptical of
such claims, because insisting that SELinux is the culprit in such cases
simply wastes time and effort that could be used to better effect in
finding evidence as to what really is the cause.
I also find it interesting that it was causing the command to fail for
you, but doesn't seem to be involved in the OP's case. I will be very
interested in learning just what's going on, and will continue to offer
suggestions if and when I have them.
4:09 p.m.
On 11/01/14 02:55, Joe Zeff wrote:
On 10/31/2014 02:21 AM, Ed Greshko wrote:
> The problem is related to "selinux".
How do you know? Are you getting SELinux alerts about this every time you boot?
It was quite simple....
I replicated what I hoped to be the OP's environment in a VM. In doing so I also saw
a failure to successfully complete the execution of the rsync command. However, as you
saw, there were no error messages to be seen.
So, I simply looked in /var/log/audit/audit.log And saw this in AVC in the log...
type=AVC msg=audit(1414746668.306:107): avc: denied { search } for pid=805
comm="rsync" name="programmers" dev="dm-0" ino=786655
scontext=system_u:system_r:rsync_t:s0 tcontext=unconfined_u:object_r:user_home_dir_t:s0
tclass=dir permissive=0
Notice that the command in question is "rsync".
Then using the selinux tools available, determined that "setsebool -P
rsync_full_access 1" was a fix for the AVC.
I then rebooted and everything now works......for me.
My failure, of course, was to assume that I'd replicated the OPs environment as it is
now.
I'm not in the habit of making blind guesses. I tend to try an replicate problems to
test fixes. I did so.
I'm of the impression that things have changed from the OP's original problem,
which I will explain later.
--
If you can't laugh at yourself, others will gladly oblige.
3:06 p.m.
On 10/31/2014 12:44 PM, Angelo Moreschini wrote:
thank you for your patience Ed
I do not want to abuse your help .. maybe you can tell me what I can do.
If you show me a direction to follow, I will try to study also alone the
problem
If I knew the answer, I'd tell you. Alas, all I can do at this point is
keep you from trying to solve an issue with SELinux that doesn't exist.
However, there is one thought: we're pretty sure that there's something
about the rsync command that's failing. Have you considered directing
stderr to a file?
2:44 p.m.
thank you for your patience Ed
I do not want to abuse your help .. maybe you can tell me what I can do.
If you show me a direction to follow, I will try to study also alone the
problem ..
regards
Angelo
On Fri, Oct 31, 2014 at 9:01 PM, Joe Zeff <joe(a)zeff.us> wrote:
On 10/31/2014 05:49 AM, Angelo Moreschini wrote:
> SELINUX=permissive =--> didn't work
>
> setsebool -P rsync_full_access 1 =--> didn't work too
>
Therefor SELinux isn't involved.
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
7:16 a.m.
On 10/31/14 17:21, Ed Greshko wrote:
The problem is related to "selinux".
The selinux fix for this would be to issue this command as root, just once in a terminal
session....
setsebool -P rsync_full_access 1
And then reboot.
--
If you can't laugh at yourself, others will gladly oblige.
1:50 p.m.
[angelo_dev@zorro ~]$ systemctl status rc-local.service
rc-local.service - /etc/rc.d/rc.local Compatibility
Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static)
Active: failed (Result: exit-code) since Fri 2014-10-31 20:43:44 IST;
2min 10s ago
Process: 891 ExecStart=/etc/rc.d/rc.local start (code=exited,
status=1/FAILURE)
On Fri, Oct 31, 2014 at 7:41 PM, Ed Greshko <ed.greshko(a)greshko.com> wrote:
On 10/31/14 22:56, Angelo Moreschini wrote:
> 1) [root@zorro ~]# cat /dev/null > /var/log/audit/audit.log
> [root@zorro ~]#
>
> # empty input
>
> 4) [root@zorro angelo_dev]# grep AVC /var/log/audit/audit.log > avcs
>
> 5) [root@zorro angelo_dev]# cat avcs =--- > empty
> ([root@zorro angelo_dev]# cat avcs
> -rw-r--r--. 1 root root 0 Oct 31 16:52 avcs)
And, after you reboot, what does this show....
systemctl status rc-local.service
--
If you can't laugh at yourself, others will gladly oblige.
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
9:56 a.m.
1) [root@zorro ~]# cat /dev/null > /var/log/audit/audit.log
[root@zorro ~]#
# empty input
4) [root@zorro angelo_dev]# grep AVC /var/log/audit/audit.log > avcs
5) [root@zorro angelo_dev]# cat avcs =--- > empty
([root@zorro angelo_dev]# cat avcs
-rw-r--r--. 1 root root 0 Oct 31 16:52 avcs)
thank you
On Fri, Oct 31, 2014 at 3:13 PM, Ed Greshko <ed.greshko(a)greshko.com> wrote:
On 10/31/14 20:49, Angelo Moreschini wrote:
> SELINUX=permissive =--> didn't work
>
> setsebool -P rsync_full_access 1 =--> didn't work too
>
> > Do you have an actual user "programmers" defined?
> yes : angelo_dev is a member of this group
Well, this is crazy.....
I can recreate the symptoms of your problems and fix it....but you seem to
have something different.
OK....
Do the following as root....
1. cat /dev/null > /var/log/audit/audit.log
2. reboot
3. When the system comes up....
4. grep AVC /var/log/audit/audit.log > avcs
5. post the contents of avcs
--
If you can't laugh at yourself, others will gladly oblige.
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
8:13 a.m.
On 10/31/14 20:49, Angelo Moreschini wrote:
SELINUX=permissive =--> didn't work
setsebool -P rsync_full_access 1 =--> didn't work too
> Do you have an actual user "programmers" defined?
yes : angelo_dev is a member of this group
Well, this is crazy.....
I can recreate the symptoms of your problems and fix it....but you seem to have something
different.
OK....
Do the following as root....
1. cat /dev/null > /var/log/audit/audit.log
2. reboot
3. When the system comes up....
4. grep AVC /var/log/audit/audit.log > avcs
5. post the contents of avcs
--
If you can't laugh at yourself, others will gladly oblige.
7:49 a.m.
SELINUX=permissive =--> didn't work
setsebool -P rsync_full_access 1 =--> didn't work too
Do you have an actual user "programmers" defined?
yes
: angelo_dev is a member of this group
On Fri, Oct 31, 2014 at 2:16 PM, Ed Greshko <ed.greshko(a)greshko.com> wrote:
On 10/31/14 17:21, Ed Greshko wrote:
> The problem is related to "selinux".
The selinux fix for this would be to issue this command as root, just once
in a terminal session....
setsebool -P rsync_full_access 1
And then reboot.
--
If you can't laugh at yourself, others will gladly oblige.
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
5:54 a.m.
On 10/31/14 18:14, Angelo Moreschini wrote:
I tried :
# this is the file /etc/rc./rc.local
/etc/rc.d/dummy-test.sh
#/etc/rc.d/syncronize-java_srcs.sh
su -c '/etc/rc.d/syncronize-java_srcs.sh' programmers
Do you have an actual user "programmers" defined?
------
but didn't work
I understand what you are talking Ed, but I am a newbie and yet I am not able to manage
problems concerning SELinux
Could you try one more thing?
Edit /etc/selinux/config
Change to
SELINUX=permissive
And reboot.....
Check to see if the rsync has worked.
On Fri, Oct 31, 2014 at 11:21 AM, Ed Greshko <ed.greshko(a)greshko.com
<mailto:ed.greshko@greshko.com>> wrote:
On 10/31/14 16:32, Ed Greshko wrote:
> It is unfortunate that I've not been able to get any error message to
display. I have an idea of the problem and why no message is shown....but again...too
tired.
OK.... I know what the problem is related to.... And, I know how to get around it
(the su -c trick), but I don't know the way to really "fix" the issue....and
I know what I'm about to say may cause some to react poorly.
The problem is related to "selinux".
--
If you can't laugh at yourself, others will gladly oblige.
--
users mailing list
users(a)lists.fedoraproject.org <mailto:users@lists.fedoraproject.org>
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
--
If you can't laugh at yourself, others will gladly oblige.
5:14 a.m.
I tried :
# this is the file /etc/rc./rc.local
/etc/rc.d/dummy-test.sh
#/etc/rc.d/syncronize-java_srcs.sh
su -c '/etc/rc.d/syncronize-java_srcs.sh' programmers
------
but didn't work
I understand what you are talking Ed, but I am a newbie and yet I am not
able to manage problems concerning SELinux
thank you
On Fri, Oct 31, 2014 at 11:21 AM, Ed Greshko <ed.greshko(a)greshko.com> wrote:
On 10/31/14 16:32, Ed Greshko wrote:
> It is unfortunate that I've not been able to get any error message to
display. I have an idea of the problem and why no message is shown....but
again...too tired.
OK.... I know what the problem is related to.... And, I know how to get
around it (the su -c trick), but I don't know the way to really "fix" the
issue....and I know what I'm about to say may cause some to react poorly.
The problem is related to "selinux".
--
If you can't laugh at yourself, others will gladly oblige.
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
4:21 a.m.
On 10/31/14 16:32, Ed Greshko wrote:
It is unfortunate that I've not been able to get any error
message to display. I have an idea of the problem and why no message is shown....but
again...too tired.
OK.... I know what the problem is related to.... And, I know how to get around it (the
su -c trick), but I don't know the way to really "fix" the issue....and I
know what I'm about to say may cause some to react poorly.
The problem is related to "selinux".
--
If you can't laugh at yourself, others will gladly oblige.
3:32 a.m.
On 10/31/14 16:22, Angelo Moreschini wrote:
Hi Rick,
your suggestion seemed to be the right one ..
But still did not work ...
I made now one further try :
these are the listed files I used
It isn't related to $PATH .... I'm too tired to explain again....
-------------------------[angelo_dev@zorro rc.d]$ cat rc.local---------
#!/bin/bash
/etc/rc.d/dummy-test.sh
Please try again to change this line....
/etc/rc.d/syncronize-java_srcs.sh
to this.....
su -c '/etc/rc.d/syncronize-java_srcs.sh' programmers
and see if it works....
It works for me....
------------------------[angelo_dev@zorro rc.d]$ cat dummy-test.sh--------------
#!/bin/bash
cp /home/angelo_dev/Documents/dconf-Editor.xcf /media/PRTZ-src_sync
----------------[angelo_dev@zorro rc.d]$ cat syncronize-java_srcs.sh--------
#!/bin/bash
/usr/bin/rsync -av \
--delete \
--include='*/' \
--include='*.java' \
--include='*.form' \
--exclude='*' \
/home/programmers/java/PROJECTS_development/ \
/media/PRTZ-src_sync
==============
1) if I launch rc.local _from the command line_ then
the _file is copied_ and _the backup is done_
2) if I _reboot the computer_ then
the _file is copied_ *BUT* _the backup is not done_...
The test proves conclusively that the failure is related to the use of the rsync command
...
but can not depend on its path because this time I used the absolute path ..
Need to investigate more about something specific related to the rsync command
It is unfortunate that I've not been able to get any error message to display. I have
an idea of the problem and why no message is shown....but again...too tired.
Try what I've suggested above. And if it works, be happy. At least for now.
--
If you can't laugh at yourself, others will gladly oblige.
3:22 a.m.
Hi Rick,
your suggestion seemed to be the right one ..
But still did not work ...
I made now one further try :
these are the listed files I used
-------------------------[angelo_dev@zorro rc.d]$ cat rc.local---------
#!/bin/bash
/etc/rc.d/dummy-test.sh
/etc/rc.d/syncronize-java_srcs.sh
------------------------[angelo_dev@zorro rc.d]$ cat
dummy-test.sh--------------
#!/bin/bash
cp /home/angelo_dev/Documents/dconf-Editor.xcf /media/PRTZ-src_sync
----------------[angelo_dev@zorro rc.d]$ cat syncronize-java_srcs.sh--------
#!/bin/bash
/usr/bin/rsync -av \
--delete \
--include='*/' \
--include='*.java' \
--include='*.form' \
--exclude='*' \
/home/programmers/java/PROJECTS_development/ \
/media/PRTZ-src_sync
==============
1) if I launch rc.local *from the command line* then
the *file is copied* and *the backup is done*
2) if I *reboot the computer* then
the *file is copied* *BUT* *the backup is not done*...
The test proves conclusively that the failure is related to the use of
the rsync
command ...
but can not depend on its path because this time I used the absolute path ..
Need to investigate more about something specific related to the rsync
command
Thank Rick you for your advice
On Fri, Oct 31, 2014 at 2:41 AM, Rick Stevens <ricks(a)alldigital.com> wrote:
On 10/29/2014 09:06 PM, Angelo Moreschini issued this missive:
> Hi Ed,
>
> I also thought that I setting controls the command in a different way
> could be the solution.
> But it did not was so.
> The question is now, however, morelimited: it is about understanding why
> a script that can be run from the command line, does not run inside the
> file /etc/rc.d/rc.local
Because the /etc/rc.d/rc.local script does not have your login
environment. The odds are that the path to one or more of your commands
is missing. If you want to prove this, modify your script to do
something like
echo $PATH >/tmp/path.txt
and reboot. Compare the contents of /tmp/path.txt and "echo $PATH" at
the command line and I'll bet the paths are different.
This is incredibly common for startup scripts and crontab entries. If
you wish to avoid them, ensure you have a "PATH=" command in the top
of your script or specify the full path to each command inside the
script:
/usr/bin/rsync........
NOT
rsync.....
because "/usr/bin" may NOT be in the crontab or initscript's PATH.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- After a shooting spree, they always want to take the guns away -
- from the people who didn't do it. -
- -- William S.Burroughs -
----------------------------------------------------------------------
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
7:41 p.m.
On 10/29/2014 09:06 PM, Angelo Moreschini issued this missive:
Hi Ed,
I also thought that I setting controls the command in a different way
could be the solution.
But it did not was so.
The question is now, however, morelimited: it is about understanding why
a script that can be run from the command line, does not run inside the
file /etc/rc.d/rc.local
Because the /etc/rc.d/rc.local script does not have your login
environment. The odds are that the path to one or more of your commands
is missing. If you want to prove this, modify your script to do
something like
echo $PATH >/tmp/path.txt
and reboot. Compare the contents of /tmp/path.txt and "echo $PATH" at
the command line and I'll bet the paths are different.
This is incredibly common for startup scripts and crontab entries. If
you wish to avoid them, ensure you have a "PATH=" command in the top
of your script or specify the full path to each command inside the
script:
/usr/bin/rsync........
NOT
rsync.....
because "/usr/bin" may NOT be in the crontab or initscript's PATH.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- After a shooting spree, they always want to take the guns away -
- from the people who didn't do it. -
- -- William S.Burroughs -
----------------------------------------------------------------------
11:35 p.m.
On 10/29/2014 10:20 PM, Ed Greshko wrote:
On 10/30/14 12:06, Angelo Moreschini wrote:
> I also thought that I setting controls the command in a different way could be the
solution.
> But it did not was so.
> The question is now, however, morelimited: it is about understanding why a script
that can be run from the command line, does not run inside the file /etc/rc.d/rc.local
>
Normally when a command doesn't run correctly in a start-up environment it has to do
with either permissions (file ownership), or something associated with environment
variables. But, usually you get an error recorded and can see and fix the problem with
ease.
This was different. I don't know why it needed to be done this way. But, works.....
Maybe I'll do a bit more research but I may chalk it up to "PFM". (Pure
"Freakin" Magic)
So, hope all is well for you now.....
Ed I think it has to be shell environment, as you suspect.
I was wondering if Angelo can set up his script which is
run from rc.local to first source a file which sets up the
run env variables to be identical to his shell env when
he runs his script from the command line.
Just my $.02's worth.
11:20 p.m.
On 10/30/14 12:06, Angelo Moreschini wrote:
I also thought that I setting controls the command in a different way
could be the solution.
But it did not was so.
The question is now, however, morelimited: it is about understanding why a script that
can be run from the command line, does not run inside the file /etc/rc.d/rc.local
Normally when a command doesn't run correctly in a start-up environment it has to do
with either permissions (file ownership), or something associated with environment
variables. But, usually you get an error recorded and can see and fix the problem with
ease.
This was different. I don't know why it needed to be done this way. But, works.....
Maybe I'll do a bit more research but I may chalk it up to "PFM". (Pure
"Freakin" Magic)
So, hope all is well for you now.....
--
If you can't laugh at yourself, others will gladly oblige.
11:06 p.m.
Hi Ed,
I also thought that I setting controls the command in a different way could be
the solution.
But it did not was so.
The question is now, however, more limited: it is about understanding why a
script that can be run from the command line, does not run inside the file /
etc/rc.d/rc.local
On Thu, Oct 30, 2014 at 1:51 AM, Ed Greshko <ed.greshko(a)greshko.com> wrote:
On 10/29/14 22:08, Angelo Moreschini wrote:
>
> angelo_dev@zorro rc.d]$ cat /tmp/syncronize.log
> + rsync -av --delete '--include=*/' '--include=*.java'
'--include=*.form' '--exclude=*'
/home/programmers/java/PROJECTS_development/ /media/PRTZ-src_sync
>
>
OK.... This means that the script syncronize-java_srcs.sh ran.....but is
still failing for some unknown reason.
I replicated, as far as I know, your environment and I recreated the
problem. I have made a guess....and have fixed it.
In your rc.local file change this line....
/etc/rc.d/syncronize-java_srcs.sh
to this
su -c '/etc/rc.d/syncronize-java_srcs.sh' programmers
and it should be fine.
--
If you can't laugh at yourself, others will gladly oblige.
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
6:51 p.m.
On 10/29/14 22:08, Angelo Moreschini wrote:
angelo_dev@zorro rc.d]$ cat /tmp/syncronize.log
+ rsync -av --delete '--include=*/' '--include=*.java'
'--include=*.form' '--exclude=*'
/home/programmers/java/PROJECTS_development/ /media/PRTZ-src_sync
OK.... This means that the script syncronize-java_srcs.sh ran.....but is still failing
for some unknown reason.
I replicated, as far as I know, your environment and I recreated the problem. I have made
a guess....and have fixed it.
In your rc.local file change this line....
/etc/rc.d/syncronize-java_srcs.sh
to this
su -c '/etc/rc.d/syncronize-java_srcs.sh' programmers
and it should be fine.
--
If you can't laugh at yourself, others will gladly oblige.
9:08 a.m.
[
angelo_dev@zorro rc.d]$ cat /tmp/syncronize.log
+ rsync -av --delete '--include=*/' '--include=*.java'
'--include=*.form'
'--exclude=*' /home/programmers/java/PROJECTS_development/
/media/PRTZ-src_sync
On Wed, Oct 29, 2014 at 2:09 PM, Ed Greshko <ed.greshko(a)greshko.com> wrote:
On 10/29/14 19:08, Angelo Moreschini wrote:
> Hi,
>
> I did some tests:
>
> This is the content of the file /etc/rc.d/rc.local that I used:
> ------------------------------
> #!/bin/bash
> # this is the file /ctc/rc./rc.local
>
> /etc/rc.d/dummy-test.sh
> /etc/rc.d/syncronize-java_srcs.sh
> ------------------------------
>
> I put inside it two script to be executed:
>
> /etc/rc.d/dummy-test.sh (to make a simple copy of a
file)
> /etc/rc.d/syncronize-java_srcs.sh (to make backups ..)
>
> -----------------------------------
> [angelo_dev@zorro rc.d]$ cat dummy-test.sh
> #!/bin/bash
> cp /home/angelo_dev/Documents/dconf-Editor.xcf /media/PRTZ-src_sync
> ---------------------------------
>
> ---------------------------------
> [angelo_dev@zorro rc.d]$ cat syncronize-java_srcs.sh
> #!/bin/bash
> # this is the file /home/angelo_dev/bin/syncronize-java_srcs.sh
>
>
> rsync -av --delete --include='*/' --include='*.java'
--include='*.form'
--exclude='*' \
> /home/programmers/java/PROJECTS_development/
\
> /media/PRTZ-src_sync
> ---------------------------
>
> the scripts are both in the same directory... ( the same directory than
rc.local)
>
> NOW :
> doing the reboot, only the first script is executed
> NOT the second one
>
> So I have the _copy_ of the file (for test) _but not the backup.
> _
> how it can be interpreted that fact ?
The second script *IS* getting executed. But, for some reason, it is
failing. I don't know how many times that can be repeated.
Change that script to this....
---------------------------
[egreshko@meimei ~]$ cat syncronize-java_srcs.sh
#!/bin/bash
# this is the file /home/angelo_dev/bin/syncronize-java_srcs.sh
exec 2> /tmp/syncronize.log # send stderr from rc.local to a log file
exec 1>&2 # send stdout to the same log file
set -x # tell sh to display commands before
execution
rsync -av --delete --include='*/' --include='*.java'
--include='*.form'
--exclude='*' \
/home/programmers/java/PROJECTS_development/ \
/media/PRTZ-src_sync
--------------------------
Reboot and supply the contents of /tmp/syncronize.log
--
If you can't laugh at yourself, others will gladly oblige.
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
7:09 a.m.
On 10/29/14 19:08, Angelo Moreschini wrote:
Hi,
I did some tests:
This is the content of the file /etc/rc.d/rc.local that I used:
------------------------------
#!/bin/bash
# this is the file /ctc/rc./rc.local
/etc/rc.d/dummy-test.sh
/etc/rc.d/syncronize-java_srcs.sh
------------------------------
I put inside it two script to be executed:
/etc/rc.d/dummy-test.sh (to make a simple copy of a file)
/etc/rc.d/syncronize-java_srcs.sh (to make backups ..)
-----------------------------------
[angelo_dev@zorro rc.d]$ cat dummy-test.sh
#!/bin/bash
cp /home/angelo_dev/Documents/dconf-Editor.xcf /media/PRTZ-src_sync
---------------------------------
---------------------------------
[angelo_dev@zorro rc.d]$ cat syncronize-java_srcs.sh
#!/bin/bash
# this is the file /home/angelo_dev/bin/syncronize-java_srcs.sh
rsync -av --delete --include='*/' --include='*.java'
--include='*.form' --exclude='*' \
/home/programmers/java/PROJECTS_development/ \
/media/PRTZ-src_sync
---------------------------
the scripts are both in the same directory... ( the same directory than rc.local)
NOW :
doing the reboot, only the first script is executed
NOT the second one
So I have the _copy_ of the file (for test) _but not the backup.
_
how it can be interpreted that fact ?
The second script *IS* getting executed. But, for some reason, it is failing. I
don't know how many times that can be repeated.
Change that script to this....
---------------------------
[egreshko@meimei ~]$ cat syncronize-java_srcs.sh
#!/bin/bash
# this is the file /home/angelo_dev/bin/syncronize-java_srcs.sh
exec 2> /tmp/syncronize.log # send stderr from rc.local to a log file
exec 1>&2 # send stdout to the same log file
set -x # tell sh to display commands before execution
rsync -av --delete --include='*/' --include='*.java'
--include='*.form' --exclude='*' \
/home/programmers/java/PROJECTS_development/ \
/media/PRTZ-src_sync
--------------------------
Reboot and supply the contents of /tmp/syncronize.log
--
If you can't laugh at yourself, others will gladly oblige.
6:08 a.m.
Hi,
I did some tests:
This is the content of the file /etc/rc.d/rc.local that I used:
------------------------------
#!/bin/bash
# this is the file /ctc/rc./rc.local
/etc/rc.d/dummy-test.sh
/etc/rc.d/syncronize-java_srcs.sh
------------------------------
I put inside it two script to be executed:
/etc/rc.d/dummy-test.sh (to make a simple copy of a file)
/etc/rc.d/syncronize-java_srcs.sh (to make backups ..)
-----------------------------------
[angelo_dev@zorro rc.d]$ cat dummy-test.sh
#!/bin/bash
cp /home/angelo_dev/Documents/dconf-Editor.xcf /media/PRTZ-src_sync
---------------------------------
---------------------------------
[angelo_dev@zorro rc.d]$ cat syncronize-java_srcs.sh
#!/bin/bash
# this is the file /home/angelo_dev/bin/syncronize-java_srcs.sh
rsync -av --delete --include='*/' --include='*.java'
--include='*.form'
--exclude='*' \
/home/programmers/java/PROJECTS_development/ \
/media/PRTZ-src_sync
---------------------------
the scripts are both in the same directory... ( the same directory than
rc.local)
NOW :
doing the reboot, only the first script is executed
NOT the second one
So I have the *copy* of the file (for test)
*but not the backup.*
how it can be interpreted that fact ?
On Wed, Oct 29, 2014 at 8:17 AM, Joe Zeff <joe(a)zeff.us> wrote:
On 10/28/2014 11:08 PM, Angelo Moreschini wrote:
> the file “sol”: (-rwxr-xr-x. 1 root root 62480 Mar 5 2014 /usr/bin/touch)
>
>
> is an executable (a card game that can run seamlessly from the command
> line).
>
>
> At the boot, the program “sol” has _*not been launched*_ yet.
>
>
The program is, as I understand, a GUI game written to run in the X
Windowing environment, which doesn't start until after you log in. How do
you expect it to run at boot?
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
1:17 a.m.
On 10/28/2014 11:08 PM, Angelo Moreschini wrote:
the file “sol”: (-rwxr-xr-x. 1 root root 62480 Mar 5 2014
/usr/bin/touch)
is an executable (a card game that can run seamlessly from the command
line).
At the boot, the program “sol” has _*not been launched*_ yet.
The program is, as I understand, a GUI game written to run in the X
Windowing environment, which doesn't start until after you log in. How
do you expect it to run at boot?
1:08 a.m.
Hi,
I made now another try ...
I modified the file /etc/rc.d rc.local in this way :
- - - - - - - - - - - -
#! / bin / bash
# This the the file /ctc/rc./rc.local
/usr/bin/sol
- - - - - - - - - - - -
the file “sol”: (-rwxr-xr-x. 1 root root 62480 Mar 5 2014 /usr/bin/touch)
is an executable (a card game that can run seamlessly from the command
line).
At the boot, the program “sol” has *not been launched* yet.
I am a beginner with Linux, so my question perhaps is silly, but it seems
logical to ask :
*because instead /usr/bin/touch was run* ?
On Wed, Oct 29, 2014 at 3:07 AM, Ed Greshko <ed.greshko(a)greshko.com> wrote:
On 10/29/14 08:36, Joe Zeff wrote:
> On 10/28/2014 04:18 PM, Ed Greshko wrote:
>> Since /tmp/rc.local.log exists and contains
>>
>> + /home/angelo_dev/bin/syncronize-java_srcs.sh
>>
>> it is obvious that rc.local is being executed.
>>
>> If I were going to assume something I would assume the systemctl
failure is related to the failure in the syncronize-java_srcs.sh script.
>
> My guess is that one of the scripts being called failed, causing
rc.local to abort. Maybe it would help to put a line like this just at the
end of each script called:
Let me say this again.... rc.local *did not* abort. It exited and the
last exit code was that returned by syncronize-java_srcs.sh
>
> echo "$FOO.sh completed" >> /temp/rc.local.log
>
> If something in the script fails, the script doesn't complete and the
line isn't written in the log. Adding print statements to help debugging
is a very old technique, but it's helped me find out just where things went
wrong many times over the decades.
What I've asked for from the OP will help *me* to determine what is
failing when "rsync" is being called.
If you want him to do something else....talk to him.
--
If you can't laugh at yourself, others will gladly oblige.
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
12:41 p.m.
On 10/31/14 22:56, Angelo Moreschini wrote:
1) [root@zorro ~]# cat /dev/null > /var/log/audit/audit.log
[root@zorro ~]#
# empty input
4) [root@zorro angelo_dev]# grep AVC /var/log/audit/audit.log > avcs
5) [root@zorro angelo_dev]# cat avcs =--- > empty
([root@zorro angelo_dev]# cat avcs
-rw-r--r--. 1 root root 0 Oct 31 16:52 avcs)
And, after you reboot, what does this show....
systemctl status rc-local.service
--
If you can't laugh at yourself, others will gladly oblige.
1:12 p.m.
[angelo_dev@zorro ~]$ *ls -l /etc/rc.d/rc.local*
-rwxr-xr-x. 1 root root 315 Oct 28 16:55 /etc/rc.d/rc.local
[angelo_dev@zorro ~]$ *systemctl status rc-local.service*
rc-local.service - /etc/rc.d/rc.local Compatibility
Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static)
Active: failed (Result: exit-code) since Tue 2014-10-28 17:07:57 IST; 3h
2min ago
Process: 877 ExecStart=/etc/rc.d/rc.local start (code=exited, status=3)
On Tue, Oct 28, 2014 at 7:47 PM, Joe Zeff <joe(a)zeff.us> wrote:
On 10/28/2014 02:18 AM, Angelo Moreschini wrote:
> I would like to have some advice concerning the way to manage tests, in
> order to understand because the content of rc.local is not executed at
> the start... and to obtain that scripts run at the boot
>
Post the results of these commands:
ls -l /etc/rc.d/rc.local
systemctl status rc-local.service
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
10:39 a.m.
Hi Ed,
How I said you in the preceded thread,* the file hello was created (when I
tried the first time. I deleted it recently.).*
Now I am send you the contents of the files .. :(but I am not able to
understand totally what you suggest me to do)
- - - - - - - - - - - - - - - - - - - - 1) the content of the file
/ctc/rc./rc.local
--------------------------------------------------------------
#!/bin/bash
# this i the file /ctc/rc./rc.local
exec 2> /tmp/rc.local.log # send stderr from rc.local to a log file
exec 1>&2 # send stdout to the same log file
set -x # tell sh to display commands before execution
/home/angelo_dev/bin/syncronize-java_srcs.sh
- - - - - - - - - - - - - - - - - - - - 2) the content of the
file/home/angelo_dev/bin/syncronize-java_srcs.sh-------------------
#!/bin/bash
# this is the file /home/angelo_dev/bin/syncronize-java_srcs.sh
rsync -av --delete --include='*/' --include='*.java'
--include='*.form'
--exclude='*' \
/home/programmers/java/PROJECTS_development/ \
/media/PRTZ-src_sync
(this script works if I launch it from line command)
- - - - - - - - - - - - - - - - - - - - 3) the content of the file
/tmp/rc.local.log
-------------------------------------------------------------
[angelo_dev@zorro ~]$ vi /tmp/rc.local.log
+ /home/angelo_dev/bin/syncronize-java_srcs.sh
(I don't see nothing about the test...)
Thank you
Regards
Angelo
On Tue, Oct 28, 2014 at 1:34 PM, Ed Greshko <ed.greshko(a)greshko.com> wrote:
On 10/28/14 19:08, Ed Greshko wrote:
> On 10/28/14 17:18, Angelo Moreschini wrote:
>> After I read this announcement, I create the the file rc.local and I
made it executable:
>>
>> [angelo_dev@zorro rc.d]$ ls -l /etc/rc.d/rc.local
>>
>> -rwxr-xr-x. 1 root root 1262 Oct 27 12:18 /etc/rc.d/rc.local
>>
>>
>> But, doing some tests, I saw that the scripts stored inside rc.local
not run at boot, ...on my computer.
>>
> I don't believe you have determined that it is not getting run at boot
time as opposed to having a failure in the script itself.
>
> As I've mentioned in a previous thread.... You should have this at the
top of your rc.local
>
> #!/bin/bash
> /bin/touch /tmp/hello
>
> Then after boot check that there is a file in /tmp with the name "hello".
>
> If there is....the script is being run.
>
> How many commands are in your script?
>
> It may be helpful to direct standard error to a file for each command as
it seems to be a small script.
>
> So do something like this.....
>
> some command 2> /tmp/first-error
> next command 2> /tmp/second-error
>
> Then check /tmp/first-error and /tmp/second-error for errors.....
>
> You may also want to simply post the contents of your rc.local for
others to examine for potential problems.
>
>
And alternative to this is to have this at the top of your rc.local
file....
#!/bin/bash
exec 2> /tmp/rc.local.log # send stderr from rc.local to a log file
exec 1>&2 # send stdout to the same log file
set -x # tell sh to display commands before
execution
And then check /tmp/rc.local.log
--
If you can't laugh at yourself, others will gladly oblige.
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
6:34 a.m.
On 10/28/14 19:08, Ed Greshko wrote:
On 10/28/14 17:18, Angelo Moreschini wrote:
> After I read this announcement, I create the the file rc.local and I made it
executable:
>
> [angelo_dev@zorro rc.d]$ ls -l /etc/rc.d/rc.local
>
> -rwxr-xr-x. 1 root root 1262 Oct 27 12:18 /etc/rc.d/rc.local
>
>
> But, doing some tests, I saw that the scripts stored inside rc.local not run at boot,
...on my computer.
>
I don't believe you have determined that it is not getting run at boot time as
opposed to having a failure in the script itself.
As I've mentioned in a previous thread.... You should have this at the top of your
rc.local
#!/bin/bash
/bin/touch /tmp/hello
Then after boot check that there is a file in /tmp with the name "hello".
If there is....the script is being run.
How many commands are in your script?
It may be helpful to direct standard error to a file for each command as it seems to be a
small script.
So do something like this.....
some command 2> /tmp/first-error
next command 2> /tmp/second-error
Then check /tmp/first-error and /tmp/second-error for errors.....
You may also want to simply post the contents of your rc.local for others to examine for
potential problems.
And alternative to this is to have this at the top of your rc.local file....
#!/bin/bash
exec 2> /tmp/rc.local.log # send stderr from rc.local to a log file
exec 1>&2 # send stdout to the same log file
set -x # tell sh to display commands before execution
And then check /tmp/rc.local.log
--
If you can't laugh at yourself, others will gladly oblige.
6:08 a.m.
On 10/28/14 17:18, Angelo Moreschini wrote:
After I read this announcement, I create the the file rc.local and I made it executable:
[angelo_dev@zorro rc.d]$ ls -l /etc/rc.d/rc.local
-rwxr-xr-x. 1 root root 1262 Oct 27 12:18 /etc/rc.d/rc.local
But, doing some tests, I saw that the scripts stored inside rc.local not run at boot,
...on my computer.
I don't believe you have determined that it is not getting run at boot time as opposed
to having a failure in the script itself.
As I've mentioned in a previous thread.... You should have this at the top of your
rc.local
#!/bin/bash
/bin/touch /tmp/hello
Then after boot check that there is a file in /tmp with the name "hello".
If there is....the script is being run.
How many commands are in your script?
It may be helpful to direct standard error to a file for each command as it seems to be a
small script.
So do something like this.....
some command 2> /tmp/first-error
next command 2> /tmp/second-error
Then check /tmp/first-error and /tmp/second-error for errors.....
You may also want to simply post the contents of your rc.local for others to examine for
potential problems.
--
If you can't laugh at yourself, others will gladly oblige.
5:43 a.m.
On 10/28/14 17:22, Frank Murphy wrote:
On Tue, 28 Oct 2014 11:18:37 +0200
Angelo Moreschini <mrangelo.fedora(a)gmail.com> wrote:
> But, doing some tests, I saw that the scripts stored inside rc.local
> not run at boot, ...on my computer.
>
>
> I would like to have some advice concerning the way to manage tests,
> in order to understand because the content of rc.local is not
> executed at the start... and to obtain that scripts run at the boot
systemctl status rc-local.service
sytemctl enable rc-local.service (if disabled above)
There is no need to enable rc-local.service.
# This unit gets pulled automatically into multi-user.target by
# systemd-rc-local-generator if /etc/rc.d/rc.local is executable.
--
If you can't laugh at yourself, others will gladly oblige.
5:17 a.m.
On 28.10.2014 10:59, poma wrote:
On 28.10.2014 10:18, Angelo Moreschini wrote:
> I would say that this thread is the continuation of a my preceding thread :
>
> “selecting some kind of files using the resync command”
>
>
> There I got help in order to make the backup of some my critical files.
>
> Now I am able to backing up these files using a shell script from the line
> command.
>
> But I would like also that this backup runs automatically when the computer
> boots.
>
>
> I know that this task is performed by the rc.local file, in Linux.
:)
https://wiki.archlinux.org/index.php/Systemd_FAQ#How_can_I_make_a_script_...
Simple as that.
BTW
/etc/systemd/system/replaces-ancient-rc.local.service
[Unit]
Description=Replaces ancient /etc/rc.d/rc.local
[Service]
Type=oneshot
ExecStart=/usr/bin/my-script-1st
ExecStart=/usr/bin/my-script-2nd
ExecStart=/usr/bin/my-script-3rd
[Install]
WantedBy=multi-user.target
$ man 5 systemd.service
poma
4:59 a.m.
On 28.10.2014 10:18, Angelo Moreschini wrote:
I would say that this thread is the continuation of a my preceding
thread :
“selecting some kind of files using the resync command”
There I got help in order to make the backup of some my critical files.
Now I am able to backing up these files using a shell script from the line
command.
But I would like also that this backup runs automatically when the computer
boots.
I know that this task is performed by the rc.local file, in Linux.
:)
https://wiki.archlinux.org/index.php/Systemd_FAQ#How_can_I_make_a_script_...
Simple as that.
4:22 a.m.
On Tue, 28 Oct 2014 11:18:37 +0200
Angelo Moreschini <mrangelo.fedora(a)gmail.com> wrote:
But, doing some tests, I saw that the scripts stored inside
rc.local
not run at boot, ...on my computer.
I would like to have some advice concerning the way to manage tests,
in order to understand because the content of rc.local is not
executed at the start... and to obtain that scripts run at the boot
systemctl status rc-local.service
sytemctl enable rc-local.service (if disabled above)
___
Regards
Frank
8:07 p.m.
On 10/29/14 08:36, Joe Zeff wrote:
On 10/28/2014 04:18 PM, Ed Greshko wrote:
> Since /tmp/rc.local.log exists and contains
>
> + /home/angelo_dev/bin/syncronize-java_srcs.sh
>
> it is obvious that rc.local is being executed.
>
> If I were going to assume something I would assume the systemctl failure is related
to the failure in the syncronize-java_srcs.sh script.
My guess is that one of the scripts being called failed, causing rc.local to abort.
Maybe it would help to put a line like this just at the end of each script called:
Let me say this again.... rc.local *did not* abort. It exited and the last exit code was
that returned by syncronize-java_srcs.sh
echo "$FOO.sh completed" >> /temp/rc.local.log
If something in the script fails, the script doesn't complete and the line isn't
written in the log. Adding print statements to help debugging is a very old technique,
but it's helped me find out just where things went wrong many times over the decades.
What I've asked for from the OP will help *me* to determine what is failing when
"rsync" is being called.
If you want him to do something else....talk to him.
--
If you can't laugh at yourself, others will gladly oblige.
7:36 p.m.
On 10/28/2014 04:18 PM, Ed Greshko wrote:
Since /tmp/rc.local.log exists and contains
+ /home/angelo_dev/bin/syncronize-java_srcs.sh
it is obvious that rc.local is being executed.
If I were going to assume something I would assume the systemctl failure is related to
the failure in the syncronize-java_srcs.sh script.
My guess is that one of the scripts being called failed, causing
rc.local to abort. Maybe it would help to put a line like this just at
the end of each script called:
echo "$FOO.sh completed" >> /temp/rc.local.log
If something in the script fails, the script doesn't complete and the
line isn't written in the log. Adding print statements to help
debugging is a very old technique, but it's helped me find out just
where things went wrong many times over the decades.
6:51 p.m.
On 10/28/2014 05:09 PM, Joe Zeff wrote:
On 10/28/2014 04:00 PM, Ed Greshko wrote:
> rc.local is working just fine!!
Riddle me this, Ed: why does systemctl report that rc-local.service
failed?
If I might,
It was failing for me because the rc.local I created contained
commands that bash could not find. But that was easy to fix.
6:46 p.m.
On 10/29/14 07:21, Matthew Miller wrote:
On Wed, Oct 29, 2014 at 07:18:25AM +0800, Ed Greshko wrote:
>>> rc.local is working just fine!!
>> Riddle me this, Ed: why does systemctl report that rc-local.service failed?
> I don't know, and at this point I don't care.
> Since /tmp/rc.local.log exists and contains
> + /home/angelo_dev/bin/syncronize-java_srcs.sh
> it is obvious that rc.local is being executed.
> If I were going to assume something I would assume the systemctl failure is related
to the failure in the syncronize-java_srcs.sh script.
Parachuting into the thread here — this seems right. systemd will
report's rc-local's status as that of the exit code of the script. If
you want it to alway succeed, end it with
exit 0
(or just ':', although I think `exit 0` is more obvious.)
Yes, you are correct. Even though I don't care about it, I'm a sucker for
testing/proving theories.
I created an rc.local file that called a script in my home directory with a deliberate
failure. Both scripts recorded their actions in a file..... After boot....
rc-local.service - /etc/rc.d/rc.local Compatibility
Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static)
Active: failed (Result: exit-code) since Wed 2014-10-29 07:34:20 CST; 1min 2s ago
Process: 1217 ExecStart=/etc/rc.d/rc.local start (code=exited, status=2)
[egreshko@f20f ~]$ cat /tmp/rc.local.log
+ /home/egreshko/bin/run
[egreshko@f20f ~]$ cat /tmp/myscript.log
+ ls /home/egreshko/notreally
ls: cannot access /home/egreshko/notreally: No such file or directory
I'm guessing that in the OP's case where it was reported (code=exited, status=3)
that the 3 is the exit code of the rsync command and may indicate.....
3 Errors selecting input/output files, dirs
But since that is just an assumption, I would want to see the results of the rsync which
is why I suggested either moving the rsync into rc.local or putting the commands to create
a trace file in the syncronize-java_srcs.sh script.
--
If you can't laugh at yourself, others will gladly oblige.
6:21 p.m.
On Wed, Oct 29, 2014 at 07:18:25AM +0800, Ed Greshko wrote:
>> rc.local is working just fine!!
> Riddle me this, Ed: why does systemctl report that rc-local.service failed?
I don't know, and at this point I don't care.
Since /tmp/rc.local.log exists and contains
+ /home/angelo_dev/bin/syncronize-java_srcs.sh
it is obvious that rc.local is being executed.
If I were going to assume something I would assume the systemctl failure is related to
the failure in the syncronize-java_srcs.sh script.
Parachuting into the thread here — this seems right. systemd will
report's rc-local's status as that of the exit code of the script. If
you want it to alway succeed, end it with
exit 0
(or just ':', although I think `exit 0` is more obvious.)
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
6:18 p.m.
On 10/29/14 07:09, Joe Zeff wrote:
On 10/28/2014 04:00 PM, Ed Greshko wrote:
> rc.local is working just fine!!
Riddle me this, Ed: why does systemctl report that rc-local.service failed?
I don't know, and at this point I don't care.
Since /tmp/rc.local.log exists and contains
+ /home/angelo_dev/bin/syncronize-java_srcs.sh
it is obvious that rc.local is being executed.
If I were going to assume something I would assume the systemctl failure is related to the
failure in the syncronize-java_srcs.sh script.
--
If you can't laugh at yourself, others will gladly oblige.
5:44 p.m.
On 10/28/2014 03:27 PM, Ed Greshko wrote:
And we are talking about debugging the OP's case only. I'm
not going to get into a tangent discussion on what I want to see from him. If you want
something else from him, go ahead and request it.
If the OP's scripts create logs or text files, they can be used for
debugging the scripts. If they're supposed to but don't, that may be
significant. However, we know, now, that rc-local.service is failing,
but not why.
6 p.m.
On 10/29/14 06:44, Joe Zeff wrote:
On 10/28/2014 03:27 PM, Ed Greshko wrote:
> And we are talking about debugging the OP's case only. I'm not going to get
into a tangent discussion on what I want to see from him. If you want something else from
him, go ahead and request it.
If the OP's scripts create logs or text files, they can be used for debugging the
scripts. If they're supposed to but don't, that may be significant. However, we
know, now, that rc-local.service is failing, but not why.
*IF* the biggest word in the English language.
rc.local is working just fine!!
--
If you can't laugh at yourself, others will gladly oblige.
5:28 p.m.
On 10/29/14 03:42, Angelo Moreschini wrote:
I don't understand what you mean with : "Make your rc.local
contain...".
Do one of two things......
1. Put the rsync command in the rc.local file *not*
/home/angelo_dev/bin/syncronize-java_srcs.sh
OR
2. Keep /home/angelo_dev/bin/syncronize-java_srcs.sh in the rc.local file but *add*
#!/bin/bash
exec 2> /tmp/myscript.log # send stderr from rc.local to a log file
exec 1>&2 # send stdout to the same log file
set -x # tell sh to display commands before execution
to the start of /home/angelo_dev/bin/syncronize-java_srcs.sh so it will record what it
does.
--
If you can't laugh at yourself, others will gladly oblige.
5:27 p.m.
On 10/29/14 06:24, Joe Zeff wrote:
On 10/28/2014 03:20 PM, Ed Greshko wrote:
> Well, yes.... But for the purpose of debugging there is nothing to see
Yes and no. The script creates a text file containing certain lines from
/var/log/messages and I can check after boot to see when the file was created and
what's in it. Of course, that's not true of most scripts that you'd call this
way.
And we are talking about debugging the OP's case only. I'm not going to get into
a tangent discussion on what I want to see from him. If you want something else from him,
go ahead and request it.
--
If you can't laugh at yourself, others will gladly oblige.
5:24 p.m.
On 10/28/2014 03:20 PM, Ed Greshko wrote:
Well, yes.... But for the purpose of debugging there is nothing to
see
Yes and no. The script creates a text file containing certain lines
from /var/log/messages and I can check after boot to see when the file
was created and what's in it. Of course, that's not true of most
scripts that you'd call this way.
5:20 p.m.
On 10/29/14 03:33, Joe Zeff wrote:
On 10/28/2014 12:21 PM, Ed Greshko wrote:
> Right.... Because you have rc.local calling another script! Please don't do
that....
My rc.local does nothing but call another script, with a fully qualified path name and it
works just fine.
Well, yes.... But for the purpose of debugging there is nothing to see
--
If you can't laugh at yourself, others will gladly oblige.
2:42 p.m.
Hi Ed
I don't understand what you mean with : "Make your rc.local contain...".
On Tue, Oct 28, 2014 at 9:33 PM, Joe Zeff <joe(a)zeff.us> wrote:
On 10/28/2014 12:21 PM, Ed Greshko wrote:
> Right.... Because you have rc.local calling another script! Please
> don't do that....
>
My rc.local does nothing but call another script, with a fully qualified
path name and it works just fine.
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
2:21 p.m.
On 10/28/14 23:39, Angelo Moreschini wrote:
Hi Ed,
How I said you in the preceded thread,_the file hello was created (when I tried the first
time. I deleted it recently.)._
OK.... That tells you that rc.local is being executed.
Now I am send you the contents of the files .. :(but I am not able to
understand totally what you suggest me to do)
- - - - - - - - - - - - - - - - - - - - 1) the content of the file /ctc/rc./rc.local
--------------------------------------------------------------
#!/bin/bash
# this i the file /ctc/rc./rc.local
log # send stderr from rc.local to a log file exec 2> /tmp/rc.local.
exec 1>&2 # send stdout to the same log file
set -x # tell sh to display commands before execution
/home/angelo_dev/bin/syncronize-java_srcs.sh
- - - - - - - - - - - - - - - - - - - - 2) the content of the
file/home/angelo_dev/bin/syncronize-java_srcs.sh-------------------
#!/bin/bash
# this is the file /home/angelo_dev/bin/syncronize-java_srcs.sh
rsync -av --delete --include='*/' --include='*.java'
--include='*.form' --exclude='*' \
/home/programmers/java/PROJECTS_development/ \
/media/PRTZ-src_sync
(this script works if I launch it from line command)
- - - - - - - - - - - - - - - - - - - - 3) the content of the file /tmp/rc.local.log
-------------------------------------------------------------
[angelo_dev@zorro ~]$ vi /tmp/rc.local.log
+ /home/angelo_dev/bin/syncronize-java_srcs.sh
(I don't see nothing about the test...)
Right.... Because you have rc.local calling another script! Please don't do
that....
Make your rc.local contain....
#!/bin/bash
exec 2> /tmp/rc.local.log # send stderr from rc.local to a log file
exec 1>&2 # send stdout to the same log file
set -x # tell sh to display commands before
execution
rsync -av rest of the command.....
--
If you can't laugh at yourself, others will gladly oblige.
3:14 p.m.
On Fri, 31 Oct 2014 13:06:52 -0700
Joe Zeff wrote:
However, there is one thought: we're pretty sure that there's
something
about the rsync command that's failing. Have you considered directing
stderr to a file?
Yep, I'd definitely stick something like this neat the front:
exec > /var/log/rclocal.log 2>&1
set -x
Then you'd see the commands echoed and the output in the log file.
1:24 p.m.
On 10/28/2014 11:12 AM, Angelo Moreschini wrote:
[angelo_dev@zorro ~]$ *_systemctl status rc-local.service_*
rc-local.service - /etc/rc.d/rc.local Compatibility
Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static)
Active: failed (Result: exit-code) since Tue 2014-10-28 17:07:57
IST; 3h 2min ago
Process: 877 ExecStart=/etc/rc.d/rc.local start (code=exited, status=3)
OK, now we're getting somewhere. I use that service to preserve the
last readings from sensord because there was reason to think my mobo was
overheating. When I check the status, it includes this:
Active: active (exited)
Now, we have to find out why it's failing...
12:47 p.m.
On 10/28/2014 02:18 AM, Angelo Moreschini wrote:
I would like to have some advice concerning the way to manage tests,
in
order to understand because the content of rc.local is not executed at
the start... and to obtain that scripts run at the boot
Post the results of these commands:
ls -l /etc/rc.d/rc.local
systemctl status rc-local.service
3462
days inactive
3468
days old
62 comments
10 participants
participants (10)
-
Angelo Moreschini -
Bill Davidsen -
Ed Greshko -
Frank Murphy -
JD -
Joe Zeff -
Matthew Miller -
poma -
Rick Stevens -
Tom Horsley