Starting and stopping RAID doesn't work from Cron

[Patrick O'Callaghan]

I have a backup script (using Borgmatic) I run every night, where the
target is a RAID1 array connected by a USB dock. The dock is normally
off so the script turns it on, does the backup, then turns it off
again. This is the cron entry:

# cat /etc/cron.d/borgmatic 
# Run borgmatic every day at 3am

0 3 * * * root /usr/local/bin/dock up && /usr/bin/borgmatic ; /usr/local/bin/dock
down

The on/off script (see attached) works reliably when run from the
command line, but fails when run via cron. The journal shows the
following:

Jun 21 03:00:01 Bree CROND[25480]: (root) CMD (/usr/local/bin/dock up &&
/usr/bin/borgmatic ; /usr/local/bin/dock down)
Jun 21 03:00:01 Bree kernel: scsi 6:0:0:0: Direct-Access     ASMT     ASM1156-PM       0  
 PQ: 0 ANSI: 6
Jun 21 03:00:01 Bree kernel: sd 6:0:0:0: Attached scsi generic sg4 type 0
Jun 21 03:00:01 Bree kernel: sd 6:0:0:0: [sdd] 1953525168 512-byte logical blocks: (1.00
TB/932 GiB)
Jun 21 03:00:01 Bree kernel: sd 6:0:0:0: [sdd] 4096-byte physical blocks
Jun 21 03:00:01 Bree kernel: scsi 6:0:0:1: Direct-Access     ASMT     ASM1156-PM       0  
 PQ: 0 ANSI: 6
Jun 21 03:00:01 Bree kernel: sd 6:0:0:0: [sdd] Write Protect is off
Jun 21 03:00:01 Bree kernel: sd 6:0:0:0: [sdd] Mode Sense: 43 00 00 00
Jun 21 03:00:01 Bree kernel: sd 6:0:0:0: [sdd] Write cache: enabled, read cache: enabled,
doesn't support DPO or FUA
Jun 21 03:00:01 Bree kernel: sd 6:0:0:1: Attached scsi generic sg5 type 0
Jun 21 03:00:01 Bree kernel: sd 6:0:0:0: [sdd] Optimal transfer size 33553920 bytes not a
multiple of physical block size (4096 bytes)
Jun 21 03:00:01 Bree kernel: sd 6:0:0:1: [sde] 1953525168 512-byte logical blocks: (1.00
TB/932 GiB)
Jun 21 03:00:01 Bree kernel: sd 6:0:0:1: [sde] 4096-byte physical blocks
Jun 21 03:00:01 Bree kernel: sd 6:0:0:1: [sde] Write Protect is off
Jun 21 03:00:01 Bree kernel: sd 6:0:0:1: [sde] Mode Sense: 43 00 00 00
Jun 21 03:00:01 Bree kernel: sd 6:0:0:1: [sde] Write cache: enabled, read cache: enabled,
doesn't support DPO or FUA
Jun 21 03:00:01 Bree kernel: sd 6:0:0:1: [sde] Optimal transfer size 33553920 bytes not a
multiple of physical block size (4096 bytes)
Jun 21 03:00:06 Bree kernel: sd 6:0:0:0: [sdd] Attached SCSI disk
Jun 21 03:00:07 Bree kernel: sd 6:0:0:1: [sde] Attached SCSI disk
Jun 21 03:00:07 Bree udisksd[961]: Error reading sysfs attr
`/sys/devices/virtual/block/md127/md/degraded': Failed to open file
“/sys/devices/virtual/block/md127/md/degraded”: No such file or directory (g-file>
Jun 21 03:00:07 Bree kernel: md/raid1:md127: active with 2 out of 2 mirrors
Jun 21 03:00:07 Bree udisksd[961]: Error reading sysfs attr
`/sys/devices/virtual/block/md127/md/sync_action': Failed to open file
“/sys/devices/virtual/block/md127/md/sync_action”: No such file or directory (>
Jun 21 03:00:07 Bree udisksd[961]: Error reading sysfs attr
`/sys/devices/virtual/block/md127/md/sync_completed': Failed to open file
“/sys/devices/virtual/block/md127/md/sync_completed”: No such file or direc>
Jun 21 03:00:07 Bree udisksd[961]: Error reading sysfs attr
`/sys/devices/virtual/block/md127/md/degraded': Failed to open file
“/sys/devices/virtual/block/md127/md/degraded”: No such file or directory (g-file>
Jun 21 03:00:07 Bree udisksd[961]: Error reading sysfs attr
`/sys/devices/virtual/block/md127/md/sync_action': Failed to open file
“/sys/devices/virtual/block/md127/md/sync_action”: No such file or directory (>
Jun 21 03:00:07 Bree udisksd[961]: Error reading sysfs attr
`/sys/devices/virtual/block/md127/md/sync_completed': Failed to open file
“/sys/devices/virtual/block/md127/md/sync_completed”: No such file or direc>
Jun 21 03:00:07 Bree kernel: md127: detected capacity change from 0 to 1000069595136
Jun 21 03:00:07 Bree kernel:  md127: p1
Jun 21 03:00:07 Bree systemd[1]: Condition check resulted in Software RAID monitoring and
management being skipped.
Jun 21 03:00:07 Bree systemd[1]: Condition check resulted in Software RAID monitoring and
management being skipped.
Jun 21 03:00:31 Bree kernel: sd 6:0:0:0: [sdd] Synchronizing SCSI cache
Jun 21 03:00:31 Bree kernel: md/raid1:md127: Disk failure on sdd, disabling device.
<---------------------------------*
                             md/raid1:md127: Operation continuing on 1 devices.
Jun 21 03:00:31 Bree kernel: sd 6:0:0:1: [sde] Synchronizing SCSI cache
Jun 21 03:00:31 Bree udisksd[961]: Unable to resolve
/sys/devices/virtual/block/md127/md/dev-sde/block symlink
Jun 21 03:00:31 Bree udisksd[961]: Unable to resolve
/sys/devices/virtual/block/md127/md/dev-sdd/block symlink
Jun 21 03:00:31 Bree udisksd[961]: Unable to resolve
/sys/devices/virtual/block/md127/md/dev-sde/block symlink
Jun 21 03:00:31 Bree udisksd[961]: Unable to resolve
/sys/devices/virtual/block/md127/md/dev-sdd/block symlink
Jun 21 03:00:31 Bree kernel: md: super_written gets error=10
Jun 21 03:00:31 Bree kernel: md127: detected capacity change from 1000069595136 to 0
Jun 21 03:00:31 Bree kernel: md: md127 stopped.

The script's own log shows it timing out after 30 seconds. The marked
line never happens when the script is run directly. Neither do any of
the other error messages.

Any ideas?

poc

[Roger Heflin]

It would appear that the md stop is still running when you remove the disk.

So in both cases you run the exact same script but from cron it fails?

I would think you either need a loop validating that the md stopped or
just put a simple few second sleep delay between the md stop and the
disk stop.

On Sun, Jun 21, 2020 at 11:54 AM Patrick O'Callaghan
<pocallaghan(a)gmail.com&gt; wrote:
>
> I have a backup script (using Borgmatic) I run every night, where the
> target is a RAID1 array connected by a USB dock. The dock is normally
> off so the script turns it on, does the backup, then turns it off
> again. This is the cron entry:
>
> # cat /etc/cron.d/borgmatic
> # Run borgmatic every day at 3am
>
> 0 3 * * * root /usr/local/bin/dock up && /usr/bin/borgmatic ;
/usr/local/bin/dock down
>
> The on/off script (see attached) works reliably when run from the
> command line, but fails when run via cron. The journal shows the
> following:
>
> Jun 21 03:00:01 Bree CROND[25480]: (root) CMD (/usr/local/bin/dock up &&
/usr/bin/borgmatic ; /usr/local/bin/dock down)
> Jun 21 03:00:01 Bree kernel: scsi 6:0:0:0: Direct-Access     ASMT     ASM1156-PM     
 0    PQ: 0 ANSI: 6
> Jun 21 03:00:01 Bree kernel: sd 6:0:0:0: Attached scsi generic sg4 type 0
> Jun 21 03:00:01 Bree kernel: sd 6:0:0:0: [sdd] 1953525168 512-byte logical blocks:
(1.00 TB/932 GiB)
> Jun 21 03:00:01 Bree kernel: sd 6:0:0:0: [sdd] 4096-byte physical blocks
> Jun 21 03:00:01 Bree kernel: scsi 6:0:0:1: Direct-Access     ASMT     ASM1156-PM     
 0    PQ: 0 ANSI: 6
> Jun 21 03:00:01 Bree kernel: sd 6:0:0:0: [sdd] Write Protect is off
> Jun 21 03:00:01 Bree kernel: sd 6:0:0:0: [sdd] Mode Sense: 43 00 00 00
> Jun 21 03:00:01 Bree kernel: sd 6:0:0:0: [sdd] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
> Jun 21 03:00:01 Bree kernel: sd 6:0:0:1: Attached scsi generic sg5 type 0
> Jun 21 03:00:01 Bree kernel: sd 6:0:0:0: [sdd] Optimal transfer size 33553920 bytes
not a multiple of physical block size (4096 bytes)
> Jun 21 03:00:01 Bree kernel: sd 6:0:0:1: [sde] 1953525168 512-byte logical blocks:
(1.00 TB/932 GiB)
> Jun 21 03:00:01 Bree kernel: sd 6:0:0:1: [sde] 4096-byte physical blocks
> Jun 21 03:00:01 Bree kernel: sd 6:0:0:1: [sde] Write Protect is off
> Jun 21 03:00:01 Bree kernel: sd 6:0:0:1: [sde] Mode Sense: 43 00 00 00
> Jun 21 03:00:01 Bree kernel: sd 6:0:0:1: [sde] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
> Jun 21 03:00:01 Bree kernel: sd 6:0:0:1: [sde] Optimal transfer size 33553920 bytes
not a multiple of physical block size (4096 bytes)
> Jun 21 03:00:06 Bree kernel: sd 6:0:0:0: [sdd] Attached SCSI disk
> Jun 21 03:00:07 Bree kernel: sd 6:0:0:1: [sde] Attached SCSI disk
> Jun 21 03:00:07 Bree udisksd[961]: Error reading sysfs attr
`/sys/devices/virtual/block/md127/md/degraded': Failed to open file
“/sys/devices/virtual/block/md127/md/degraded”: No such file or directory (g-file>
> Jun 21 03:00:07 Bree kernel: md/raid1:md127: active with 2 out of 2 mirrors
> Jun 21 03:00:07 Bree udisksd[961]: Error reading sysfs attr
`/sys/devices/virtual/block/md127/md/sync_action': Failed to open file
“/sys/devices/virtual/block/md127/md/sync_action”: No such file or directory (>
> Jun 21 03:00:07 Bree udisksd[961]: Error reading sysfs attr
`/sys/devices/virtual/block/md127/md/sync_completed': Failed to open file
“/sys/devices/virtual/block/md127/md/sync_completed”: No such file or direc>
> Jun 21 03:00:07 Bree udisksd[961]: Error reading sysfs attr
`/sys/devices/virtual/block/md127/md/degraded': Failed to open file
“/sys/devices/virtual/block/md127/md/degraded”: No such file or directory (g-file>
> Jun 21 03:00:07 Bree udisksd[961]: Error reading sysfs attr
`/sys/devices/virtual/block/md127/md/sync_action': Failed to open file
“/sys/devices/virtual/block/md127/md/sync_action”: No such file or directory (>
> Jun 21 03:00:07 Bree udisksd[961]: Error reading sysfs attr
`/sys/devices/virtual/block/md127/md/sync_completed': Failed to open file
“/sys/devices/virtual/block/md127/md/sync_completed”: No such file or direc>
> Jun 21 03:00:07 Bree kernel: md127: detected capacity change from 0 to 1000069595136
> Jun 21 03:00:07 Bree kernel:  md127: p1
> Jun 21 03:00:07 Bree systemd[1]: Condition check resulted in Software RAID monitoring
and management being skipped.
> Jun 21 03:00:07 Bree systemd[1]: Condition check resulted in Software RAID monitoring
and management being skipped.
> Jun 21 03:00:31 Bree kernel: sd 6:0:0:0: [sdd] Synchronizing SCSI cache
> Jun 21 03:00:31 Bree kernel: md/raid1:md127: Disk failure on sdd, disabling device.
<---------------------------------*
>                              md/raid1:md127: Operation continuing on 1 devices.
> Jun 21 03:00:31 Bree kernel: sd 6:0:0:1: [sde] Synchronizing SCSI cache
> Jun 21 03:00:31 Bree udisksd[961]: Unable to resolve
/sys/devices/virtual/block/md127/md/dev-sde/block symlink
> Jun 21 03:00:31 Bree udisksd[961]: Unable to resolve
/sys/devices/virtual/block/md127/md/dev-sdd/block symlink
> Jun 21 03:00:31 Bree udisksd[961]: Unable to resolve
/sys/devices/virtual/block/md127/md/dev-sde/block symlink
> Jun 21 03:00:31 Bree udisksd[961]: Unable to resolve
/sys/devices/virtual/block/md127/md/dev-sdd/block symlink
> Jun 21 03:00:31 Bree kernel: md: super_written gets error=10
> Jun 21 03:00:31 Bree kernel: md127: detected capacity change from 1000069595136 to 0
> Jun 21 03:00:31 Bree kernel: md: md127 stopped.
>
> The script's own log shows it timing out after 30 seconds. The marked
> line never happens when the script is run directly. Neither do any of
> the other error messages.
>
> Any ideas?
>
> poc
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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/[e-mail]

[Patrick O'Callaghan]

On Sun, 2020-06-21 at 18:06 -0500, Roger Heflin wrote:
>  It would appear that the md stop is still running when you remove the
> disk.
>  
>  
>  
>  So in both cases you run the exact same script but from cron it fails? 
Yes.

>  I would think you either need a loop validating that the md stopped
> or
>  just put a simple few second sleep delay between the md stop and the
>  disk stop. 
I'll look at that (though I would think that when 'mdadm' returns it
means that md has in fact stopped), however the errors appear when
starting ('dock up'), not when stopping.

poc

[Roberto Ragusa]

On 2020-06-21 18:54, Patrick O'Callaghan wrote:
>  0 3 * * * root /usr/local/bin/dock up && /usr/bin/borgmatic ;
> /usr/local/bin/dock down 
I would suggest to avoid multiple commands on a cron entry,
better to have a simple /usr/local/bin/do_backup with the three commands inside.

There you can log with "date" commands the execution the starting of each of the
part

and probably discover that the up part is working fine

(md127: active with 2 out of 2 mirrors)

then the backup script is failing (or not starting) and the down part is having problems,

apparently shutting down disks while md is still active.
Cron jobs have often problems with missing env variables (e.g. simplified PATH)
,
those can also be fixed if you go the do_backup approach.

Regards.

-- 
    Roberto Ragusa    mail at robertoragusa.it

[Patrick O'Callaghan]

On Mon, 2020-06-22 at 18:35 +0200, Roberto Ragusa wrote:
>  On 2020-06-21 18:54, Patrick O'Callaghan wrote:
>  > 0 3 * * * root /usr/local/bin/dock up && /usr/bin/borgmatic ;
> /usr/local/bin/dock down
>  
>  I would suggest to avoid multiple commands on a cron entry,
>  better to have a simple /usr/local/bin/do_backup with the three commands inside.
>  
>  There you can log with "date" commands the execution the starting of each of
> the part
>  
>  and probably discover that the up part is working fine
>  
>  (md127: active with 2 out of 2 mirrors)
>  
>  then the backup script is failing (or not starting) and the down part is having problems,
I'll consider that, but the script itself is already logging its
actions.

>  apparently shutting down disks while md is still active.
>  Cron jobs have often problems with missing env variables (e.g. simplified PATH)
>  ,
>  those can also be fixed if you go the do_backup approach. 
The script is called with a full path, so I don't think that's it, but
I guess I'll try it anyway.

Thanks for the feedback.

poc

[Roger Heflin]

How are you mounting the filesystem? (I don't remember details from
the prior discussion)  Directly with /dev/mdXXX or are you using some
other link?  If you are using some other link then udev needs time to
get the original mdXXX creation event and then create other links
pointing to mdXXX.

And as someone else said, I would put it all in a single script and
call that single script and add dates and echo's of various sorts and
send both stderr and stdout to a log file.  I usually just appended to
the log file and then once in a while clear the file manually, but you
can also just overwrite.



On Tue, Jun 23, 2020 at 5:05 AM Patrick O'Callaghan
<pocallaghan(a)gmail.com&gt; wrote:
>
> On Mon, 2020-06-22 at 18:35 +0200, Roberto Ragusa wrote:
> > On 2020-06-21 18:54, Patrick O'Callaghan wrote:
> > > 0 3 * * * root /usr/local/bin/dock up && /usr/bin/borgmatic ;
/usr/local/bin/dock down
> >
> > I would suggest to avoid multiple commands on a cron entry,
> > better to have a simple /usr/local/bin/do_backup with the three commands
inside.
> >
> > There you can log with "date" commands the execution the starting of
each of the part
> >
> > and probably discover that the up part is working fine
> >
> > (md127: active with 2 out of 2 mirrors)
> >
> > then the backup script is failing (or not starting) and the down part is having
problems,
>
> I'll consider that, but the script itself is already logging its
> actions.
>
> > apparently shutting down disks while md is still active.
> > Cron jobs have often problems with missing env variables (e.g. simplified PATH)
> > ,
> > those can also be fixed if you go the do_backup approach.
>
> The script is called with a full path, so I don't think that's it, but
> I guess I'll try it anyway.
>
> Thanks for the feedback.
>
> poc
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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/[e-mail]

[Patrick O'Callaghan]

On Tue, 2020-06-23 at 06:12 -0500, Roger Heflin wrote:
>  How are you mounting the filesystem? (I don't remember details
> from
>  
>  the prior discussion)  Directly with /dev/mdXXX or are you using some
>  other link?  If you are using some other link then udev needs time to
>  get the original mdXXX creation event and then create other links
>  pointing to mdXXX.
>  
>  
>   
As I said earlier, it's being mounted via /etc/fstab thus:

UUID=6cb66da2-147a-4f3c-a513-36f6164ab581       /raid                   ext4   
rw,noauto,user  1 1

where the script does:

                up)     mounted && exit 0
                        echo "- - -" > $SCAN
                        echo -n "raid attempt: " >> $LOG
                        for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15; do        # Wait up
to 30 seconds
                                sleep 2
                                echo -n $i " " >> $LOG
                                raidon && break
                        done
                        raidon || (echo -n " failed:"; date; exit 2)           
# RAID timed out
                        (echo; echo -n "up:   "; date) >> $LOG
                        mount /raid > /dev/null 2>&1
                        mounted || (echo "mount failed"; exit 3)               
# Mount failed

and 'raidon' is defined as:

function raidon() {     # RAID drive is running
        if mdadm --query $RAID > /dev/null 2>&1 ; then
                return 0
        fi
        return 1
}

I'm assuming that once mdadm returns 0 the array is up and running. If
that's not the case, then it would explain the issue.

As can be seen, it's also doing a lot of logging. I can change it to
run everything as a single script, but I don't really see what
difference it will make. I'll report back on the results.

poc

[Doug H.]

On Tue, 2020-06-23 at 17:07 +0100, Patrick O'Callaghan wrote:
>  On Tue, 2020-06-23 at 06:12 -0500, Roger Heflin wrote:
>  > How are you mounting the filesystem? (I don't remember details from
>  > 
>  > the prior discussion)  Directly with /dev/mdXXX or are you using
>  > some
>  > other link?  If you are using some other link then udev needs time
>  > to
>  > get the original mdXXX creation event and then create other links
>  > pointing to mdXXX.
>  > 
>  > 
>  > 
>  
>  As I said earlier, it's being mounted via /etc/fstab thus:
>  
>  UUID=6cb66da2-147a-4f3c-a513-
>  36f6164ab581       /raid                   ext4    rw,noauto,user  1
>  1
>  
>  where the script does:
>  
>                  up)     mounted && exit 0
>                          echo "- - -" > $SCAN
>                          echo -n "raid attempt: " >> $LOG
>                          for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15;
>  do        # Wait up to 30 seconds
>                                  sleep 2
>                                  echo -n $i " " >> $LOG
>                                  raidon && break
>                          done
>                          raidon || (echo -n " failed:"; date; exit
>  2)            # RAID timed out
>                          (echo; echo -n "up:   "; date) >> $LOG
>                          mount /raid > /dev/null 2>&1
>                          mounted || (echo "mount failed"; exit
>  3)                # Mount failed
>  
>  and 'raidon' is defined as:
>  
>  function raidon() {     # RAID drive is running
>          if mdadm --query $RAID > /dev/null 2>&1 ; then
>                  return 0
>          fi
>          return 1
>  }
>  
>  I'm assuming that once mdadm returns 0 the array is up and running.  
Perhaps a simpler way to assure that it is running is to check a static
file that you place on the raid. If it is there then the raid is up. It
would show the file as long as it is running, even if it is degraded.

If you want to be sure that it is running non-degraded then maybe look
for "[UU]" in /proc/mdstat, assuming you just have a single RAID 1.


>  If
>  that's not the case, then it would explain the issue.
>  
>  As can be seen, it's also doing a lot of logging. I can change it to
>  run everything as a single script, but I don't really see what
>  difference it will make. I'll report back on the results.
>  
>  poc
>  _______________________________________________
>  users mailing list -- users(a)lists.fedoraproject.org
>  To unsubscribe send an email to users-leave(a)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/[e-mail] 
-- 
Doug H.

[Patrick O'Callaghan]

On Tue, 2020-06-23 at 09:23 -0700, Doug H. wrote:
>  > I'm assuming that once mdadm returns 0 the array is up and
> running. 
>  
>  
>  Perhaps a simpler way to assure that it is running is to check a static
>  
>  file that you place on the raid. If it is there then the raid is up. It
>  
>  would show the file as long as it is running, even if it is degraded.
>  
>  
>  
>  If you want to be sure that it is running non-degraded then maybe look
>  
>  for "[UU]" in /proc/mdstat, assuming you just have a single RAID 1. 
Interesting ideas, thanks.

poc

[Patrick O'Callaghan]

On Tue, 2020-06-23 at 09:23 -0700, Doug H. wrote:
>  > I'm assuming that once mdadm returns 0 the array is up and
> running. 
>  
>  
>  Perhaps a simpler way to assure that it is running is to check a static
>  file that you place on the raid. If it is there then the raid is up. It
>  would show the file as long as it is running, even if it is degraded. 
On second thoughts, that will only work if it's mounted, which happens
after I check that it's up.

Thanks anyway.

poc

[Roger Heflin]

The uuid= I believe requires a link that udev creates when the device
gets created and it scans it.  That link may or may not be done when
mdadm returns with 0 as that udev/link creating is not in the mdadm
code path.

So wait a second before you mount it.  In reality it will probably
happen much faster than 1sec.

I think the specific udev rule doing it is in
/lib/udev/rules.d/60-persistent-storage.rules and this happens after
udev processes the event when the device shows up.

the link will be in /dev/disk/by-uuid/ so if once the mdadm exists do
a ls -l against that dir and then sleep a second and do it again
something new will show up.

On Tue, Jun 23, 2020 at 11:45 AM Patrick O'Callaghan
<pocallaghan(a)gmail.com&gt; wrote:
>
> On Tue, 2020-06-23 at 09:23 -0700, Doug H. wrote:
> > > I'm assuming that once mdadm returns 0 the array is up and running.
> >
> >
> > Perhaps a simpler way to assure that it is running is to check a static
> > file that you place on the raid. If it is there then the raid is up. It
> > would show the file as long as it is running, even if it is degraded.
>
> On second thoughts, that will only work if it's mounted, which happens
> after I check that it's up.
>
> Thanks anyway.
>
> poc
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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/[e-mail]

[Patrick O'Callaghan]

On Tue, 2020-06-23 at 19:17 -0500, Roger Heflin wrote:
>  The uuid= I believe requires a link that udev creates when the
> device
>  gets created and it scans it.  That link may or may not be done when
>  mdadm returns with 0 as that udev/link creating is not in the mdadm
>  code path.
>  
>  
>  So wait a second before you mount it.  In reality it will probably
>  happen much faster than 1sec.
>  
>  
>  I think the specific udev rule doing it is in
>  /lib/udev/rules.d/60-persistent-storage.rules and this happens after
>  udev processes the event when the device shows up.
>  
>  the link will be in /dev/disk/by-uuid/ so if once the mdadm exists do
>  a ls -l against that dir and then sleep a second and do it again
>  something new will show up. 
The journal is showing errors from udisksd immediately after the dock
starts up from power-down, which may be because the mdadm check is
running before the /sys/devices/... files are populated. I've changed
the test to search for [UU] in /proc/mdstat to see if that works
better.

poc