unRAID Server Release 5.0-beta10 Available

[lovingHDTV]

I've noticed before as well.  I consider this a major bug as you don't realize that your data is not protected.  I try to remember to do this after the reboot, but just checked and have 3 weeks of unprotected pictures on my cache drive that are not protected.

 

Can we get this fixed?  At least a button that we can click to say "apply on reboot".

 

dave

 

After you reboot, but before you click on "Apply" type:

crontab -l

and post the output.   It could be that the mover is not even being scheduled in cron until you "apply" it.

 

Errrr .... crontab -l never shows the schedule for mover, because it lists the contents of /var/spool/cron/crontabs/root

 

The mover schedule is placed in /etc/cron.d/root ... from the logfile:

Aug 1 00:39:56 Tower login[9423]: ROOT LOGIN on '/dev/pts/0' from '10.2.1.15'
Aug 1 00:41:29 Tower emhttp: shcmd (77): crontab -c /etc/cron.d - <<< "# Generated mover schedule: 0 */2 * * * /usr/local/sbin/mover |& logger"

 

I will investigate the contents of /etc/cron.d next time my server is rebooted.

 

Just did a reboot. Nothing in the /etc/cron.d - empty.

 

As for crontab -l

 

root@Tower:~# crontab -l
# If you don't want the output of a cron job mailed to you, you have to direct
# any output to /dev/null.  We'll do this here since these jobs should run
# properly on a newly installed system, but if they don't the average newbie
# might get quite perplexed about getting strange mail every 5 minutes. :^)
#
# Run the hourly, daily, weekly, and monthly cron jobs.
# Jobs that need different timing may be entered into the crontab as before,
# but most really don't need greater granularity than this.  If the exact
# times of the hourly, daily, weekly, and monthly cron jobs do not suit your
# needs, feel free to adjust them.
#
# Run hourly cron jobs at 47 minutes after the hour:
47 * * * * /usr/bin/run-parts /etc/cron.hourly 1> /dev/null
#
# Run daily cron jobs at 4:40 every day:
40 4 * * * /usr/bin/run-parts /etc/cron.daily 1> /dev/null
#
# Run weekly cron jobs at 4:30 on the first day of the week:
30 4 * * 0 /usr/bin/run-parts /etc/cron.weekly 1> /dev/null
#
# Run monthly cron jobs at 4:20 on the first day of the month:
20 4 1 * * /usr/bin/run-parts /etc/cron.monthly 1> /dev/null
# check parity every Mon at 8 am:
0 8 * * 1 /root/mdcmd check NOCORRECT 1>/dev/null 2>&1
root@Tower:~#

 

Shawn

 

[local.bin]

 

I've read in some older threads about getting rsync running on unraid, making it an rsync server for other clients.

 

Do those hold true for getting rsync setup on v5 beta?

 

Thanks

[Joe L.]

 

I've read in some older threads about getting rsync running on unraid, making it an rsync server for other clients.

 

Do those hold true for getting rsync setup on v5 beta?

 

Thanks

nothing has changed with rsync, however, you will need to deal with setting the permissions on copied files as security on the 5.0 series is tightened a bit.

[Stokkes]

There seems to be a problem with AVAHI in beta10 (at least from what I can tell).

 

Upon starting Plex Media Server, it doesn't broadcast via avahi on the default daemon that is started with beta10. If I do an avahi-daemon -r (to reload services), it spits out an error.

 

If I force kill the built-in avahi process that starts with emhttp and restart it using avahi-daemon -D, then things start working properly (and Plex starts broadcasting).

 

Also, trying to do an avahi-daemon -c (to check to see if its running) doesn't return anything.

 

Something is definitely wonky..

[meoge]

My monthly parity check started this morning and is still running.  It's 37% done which seems really slow.  It usually finishes in 4 or 5 hours with the previous beta's.  I have 8.9TB in my array.  Has anyone else noticed the parity check taking longer than usual?

[BRiT]

My parity check took the same time as prior betas. Perhaps you should examine your syslog for errors.

[btlupin]

There seems to be a problem with AVAHI in beta10 (at least from what I can tell).

 

Upon starting Plex Media Server, it doesn't broadcast via avahi on the default daemon that is started with beta10. If I do an avahi-daemon -r (to reload services), it spits out an error.

 

If I force kill the built-in avahi process that starts with emhttp and restart it using avahi-daemon -D, then things start working properly (and Plex starts broadcasting).

 

Also, trying to do an avahi-daemon -c (to check to see if its running) doesn't return anything.

 

Something is definitely wonky..

 

Plex works fine for me running avahi in beta10.

 

Roland

[Nezil]

Plex is working fine for me too in this release.

 

I'll post a new walkthrough on how I set things up in either a new thread, or an existing one nice I've done a search to find out where's best.

 

I have already posted much of the information already on page 7 of this thread.

[speeding_ant]

Same here

[dimaestro]

Came home today to an unresponsive box.  5.0-beta10. Unable to connect to user shares, can connect to //tower/flash. Cannot connect via AFP (avahi). Can SSH into the box. Load average was 9, currently at 15 and climbing.

 

Load:

16:58:56 up 1 day,  3:22,  2 users,  load average: 17.00, 15.67, 11.98

 

CPU Usage:

 

Tasks: 104 total,   1 running, 100 sleeping,   0 stopped,   3 zombie

Cpu(s):  0.1%us,  0.1%sy,  0.0%ni, 94.7%id,  5.1%wa,  0.0%hi,  0.0%si,  0.0%st

Mem:   2064536k total,  1236184k used,   828352k free,    50488k buffers

Swap:        0k total,        0k used,        0k free,  1089844k cached

 

 

 

---syslog entry---

Aug  1 11:16:04 Warehouse13 kernel: sas: command 0xf136cf00, task 0xf136ea00, timed out: BLK_EH_NOT_HANDLED

------

 

I think this is the culprit here.

 

Running on:

Mobo: Super Micro X7SPA-h-o

SAS: SUPERMICRO AOC-SASLP-MV8

7 SAMSUNG EcoGreen F2 HD154U

2gb Crucial

 

.... Sadly this leads me to a question: After I upgraded to beta 10, I changed some stuff around on the NAS. is the super.dat file in beta 10 compatible with lower versions? I'd prefer to have a machine that is completely stable, and unable to take my time machine backups, then one I can't trust entirely.

 

----- after doing some digging I've come across a post here that refers to power for the drives. Considering I recently removed 3 drives- it is possible i have a poor power connector. I'll check them all.

 

----- edit ---- Reseated all connectors *and* removed an empty Port Multiplier cable. We'll see what happens.

syslog.zip

[Interstellar]

From a performance point of view, things seem to have improved.

 

Multiple AFP connections work much better.

 

Haven't moved my Mac Pro over to Lion yet but I will over the next few days!

 

Edit: To cache drive enabled shares speeds are still at 20Mb/sec

 

I will do another test tomorrow to compare to 5b9 speeds.

[meoge]

My parity check took the same time as prior betas. Perhaps you should examine your syslog for errors.

 

This is my syslog from when the parity check started this morning:

 

Aug  1 00:00:01 galactica kernel: mdcmd (85): check NOCORRECT (unRAID engine)

Aug  1 00:00:01 galactica kernel:  (Routine)

Aug  1 00:00:01 galactica kernel: md: recovery thread woken up ... (unRAID engine)

Aug  1 00:00:01 galactica kernel: md: recovery thread checking parity... (unRAID engine)

Aug  1 00:00:01 galactica kernel: md: using 1152k window, over a total of 1953514552 blocks. (unRAID engine)

Aug  1 00:00:11 galactica kernel: md: parity incorrect: 2824 (Errors)

Aug  1 00:19:21 galactica kernel: md: parity incorrect: 32831584 (Errors)

Aug  1 00:47:02 galactica sSMTP[8978]: Creating SSL connection to host

Aug  1 00:47:02 galactica sSMTP[8978]: SSL connection using RC4-SHA

Aug  1 00:47:05 galactica sSMTP[8978]: Sent mail for root@ (221 2.0.0 closing connection z18sm3119842ibf.35) uid=0 username=root outbytes=857

Aug  1 01:47:02 galactica sSMTP[6118]: Creating SSL connection to host

Aug  1 01:47:03 galactica sSMTP[6118]: SSL connection using RC4-SHA

Aug  1 01:47:05 galactica sSMTP[6118]: Sent mail for root@ (221 2.0.0 closing connection b6sm3151668ibg.31) uid=0 username=root outbytes=857

Aug  1 02:47:02 galactica sSMTP[323]: Creating SSL connection to host

Aug  1 02:47:02 galactica sSMTP[323]: SSL connection using RC4-SHA

Aug  1 02:47:05 galactica sSMTP[323]: Sent mail for root@ (221 2.0.0 closing connection o1sm93479icy.4) uid=0 username=root outbytes=1110

Aug  1 03:40:01 galactica logger: mover started

Aug  1 03:40:01 galactica logger: skipping */

Aug  1 03:40:01 galactica logger: mover finished

Aug  1 03:47:03 galactica sSMTP[27331]: Creating SSL connection to host

Aug  1 03:47:03 galactica sSMTP[27331]: SSL connection using RC4-SHA

Aug  1 03:47:07 galactica sSMTP[27331]: Sent mail for root@ (221 2.0.0 closing connection f14sm6454992icm.3) uid=0 username=root outbytes=857

Aug  1 04:47:03 galactica sSMTP[21457]: Creating SSL connection to host

Aug  1 04:47:03 galactica sSMTP[21457]: SSL connection using RC4-SHA

Aug  1 04:47:06 galactica sSMTP[21457]: Sent mail for root@ (221 2.0.0 closing connection h6sm6514137icy.1) uid=0 username=root outbytes=1110

Aug  1 05:47:02 galactica sSMTP[13853]: Creating SSL connection to host

Aug  1 05:47:02 galactica sSMTP[13853]: SSL connection using RC4-SHA

Aug  1 05:47:05 galactica sSMTP[13853]: Sent mail for root@ (221 2.0.0 closing connection v16sm3264458ibe.51) uid=0 username=root outbytes=1110

Aug  1 06:47:02 galactica sSMTP[7119]: Creating SSL connection to host

Aug  1 06:47:03 galactica sSMTP[7119]: SSL connection using RC4-SHA

Aug  1 06:47:06 galactica sSMTP[7119]: Sent mail for root@ (221 2.0.0 closing connection c2sm2130931ibd.56) uid=0 username=root outbytes=1110

Aug  1 07:47:02 galactica sSMTP[28744]: Creating SSL connection to host

Aug  1 07:47:02 galactica sSMTP[28744]: SSL connection using RC4-SHA

Aug  1 07:47:05 galactica sSMTP[28744]: Sent mail for root@ (221 2.0.0 closing connection b6sm3318270ibg.31) uid=0 username=root outbytes=857

Aug  1 08:19:04 galactica kernel: mdcmd (86): spindown 1 (Routine)

Aug  1 08:47:02 galactica sSMTP[11776]: Creating SSL connection to host

Aug  1 08:47:03 galactica sSMTP[11776]: SSL connection using RC4-SHA

Aug  1 08:47:08 galactica sSMTP[11776]: Sent mail for root@ (221 2.0.0 closing connection v16sm3345747ibf.25) uid=0 username=root outbytes=764

Aug  1 09:47:02 galactica sSMTP[29298]: Creating SSL connection to host

Aug  1 09:47:02 galactica sSMTP[29298]: SSL connection using RC4-SHA

Aug  1 09:47:05 galactica sSMTP[29298]: Sent mail for root@ (221 2.0.0 closing connection c2sm3376781ibd.39) uid=0 username=root outbytes=764

Aug  1 10:47:02 galactica sSMTP[8569]: Creating SSL connection to host

Aug  1 10:47:02 galactica sSMTP[8569]: SSL connection using RC4-SHA

Aug  1 10:47:05 galactica sSMTP[8569]: Sent mail for root@ (221 2.0.0 closing connection b6sm3405021ibg.14) uid=0 username=root outbytes=764

Aug  1 11:47:03 galactica sSMTP[18288]: Creating SSL connection to host

Aug  1 11:47:03 galactica sSMTP[18288]: SSL connection using RC4-SHA

Aug  1 11:47:06 galactica sSMTP[18288]: Sent mail for root@ (221 2.0.0 closing connection a10sm3432694iba.24) uid=0 username=root outbytes=764

Aug  1 12:47:02 galactica sSMTP[30729]: Creating SSL connection to host

Aug  1 12:47:02 galactica sSMTP[30729]: SSL connection using RC4-SHA

Aug  1 12:47:05 galactica sSMTP[30729]: Sent mail for root@ (221 2.0.0 closing connection 3sm3462429ibm.10) uid=0 username=root outbytes=764

Aug  1 13:47:03 galactica sSMTP[17254]: Creating SSL connection to host

Aug  1 13:47:03 galactica sSMTP[17254]: SSL connection using RC4-SHA

Aug  1 13:47:06 galactica sSMTP[17254]: Sent mail for root@ (221 2.0.0 closing connection m7sm3235838qct.17) uid=0 username=root outbytes=764

Aug  1 14:47:02 galactica sSMTP[6507]: Creating SSL connection to host

Aug  1 14:47:02 galactica sSMTP[6507]: SSL connection using RC4-SHA

Aug  1 14:47:06 galactica sSMTP[6507]: Sent mail for root@ (221 2.0.0 closing connection f14sm7054484icm.3) uid=0 username=root outbytes=764

Aug  1 15:47:02 galactica sSMTP[29859]: Creating SSL connection to host

Aug  1 15:47:02 galactica sSMTP[29859]: SSL connection using RC4-SHA

Aug  1 15:47:05 galactica sSMTP[29859]: Sent mail for root@ (221 2.0.0 closing connection uz2sm4008517icb.0) uid=0 username=root outbytes=764

Aug  1 16:47:03 galactica sSMTP[18606]: Creating SSL connection to host

Aug  1 16:47:03 galactica sSMTP[18606]: SSL connection using RC4-SHA

Aug  1 16:47:06 galactica sSMTP[18606]: Sent mail for root@ (221 2.0.0 closing connection c2sm3572151ibd.39) uid=0 username=root outbytes=764

Aug  1 17:47:02 galactica sSMTP[11949]: Creating SSL connection to host

Aug  1 17:47:02 galactica sSMTP[11949]: SSL connection using RC4-SHA

Aug  1 17:47:05 galactica sSMTP[11949]: Sent mail for root@ (221 2.0.0 closing connection v16sm3598246ibe.34) uid=0 username=root outbytes=764

Aug  1 18:47:03 galactica sSMTP[6654]: Creating SSL connection to host

Aug  1 18:47:03 galactica sSMTP[6654]: SSL connection using RC4-SHA

Aug  1 18:47:06 galactica sSMTP[6654]: Sent mail for root@ (221 2.0.0 closing connection fx7sm1027767ibb.36) uid=0 username=root outbytes=764

Aug  1 19:18:23 galactica kernel: mdcmd (87): spindown 4 (Routine)

Aug  1 19:47:02 galactica sSMTP[14863]: Creating SSL connection to host

Aug  1 19:47:02 galactica sSMTP[14863]: SSL connection using RC4-SHA

Aug  1 19:47:04 galactica sSMTP[14863]: Sent mail for root@ (221 2.0.0 closing connection o1sm1053559icy.16) uid=0 username=root outbytes=764

Aug  1 20:47:02 galactica sSMTP[22535]: Creating SSL connection to host

Aug  1 20:47:02 galactica sSMTP[22535]: SSL connection using RC4-SHA

Aug  1 20:47:05 galactica sSMTP[22535]: Sent mail for root@ (221 2.0.0 closing connection v3sm3691330ibh.33) uid=0 username=root outbytes=764

 

 

It's currently at 58.1% and a speed of 18,418 KB/sec.  I'm not sure what speed it normally moves at but I know it has never taken this long to check parity before.

[abeta]

I'm currently on unRaid 4.7. It's been working fine, but since I recently made a backup of all of my data, I figured I'd try the Beta 10.

 

I followed the instructions. Copied the bzroot and bzimage file over, deleted the config/passwd and config/smbpasswd files. I didn't have a config/shadow file to delete.

 

How long should it take to come up? With 4.7 it takes a minute or two (not long at all). I waited for 5.0Beta10 to come up and on the webpage, it looks like part of the new unRaid screen, but nothing is visible. It is like it is missing the graphics/images, etc.

 

I'm on Win7 64bit and IE9. I've tried Safari on the Mac, Firefox on both PC and Mac and it doesn't ever seem to come up. This is after waiting upwards of 30 minutes. I've copied the files over again, etc. Same thing.

 

I put the old config files and 4.7 system files and it comes up immediately for me. Am I missing something really basic in the upgrade instructions?

 

This is on Lime Tech's MD-1510 server.

 

[Joe L.]

I'm currently on unRaid 4.7. It's been working fine, but since I recently made a backup of all of my data, I figured I'd try the Beta 10.

 

I followed the instructions. Copied the bzroot and bzimage file over, deleted the config/passwd and config/smbpasswd files. I didn't have a config/shadow file to delete.

 

How long should it take to come up? With 4.7 it takes a minute or two (not long at all). I waited for 5.0Beta10 to come up and on the webpage, it looks like part of the new unRaid screen, but nothing is visible. It is like it is missing the graphics/images, etc.

 

I'm on Win7 64bit and IE9. I've tried Safari on the Mac, Firefox on both PC and Mac and it doesn't ever seem to come up. This is after waiting upwards of 30 minutes. I've copied the files over again, etc. Same thing.

 

I put the old config files and 4.7 system files and it comes up immediately for me. Am I missing something really basic in the upgrade instructions?

 

This is on Lime Tech's MD-1510 server.

 

Sounds like you have "php" loaded as an add-on. 

[savestheday]

So I'm fairly certain that all cron stuff is messed up.  I use simplefeatures and it's supposed to send me a status email every 3 hours.  It was doing this in beta 9 but I haven't gotten an email in a while.  My mover isn't working even if I "apply" it.  I move stuff manually now

[speeding_ant]

So I'm fairly certain that all cron stuff is messed up.  I use simplefeatures and it's supposed to send me a status email every 3 hours.  It was doing this in beta 9 but I haven't gotten an email in a while.  My mover isn't working even if I "apply" it.  I move stuff manually now

 

SimpleFeatures doesn't use cron   Something else is probably wrong there.

[abeta]

I'm currently on unRaid 4.7. It's been working fine, but since I recently made a backup of all of my data, I figured I'd try the Beta 10.

 

I followed the instructions. Copied the bzroot and bzimage file over, deleted the config/passwd and config/smbpasswd files. I didn't have a config/shadow file to delete.

 

How long should it take to come up? With 4.7 it takes a minute or two (not long at all). I waited for 5.0Beta10 to come up and on the webpage, it looks like part of the new unRaid screen, but nothing is visible. It is like it is missing the graphics/images, etc.

 

I'm on Win7 64bit and IE9. I've tried Safari on the Mac, Firefox on both PC and Mac and it doesn't ever seem to come up. This is after waiting upwards of 30 minutes. I've copied the files over again, etc. Same thing.

 

I put the old config files and 4.7 system files and it comes up immediately for me. Am I missing something really basic in the upgrade instructions?

 

This is on Lime Tech's MD-1510 server.

 

Sounds like you have "php" loaded as an add-on.   

 

Aye, I don't recall why I installed it . Any idea if  unmenu, airvideo, apcupsd or powerdown require it? Those are probably the only packages I can't live without at this point. If it does, I'll just sit on the sidelines and wait .

[timsutton]

I'm currently on unRaid 4.7. It's been working fine, but since I recently made a backup of all of my data, I figured I'd try the Beta 10.

 

I followed the instructions. Copied the bzroot and bzimage file over, deleted the config/passwd and config/smbpasswd files. I didn't have a config/shadow file to delete.

 

How long should it take to come up? With 4.7 it takes a minute or two (not long at all). I waited for 5.0Beta10 to come up and on the webpage, it looks like part of the new unRaid screen, but nothing is visible. It is like it is missing the graphics/images, etc.

 

I'm on Win7 64bit and IE9. I've tried Safari on the Mac, Firefox on both PC and Mac and it doesn't ever seem to come up. This is after waiting upwards of 30 minutes. I've copied the files over again, etc. Same thing.

 

I put the old config files and 4.7 system files and it comes up immediately for me. Am I missing something really basic in the upgrade instructions?

 

This is on Lime Tech's MD-1510 server.

 

Sounds like you have "php" loaded as an add-on.   

 

Okay, this php conflict gets posted several times for every beta release. Don't the docs say to disable *all* 3rd party extensions before attempting the upgrade?

[Joe L.]

I'm currently on unRaid 4.7. It's been working fine, but since I recently made a backup of all of my data, I figured I'd try the Beta 10.

 

I followed the instructions. Copied the bzroot and bzimage file over, deleted the config/passwd and config/smbpasswd files. I didn't have a config/shadow file to delete.

 

How long should it take to come up? With 4.7 it takes a minute or two (not long at all). I waited for 5.0Beta10 to come up and on the webpage, it looks like part of the new unRaid screen, but nothing is visible. It is like it is missing the graphics/images, etc.

 

I'm on Win7 64bit and IE9. I've tried Safari on the Mac, Firefox on both PC and Mac and it doesn't ever seem to come up. This is after waiting upwards of 30 minutes. I've copied the files over again, etc. Same thing.

 

I put the old config files and 4.7 system files and it comes up immediately for me. Am I missing something really basic in the upgrade instructions?

 

This is on Lime Tech's MD-1510 server.

 

Sounds like you have "php" loaded as an add-on.   

 

Aye, I don't recall why I installed it . Any idea if  unmenu, airvideo, apcupsd or powerdown require it? Those are probably the only packages I can't live without at this point. If it does, I'll just sit on the sidelines and wait .

You can fix it in about 30 seconds.  

 

See here:

http://lime-technology.com/forum/index.php?topic=10840.msg103297#msg103297

 

however, none of the packages you mentioned use "php"

[mrcsx]

My monthly parity check started this morning and is still running.  It's 37% done which seems really slow.  It usually finishes in 4 or 5 hours with the previous beta's.  I have 8.9TB in my array.  Has anyone else noticed the parity check taking longer than usual?

 

My parity check on my beta10 server ran at about 10 mb/second.  Way slower then last month before the upgrade.  I checked my syslog and nothing out of the ordinary.  Looks like its not just me!

[speeding_ant]

Parity sync on my server is very slow (intermittently). Haven't done parity check yet.

[sunnyville]

 

 

---syslog entry---

Aug  1 11:16:04 Warehouse13 kernel: sas: command 0xf136cf00, task 0xf136ea00, timed out: BLK_EH_NOT_HANDLED

 

 

I keep getting the exact same errors when hitting "execute mover script".

 

[sunnyville]

I am getting a bit frustrated with the mover script: I copy a file to my "Media" share (which goes to the cache drive). Disks 1 and 2 are full. When I hit execute mover script, the cache drive continuously tries to write to disk 1, although it is full, and never attempts to write to any other drives. Also, the cache drive seems to be empty again, although NO FILES were written to any disks! Additionally it is trying to move files that aren't even on the cache drive, such as this one, which I wrote to disk 1 over a year ago:

 

Aug 2 14:22:38 Tower logger: rsync: writefd_unbuffered failed to write 79 bytes to socket [Receiver]: Broken pipe (32)

Aug 2 14:22:38 Tower logger: rsync error: error in rsync protocol data stream (code 12) at io.c(1530) [Receiver=3.0.7]

Aug 2 14:22:38 Tower logger: ./Media/Filme/.AppleDouble/CHERI.iso

Aug 2 14:22:38 Tower logger: *** glibc detected *** rsync: free(): invalid next size (normal): 0x080cbfa0 ***

Aug 2 14:22:38 Tower logger: ======= Backtrace: =========

Aug 2 14:22:38 Tower logger: /lib/libc.so.6(+0x705aa)[0xb75ed5aa]

Aug 2 14:22:38 Tower logger: /lib/libc.so.6(+0x73503)[0xb75f0503]

Aug 2 14:22:38 Tower logger: /lib/libc.so.6(cfree+0x70)[0xb75f36b0]

Aug 2 14:22:38 Tower logger: rsync[0x807cd74]

Aug 2 14:22:38 Tower logger: rsync[0x807de60]

Aug 2 14:22:38 Tower logger: rsync[0x804f3aa]

Aug 2 14:22:38 Tower logger: rsync[0x8050b5f]

Aug 2 14:22:38 Tower logger: rsync[0x8051e56]

Aug 2 14:22:38 Tower logger: rsync[0x8065825]

Aug 2 14:22:38 Tower logger: rsync[0x80666ac]

Aug 2 14:22:38 Tower logger: /lib/libc.so.6(__libc_start_main+0xe6)[0xb7593b86]

Aug 2 14:22:38 Tower logger: rsync[0x804aad1]

Aug 2 14:22:38 Tower logger: ======= Memory map: ========

Aug 2 14:22:38 Tower logger: 08048000-0809d000 r-xp 00000000 00:01 1067 /usr/bin/rsync

Aug 2 14:22:38 Tower logger: 0809d000-080a1000 rw-p 00054000 00:01 1067 /usr/bin/rsync

Aug 2 14:22:38 Tower logger: 080a1000-080f3000 rw-p 00000000 00:00 0 [heap]

Aug 2 14:22:38 Tower logger: b7400000-b7421000 rw-p 00000000 00:00 0

Aug 2 14:22:38 Tower logger: b7421000-b7500000 ---p 00000000 00:00 0

Aug 2 14:22:38 Tower logger: b7518000-b7534000 r-xp 00000000 00:01 1531 /usr/lib/libgcc_s.so.1

Aug 2 14:22:38 Tower logger: b7534000-b7535000 rw-p 0001b000 00:01 1531 /usr/lib/libgcc_s.so.1

Aug 2 14:22:38 Tower logger: b7535000-b7578000 rw-p 00000000 00:00 0

Aug 2 14:22:38 Tower logger: b7578000-b757c000 r-xp 00000000 00:01 559 /lib/libattr.so.1.1.0

Aug 2 14:22:38 Tower logger: b757c000-b757d000 rw-p 00003000 00:01 559 /lib/libattr.so.1.1.0

Aug 2 14:22:38 Tower logger: b757d000-b76d9000 r-xp 00000000 00:01 820 /lib/libc-2.11.1.so

Aug 2 14:22:38 Tower logger: b76d9000-b76da000 ---p 0015c000 00:01 820 /lib/libc-2.11.1.so

Aug 2 14:22:38 Tower logger: b76da000-b76dc000 r--p 0015c000 00:01 820 /lib/libc-2.11.1.so

Aug 2 14:22:38 Tower logger: b76dc000-b76dd000 rw-p 0015e000 00:01 820 /lib/libc-2.11.1.so

Aug 2 14:22:38 Tower logger: b76dd000-b76e0000 rw-p 00000000 00:00 0

Aug 2 14:22:38 Tower logger: b76e0000-b76e6000 r-xp 00000000 00:01 770 /lib/libpopt.so.0.0.0

Aug 2 14:22:38 Tower logger: b76e6000-b76e7000 rw-p 00006000 00:01 770 /lib/libpopt.so.0.0.0

Aug 2 14:22:38 Tower logger: b76e7000-b76ed000 r-xp 00000000 00:01 823 /lib/libacl.so.1.1.0

Aug 2 14:22:38 Tower logger: b76ed000-b76ee000 rw-p 00005000 00:01 823 /lib/libacl.so.1.1.0

Aug 2 14:22:38 Tower logger: b76f2000-b76f3000 rw-p 00000000 00:00 0

Aug 2 14:22:38 Tower logger: b76f3000-b76f4000 r-xp 00000000 00:00 0 [vdso]

Aug 2 14:22:38 Tower logger: b76f4000-b7711000 r-xp 00000000 00:01 567 /lib/ld-2.11.1.so

Aug 2 14:22:38 Tower logger: b7711000-b7712000 r--p 0001d000 00:01 567 /lib/ld-2.11.1.so

Aug 2 14:22:38 Tower logger: b7712000-b7713000 rw-p 0001e000 00:01 567 /lib/ld-2.11.1.so

Aug 2 14:22:38 Tower logger: bfca2000-bfcc3000 rw-p 00000000 00:00 0 [stack]

Aug 2 14:22:38 Tower logger: find: `rsync' terminated by signal 6

Aug 2 14:22:38 Tower logger: rsync: writefd_unbuffered failed to write 79 bytes to socket [Receiver]: Broken pipe (32)

Aug 2 14:22:38 Tower logger: rsync error: error in rsync protocol data stream (code 12) at io.c(1530) [Receiver=3.0.7]

[PeterB]

The mover schedule is placed in /etc/cron.d/root ... from the logfile:

Aug 1 00:39:56 Tower login[9423]: ROOT LOGIN on '/dev/pts/0' from '10.2.1.15'
Aug 1 00:41:29 Tower emhttp: shcmd (77): crontab -c /etc/cron.d - <<< "# Generated mover schedule: 0 */2 * * * /usr/local/sbin/mover |& logger"

 

I will investigate the contents of /etc/cron.d next time my server is rebooted.

 

I can confirm that, after a reboot, /etc/cron.d is empty.

 

If 'Apply' is clicked in Mover Settings, then the file /etc/cron.d/root is created with the mover schedule in it.

 

This, clearly, has to be a bug.

[EddieA]

My monthly parity check started this morning and is still running.  It's 37% done which seems really slow.  It usually finishes in 4 or 5 hours with the previous beta's.  I have 8.9TB in my array.  Has anyone else noticed the parity check taking longer than usual?

 

My parity check on my beta10 server ran at about 10 mb/second.  Way slower then last month before the upgrade.  I checked my syslog and nothing out of the ordinary.  Looks like its not just me!

I didn't time mine to see what the speed actually was, but my "gut feel" said it was really slow.

 

Cheers.