Thanks for the heads-up. You could use the "flag as out of date" button next time also. It's hard to notice when something goes out of date when I'm not looking to reinstall it regularly. It should be all set now.
Search Criteria
Package Details: raid-check-systemd 4.1-2
| Git Clone URL: | https://aur.archlinux.org/raid-check-systemd.git (read-only, click to copy) |
|---|---|
| Package Base: | raid-check-systemd |
| Description: | Raid data scrubbing script with systemd timer to be used with mdadm. |
| Upstream URL: | https://wiki.archlinux.org/index.php/RAID#Scrubbing |
| Keywords: | mdadm raid scrub systemd |
| Licenses: | |
| Conflicts: | |
| Submitter: | TheChickenMan |
| Maintainer: | TheChickenMan |
| Last Packager: | TheChickenMan |
| Votes: | 9 |
| Popularity: | 0.53 |
| First Submitted: | 2016-06-07 08:44 |
| Last Updated: | 2019-09-29 18:24 |
Dependencies (2)
Required by (0)
Sources (3)
TheChickenMan commented on 2018-05-16 22:09
jholmer commented on 2018-05-16 15:49
This is currently broken. The centos package needs a version bump:
_cent_rel=13
sha256sum='f4ba05c4a966ebfa90dc510cf4d67187dbd3666a50d2bd96942dfd3e57f89704'
TheChickenMan commented on 2017-09-19 10:38
Should be fixed now. Wish there was an easier way to know when the source for this stuff gets updated other than it not working for someone.
Ryblade commented on 2017-09-19 10:35
Gah, I've been all over the place with this one. Glad to see you're up as early as I am :). Thanks for getting on this.
TheChickenMan commented on 2017-09-19 10:26
Looks like they updated their source to
mdadm-4.0-5.el7.x86_64.rpm
TheChickenMan commented on 2017-09-01 11:27
You are supposed to use:
$ sudo systemctl enable raid-check.timer
morosa commented on 2017-09-01 11:17
I have that problem:
systemctl enable /usr/lib/systemd/system/raid-check.service
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
instance name specified.
TheChickenMan commented on 2017-05-02 09:51
Yes, it does say "started" again even though it's actually finished.
elimpfor commented on 2017-05-02 01:42
I just did a systemctl status raid-check.service and I get the following:
May 01 08:00:15 host1 systemd[1]: Starting raid-check...
May 01 08:42:21 host1 systemd[1]: Started raid-check.
I'm guessing it started at 08:00:15. Did it finish at 08:42:21 even though it says that it "started"?
TheChickenMan commented on 2017-04-30 19:00
You can view the status of the service while it is running in the kernel log with dmesg. You can also review status with the following:
$ systemctl status raid-check.service
$ systemctl status raid-check.timer
$ systemctl list-timers --all
Pinned Comments
TheChickenMan commented on 2017-04-30 19:00
You can view the status of the service while it is running in the kernel log with dmesg. You can also review status with the following:
$ systemctl status raid-check.service
$ systemctl status raid-check.timer
$ systemctl list-timers --all