Your experience with udev matches mine. I'm not sure if it's just a really
complex process, or if it doesn't actually work the way it says it works,
but it seems that using it successfully rarely takes fewer than 19
attempts. And I don't believe that ``--reload`` works at all; I always
reboot to try a new rule. It's nice when it co-operates, but it takes a lot
of work to get there.
Best of luck with bacula.
On Sat, Jul 6, 2019 at 2:46 AM Angelo Moreschini <mrangelo.fed...@gmail.com>
wrote:
> Hi,
>
> although I did a lot of tests with many engagement I was not able to
> catch the UDEV event ....
> Having exhausted my trust ... I give up.
>
> I will not try bacula which (perhaps) is excessive for my purposes, and
> so I'll try with a simple script that uses the rsynk utility to copy the
> only files that I are in my interest.
> I have already successfully used this method, but that time I mounted
> permanently the HD USB to the computer via the file fstable ( this
> caused problems) but this time I will do otherwise :
> I'll simply mount and unmount the HD USB via the script .
> The only drawback (and it is not a serious inconvenience) will be the need
> to connect and disconnect the HD USB before that l'll launch the script
> during the time it is running.
>
> Thank you to all that tried to help me
>
> Angelo
>
> On Thu, Jul 4, 2019 at 9:02 PM Seth Kenlon <sken...@redhat.com> wrote:
>
>> You should be using the UUID of the partition to detect and mount your
>> target. Detecting the "whole" drive is immaterial, since you want udev to
>> mount a partition, not a drive.
>>
>> I would try to get one partition working first, then proceed to the
>> others. With udev testing, I've always had far more luck testing individual
>> tasks, one by one. Throw too much stuff at it, and you can't tell what's
>> not working: udev, your script, or you.
>>
>> On Thu, Jul 4, 2019 at 3:26 AM Angelo Moreschini <
>> mrangelo.fed...@gmail.com> wrote:
>>
>>> HI Seth,
>>>
>>> I'm sorry to still bother you ..., but your help could save me a lot of
>>> useless tests (since there are many parameters to manage and knowing what I
>>> really have to do could, this trigger me the use of useless ones).
>>>
>>>
>>> I think that I understood the crux of the problem ... (the UDEV theory
>>> …) but I still have a doubt that comes from the division of my HD into
>>> partitions (to how this particularity can influence my particular problem).
>>>
>>> *I would like exactly to know if UDEV reveals the existence of the
>>> entire HD USB, or if instead it detects only the individual existence of
>>> the three partitions that are mounted there ..*
>>>
>>>
>>> Because I read this.., I think that I could be able to check the real
>>> “work” of UDEV on my computer :
>>>
>>> *“Whenever you connect to the system, the kernel detects and initializes
>>> it, and directory with the device name is created under / sys / directory
>>> which stores the device attributes.”.*
>>>
>>> This could be a great help, but I couldn’t identify “this:
>>> sub-directory…., in the /sys directory, they are there many directories
>>> with many ramifications , how I can to identify the one in which they are
>>> stored the attributes of the device whose presence is detected by UDEV?
>>>
>>>
>>> Knowing if UDEV only reveals the existence of the (three) partitions
>>> and not the existence of the entire HD also has reflections on the
>>> script script that uses rsynk to carry out the bak-up.
>>>
>>> This is because (probably) I should write three scripts that use the
>>> utility rsync (one script for each partition) and not a single script
>>> that acts on the three different partitions.
>>>
>>>
>>> Thank you
>>>
>>> regards
>>>
>>>
>>> Angelo
>>>
>>>
>>> On Wed, Jul 3, 2019 at 12:40 AM Fred Smith <
>>> fre...@fcshome.stoneham.ma.us> wrote:
>>>
>>>> On Wed, Jul 03, 2019 at 07:16:17AM +1200, Seth Kenlon wrote:
>>>> > Using the UUID is correct.
>>>> >
>>>> > If the script isn't being executed by udev but you can confirm that
>>>> > udev is correctl mounting your target partition, and the shell script
>>>> > functions as expected when you run it manually, then I would create a
>>>> > simple timestamp shell script just to confirm that you can get a shell
>>>> > script to do *something* due to a udev event. The more complex the
>>>> > shell script, the more variables you have to debug, so simplify your
>>>> > shell script and work to just get a time stamp (or something) when a
>>>> > udev event occurs.
>>>>
>>>> I've done that by embedding echo commands into the script that
>>>> will put debugging statements a debug file that you can look
>>>> at after bootup.
>>>>
>>>> put one statement before anything else in the script and if you
>>>> don't get any debugoutput you'll know the script isn't being run.
>>>>
>>>> Fred
>>>> >
>>>> > On Tue, Jul 2, 2019 at 3:07 AM Angelo Moreschini
>>>> > <mrangelo.fed...@gmail.com> wrote:
>>>> > >
>>>> > > thank you Seth,
>>>> > >
>>>> > > I have no problems with the script executed at the UDEV event (if
>>>> this is the meaning you attribute to the term <UDEV script>).
>>>> > > I've already done this script that works, if run from a terminal.
>>>> > > If by the term <UDEV script> you mean something different, please
>>>> tell me.
>>>> > >
>>>> > >
>>>> > > The problem is that this script is not executed as a result of the
>>>> UDEV event.
>>>> > > - - - - - -
>>>> > > But maybe there is still something not clear for me that I can ask
>>>> you:
>>>> > > The HD (USB) that I am using, is divided into three partitions (in
>>>> order to keep the saved data separate):
>>>> > > = - = - = - = - = - =
>>>> > > the blkid command give this output ...:
>>>> > > / dev / sdc1: LABEL = "PRTZm_sys-admin" UUID = "1A5CEE7149E4BA81"
>>>> TYPE = "ntfs" PARTUUID = "0007fd62-01"
>>>> > > / dev / sdc2: LABEL = "PRTZm_data-common" UUID = "7FB1E3D91206DE1C"
>>>> TYPE = "ntfs" PARTUUID = "0007fd62-02"
>>>> > > / dev / sdc3: LABEL = "PRTZm_programming" UUID = "0A69FDE9688969D9"
>>>> TYPE = "ntfs" PARTUUID = "0007fd62-03"
>>>> > > = - = - = - = - = - =
>>>> > > so far, till now, I tried to reveal the montage of the HD without
>>>> taking into the account of partitions into which the USB HD is divided ..
>>>> > > But since the blkid command does not reveal its own UUID I am now
>>>> thinking that this could be the problem.
>>>> > >
>>>> > > IN CONCLUSION, since the USB is divided into partitions, ... will
>>>> the UDEV event reveal the presence of the entire HD (as the sole unit), or
>>>> will it instead reveal the presence of the three individual different
>>>> partitions?
>>>> > >
>>>> > > Still I would ask .... : this is a good syntax ?
>>>> ENV{ID_FS_UUID}=="1A5CEE7149E4BA81"
>>>> > > and still also, :-) ....
>>>> > > what I have to use the UUID number, or instead the PARTUUID number ?
>>>> > >
>>>> > > thank you very much
>>>> > > Angelo
>>>> > >
>>>> > > On Mon, Jul 1, 2019 at 2:00 PM Seth Kenlon <sken...@redhat.com>
>>>> wrote:
>>>> > >>
>>>> > >> Angelo,
>>>> > >> I agree with Tom's analysis, but my udev script accounts for it by
>>>> > >> mounting your drive with a very specific designator.
>>>> > >>
>>>> > >> Here is how I have tested this sort of thing before:
>>>> > >>
>>>> > >> 0. Get the UUID of your drive with blkid
>>>> > >> 1. Write a udev script to detect your drive by UUID when attached,
>>>> and
>>>> > >> to execute a test shell script (such as
>>>> /usr/local/bin/angelo-test.sh)
>>>> > >> when the drive is attached
>>>> > >> 2. Create the script /usr/local/bin/angelo-test.sh to do something
>>>> > >> very simle, like echo `date` >> /tmp/backup.log, and make it
>>>> > >> executable
>>>> > >> 3. Reboot
>>>> > >> 4. Attach your drive, and then look for the execution of your test
>>>> > >> script. If there was a /tmp/backup.log created with the correct
>>>> date
>>>> > >> and time in it.
>>>> > >> 5. Look in /media to ensure that your drive has been mounted as a
>>>> > >> unique and persistent entitiy.
>>>> > >>
>>>> > >> If it worked, then change the script to your real backup script.
>>>> > >> Continue to test.
>>>> > >>
>>>> > >> If it failed, review your udev script, use `udevadm monitor` to
>>>> > >> discover why your drive isn't triggering your script.
>>>> > >> _______________________________________________
>>>> > >> users mailing list -- users@lists.fedoraproject.org
>>>> > >> To unsubscribe send an email to
>>>> users-le...@lists.fedoraproject.org
>>>> > >> Fedora Code of Conduct:
>>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>>> > >> List Guidelines:
>>>> https://fedoraproject.org/wiki/Mailing_list_guidelines
>>>> > >> List Archives:
>>>> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
>>>> > >
>>>> > > _______________________________________________
>>>> > > users mailing list -- users@lists.fedoraproject.org
>>>> > > To unsubscribe send an email to users-le...@lists.fedoraproject.org
>>>> > > Fedora Code of Conduct:
>>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>>> > > List Guidelines:
>>>> https://fedoraproject.org/wiki/Mailing_list_guidelines
>>>> > > List Archives:
>>>> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
>>>> > _______________________________________________
>>>> > users mailing list -- users@lists.fedoraproject.org
>>>> > To unsubscribe send an email to users-le...@lists.fedoraproject.org
>>>> > Fedora Code of Conduct:
>>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>>> > List Guidelines:
>>>> https://fedoraproject.org/wiki/Mailing_list_guidelines
>>>> > List Archives:
>>>> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
>>>>
>>>> --
>>>> ---- Fred Smith -- fre...@fcshome.stoneham.ma.us
>>>> -----------------------------
>>>> "For him who is able to keep you from falling and to present you
>>>> before his
>>>> glorious presence without fault and with great joy--to the only God
>>>> our Savior
>>>> be glory, majesty, power and authority, through Jesus Christ our Lord,
>>>> before
>>>> all ages, now and forevermore! Amen."
>>>> ----------------------------- Jude 1:24,25 (niv)
>>>> -----------------------------
>>>> _______________________________________________
>>>> users mailing list -- users@lists.fedoraproject.org
>>>> To unsubscribe send an email to users-le...@lists.fedoraproject.org
>>>> Fedora Code of Conduct:
>>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>>> List Archives:
>>>> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
>>>>
>>> _______________________________________________
>>> users mailing list -- users@lists.fedoraproject.org
>>> To unsubscribe send an email to users-le...@lists.fedoraproject.org
>>> Fedora Code of Conduct:
>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives:
>>> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
>>>
>> _______________________________________________
>> users mailing list -- users@lists.fedoraproject.org
>> To unsubscribe send an email to users-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
>>
> _______________________________________________
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
>
_______________________________________________
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
