Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

2 Neutral

About minidomo

  • Rank

Profile Information

  • Gender
  • Location
    South Bend, Indiana

Recent Profile Visitors

360 profile views
  1. minidomo

    repetitive SIGSEGV error

    Thanks, Nigel! I used the sudo commands you listed and the SIGSEGV error immediately stopped showing up in the Mac's console log. Now that I have a meaningful system log again, I can go back to researching my non-Retrospect related issue.
  2. minidomo

    repetitive SIGSEGV error

    I figured it had something do with Instant Scan although I wasn't sure what. I had gone into the Retrospect control panel and confirmed that Instant Scan was disabled on this computer itself (screenshot attached). Thanks to your reply, I looked up that page reference and disabled Instant Scan on our five clients as well but I'm still seeing this message show up in the macOS Console log (apologies for the confusion). Funny thing is that I hadn't looked at Retrospect's log at all (stupid, stupid, stupid). I'm not exactly seeing a corresponding error there but I am seeing another error that pops up randomly for no apparently reason, often in little clusters -- might be related? [*] UGetDriveType: ioQuery.Open /Volumes/com.apple.TimeMachine.localsnapshots/Backups.backupdb/PJJ4/2019-06-01-004304/Kitchen failed; devicePath com.apple.TimeMachine.2019-06-01-004304@/dev/disk1s1, file system apfs, osErr -35 [*] UGetDriveType: ioQuery.Open /Volumes/com.apple.TimeMachine.localsnapshots/Backups.backupdb/PJJ4/2019-06-01-014136/Kitchen failed; devicePath com.apple.TimeMachine.2019-06-01-014136@/dev/disk1s1, file system apfs, osErr -35 The funny thing about it is that there's no reason Retrospect should even be looking at this location. This Mac mini acts as the office's server (although it's not actually running macOS Server - we just use plain file sharing since it's a very small office). I've considered switching over to macOS Server to deal with some unrelated issues but haven't run macOS Server before so I'd have to learn more about it before doing that. Anyway, this is getting away from the issue at hand. This Mac "server" has three permanent volumes: Kitchen - the boot drive (the Retrospect apps runs on this volume too) Stove - a USB external drive where data is stored Fridge - a USB external Time Machine drive There are a trio of rotating USB external drives that are used as backup volume targets but those change every week.As you can see in the error message, it's pointing to the Time Machine snapshot folder. If I do ls -lah at a Terminal prompt, I can see this hidden volume exists: drwxr-xr-x@ 7 root wheel 224B Jun 2 13:41 . drwxr-xr-x@ 30 root wheel 960B May 19 00:12 .. drwxrwxr-x@ 29 pjjstaff staff 1.0K Jun 2 14:14 BackupB drwxrwxr-x 5 root wheel 442B Jun 2 13:41 Fridge lrwxr-xr-x 1 root wheel 1B Jun 1 01:25 Kitchen -> / drwxrwxr-x@ 10 pjjstaff staff 408B Jun 3 2018 Stove drwxr-xr-x+ 3 root wheel 96B Feb 27 2018 com.apple.TimeMachine.localsnapshots Not sure why Retrospect is even trying to scan this volume. There are only two folders on Kitchen that I have Retrospect backup at all, and these are in the current user's home folder. Retrospect doesn't target anything on Fridge (the Time Machine drive) at all. I had considered upgrading to Retrospect 16 but, after reviewing the feature list, nothing earth-shattering jumped out at me. Retrospect 15 supports macOS 10.14 so this should be a compatible combination. Still, if there's a compatibility problem that I can solve by upgrading to Retrospect 16, I'll do it -- I'm just not seeing evidence of that yet.
  3. I've got a Mac mini (Late 2014) running macOS 10.14.5 and Retrospect Single Server While looking through the Console log, I find that most of it is filled with this repeating error: Jun 1 01:11:09 PJJ4 com.apple.xpc.launchd[1] (com.retrospect.retroisa): Service only ran for 0 seconds. Pushing respawn out by 10 seconds. Jun 1 01:11:19 PJJ4 com.apple.xpc.launchd[1] (com.retrospect.retroisa[13266]): Service exited due to SIGSEGV | sent by exc handler[13266] Jun 1 01:11:19 PJJ4 com.apple.xpc.launchd[1] (com.retrospect.retroisa): Service only ran for 0 seconds. Pushing respawn out by 10 seconds. Jun 1 01:11:29 PJJ4 com.apple.xpc.launchd[1] (com.retrospect.retroisa[13267]): Service exited due to SIGSEGV | sent by exc handler[13267] Jun 1 01:11:29 PJJ4 com.apple.xpc.launchd[1] (com.retrospect.retroisa): Service only ran for 0 seconds. Pushing respawn out by 10 seconds. Jun 1 01:11:39 PJJ4 com.apple.xpc.launchd[1] (com.retrospect.retroisa[13268]): Service exited due to SIGSEGV | sent by exc handler[13268] Retrospect seems to be working but the Console log is so filled with this error that it basically obscures any other useful information. Any idea on how I can fix it?
  4. I’ve recently replaced a pretty old Mac mini that was has been acting as a “file server” (just using OS X 10.6 file sharing to service a 4-person office). The new station is also a Mac mini (Late 2014, 16G RAM, OS X 10.10.1) running Retrospect Single Server 11.5.2 (104). I am not running OS X Server — at least, not yet. Still just using the integrated file sharing. Although I am using Retrospect 11.5.2 on several other Macs at another office, all of those are running OS X 10.9.5. This is the only station where I’ve got Retrospect running under OS X 10.10. And I’m running into a situation where Retrospect stops responding under two specific situations: * I have 3 rotating external hard drives where backups are stored. These are all disk-based media sets, one recycled set for each day of the week. Although I am still using the same physical drives, I used to backup into seven individual file-based media sets, but have opted for the disk-based sets instead because I can limit them to only using no more than 10% of the backup drive. So I would create the first set (Week1-1) and that would work fine. But when I would attempt to create Week1-2, the “add” window would just barely start to roll up after clicking “add”, and then Retrospect would appear to hang. I examined the Console log and found this error repeated over and over again: 12/17/14 1:43:30.223 AM WindowServer[148]: WSGetSurfaceInWindow : Invalid surface 573498759 for window 169 Strangely enough, I made a guess that it was something about redrawing the window, so I switched Retrospect to running in full screen mode and this circumvented the problem. Very weird, but it worked. * The other problem I had involved enabling media sets within a backup script. I have the first week’s script done, so it has 7 media sets (Week1-1, Week1-2, etc.) and 7 schedules (one recycle script per night with a 3-week repeat). Now I clone that script to make the Week2 script. First thing I do is go into the Media Sets tab and want to click to enable all the Week2-x sets before I go to the Schedules tab to use them as new targets. I can click the first one but clicking the second set causes Retrospect to hang, and I have to force-quit the app. Looking at the Console log, I see messages such as these: 12/17/14 12:06:56.000 PM kernel[0]: process RetroEngine[26] thread 339831 caught burning CPU! It used more than 50% CPU (Actual recent usage: 78%) over 180 seconds. thread lifetime cpu usage 90.122123 seconds, (78.577832 user, 11.544291 system) ledger info: balance: 90005809303 credit: 90005809303 debit: 0 limit: 90000000000 (50%) period: 180000000000 time since last refill (ns): 114159505629 12/17/14 2:06:56.590 AM spindump[427]: Saved wakeups_resource.diag report for RetroISA version ??? (???) to /Library/Logs/DiagnosticReports/RetroISA_2014-12-17-020656_PJJ2.wakeups_resource.diag 12/17/14 2:06:55.000 AM kernel[0]: process RetroISA[53] caught causing excessive wakeups. Observed wakeups rate (per sec): 177; Maximum permitted wakeups rate (per sec): 150; Observation period: 300 seconds; Task lifetime number of wakeups: 45032 I did develop a workaround, which was this: 1. Enable 1 additional script — for sake of example, we’ll start with Week2-7. 2. Switch to the schedule tab and adjust the event that used Week1-7 to use Week2-7, then set the schedule for the proper date and time. 3. Commit the changes to the script. 4. Quit Retrospect. 5. Launch Retrospect. 6. Select script for Week2 and disable media set Week1-7 (since it is no longer being used by any schedule in this script). 7. Return to step 1 but enable media set Week2-6 this time, and repeat forward for all remaining events. So both of those workarounds did fix my problems, but obviously there’s some underlying issue(s) here.
  5. I have about a dozen network clients that get backed up to a single machine dedicated to nothing else but running Retrospect. This system is running 32-bit Windows 7 Pro (Service Pack 1), 4G RAM, all latest Windows updates. All the machines on my network get a nightly backup into their own individual .RBF backup file, and then once those are all completed Retrospect copies those onto one of three external drives that I rotate from week to week. The clients on my network are all Windows 7 Pro (some 32-bit, some 64-bit), running the latest 8.5 client. One station in particular seems to backup very slowly, although I think I might know why. Let's compare that system to another one on the network that has lower specs but yet backs up quicker. FYI -- both systems are connected to our network via gigabit Ethernet, so that factor is equalized. THE "GOOD" SYSTEM (should outperform the other system) Intel Quad-Core Xeon 2.26 GHz 6G RAM 64-bit operating system 3-years old THE "BAD" SYSTEM (should underperform in comparison to the "good" system) Intel Dual-Core 2.70 GHz 4G RAM 32-bit operating system 4-years old These systems are used by different people, so the collection of files on them is different. But my premise is that if, for example, both computers had exactly 1,000 files on them totaling 10G of data and they were backed up across the network to our Retrospect server, the "good" system should backup as fast or faster than the "bad" system, since the "good" system has superior specs. That said, here's last night's specs. "GOOD" SYSTEM 180,496 files totaling 23.5G 86.3 minutes to backup "BAD" SYSTEM 1,637 files totaling 20.2G 22.5 minutes to backup So the "good" system is taking like 3.8 times as long to backup, even though it has only about 16% more data (measured in gigabytes). It does have 110 times as many files though -- this station is used by a web developer, and he's got scads of really, really tiny code files. So my question is whether anything is wrong here or not. Even though they have similar amounts of data in gigabytes, the file count is very different. Does that explain why it takes so much longer to backup? Short of eliminating files, are there any settings I can tweak to improve performance? Thanks for your time.
  6. minidomo

    E-mail Notification Not Working in 8.2

    It's an Ubuntu 12.04 LTS server. I'm using SMTP authentication on port 587. But I don't think my server can be the issue, since it works with the "send test e-mail" function. The test email sent with that button gets through every time, on both Windows 8.2 and Mac 10.2. It's only ones sent after an automatic script runs that are not working.
  7. minidomo

    E-mail Notification Not Working in 8.1

    Retrospect released version 8.2 for Windows and 10.2 for Mac yesterday. At least for me, the problem is not fixed -- the "send test e-mail" button works but logs still fail to be sent during automatic executions. I've started a new thread to discuss the issue under the new version -- please add your feedback there if you are seeing this as well. Thanks. http://forums.retrospect.com/index.php?/topic/150572-e-mail-notification-not-working-in-82/
  8. The 8.2 release notes states one fix is "Improve compatibility with email servers when sending notification email". And it does, if you use the "Send Test E-Mail" button. But if you actually let an automatic script run, the notification still fails. Under Retrospect 8.2 for Windows, I get this in the log: E-mail notification failed: error -511 ( unknown service message) I also have a number of Retrospect 10.2 for Mac stations, which claim the same fix in the release notes and are still exhibiting the same problem, although the error message in the log is different there: E-mail notification failed: error -597 ( mail server not found) I've waited three months to get my email notification back, and I'm sorely disappointed. I really think a hotfix for this is due. There's nothing weird about my email setup -- in fact, since it works with the test button, I'd say my config is not the issue here. For sake of troubleshooting though, I'll say my outgoing mail server is entered as follows (not the real name): mail.outgoingserver.com:587 I have to use port 587 for outgoing mail, so I can't remove that. Not sure if the colon and/or the port number is the problem here. Whatever it is -- please get it fixed.
  9. minidomo

    E-mail Notification Not Working in 8.1

    This is ridiculous. It has been two months since this problem has been reported. TWO MONTHS. I don't know what priority Retrospect's engineers have assigned to this issue but whatever it is, IT IS TOO LOW. Every morning, I get backup logs from the three systems that I still have not upgraded to the latest version, and it reminds me that this problem is still unsolved. I have been holding out on those upgrades solely because of this issue, plus I have Retrospect upgrades I would recommend for other clients, but am holding on those as well until I can be assured I will get backup logs via email again. I still can't understand exactly how this issue was not discovered prior to release -- getting email notifications is a particularly important part of backup software. Please get this fixed, and get it fixed soon.
  10. minidomo

    E-mail Notification Not Working in 8.1

    I cannot change those settings, as they are required for use of that email account. However, for reasons unrelated to this (a domain change at our company), I'm switching all our Retrospect email notifications over to another email service anyway. I made some interesting discoveries while doing that. A screen grab of the new settings is attached -- we're using a GoDaddy-hosted email account for the new alerts. - All my Mac-based Retrospect 9.0.2 and 10.1 installs work with the new email settings - I have one Windows Server 2003 install running Retrospect Single Server 7.7.6, and it works fine with the new email settings - I have one Windows 7 Pro install running Retrospect 8.1, and it will not work with the new settings The SMTP service from GoDaddy will let you use ports 25, 80 or 3535 (without SSL). I've tried all three of these ports, and none of them will get a log sent out. If I leave no port specified, there is an obvious delay (cursor turns into a spinning wheel for several seconds), but still that does not get a test message sent to the recipient. I assume without a port specified, Retrospect is either trying port 25 or trying to use a list of common SMTP ports, but either way it still doesn't work.
  11. minidomo

    E-mail Notification Not Working in 8.1

    Here's a screen shot from one of my Mac 10.1 installs.
  12. minidomo

    E-mail Notification Not Working in 8.1

    Correction to my earlier post -- turns out I had not been paying proper attention to my Mac backup logs. Only some of our stations had been upgraded to 10.1 -- only our version 9 installs are still sending me backup logs. I checked the settings on some of our 10.1 stations and, if I try to send a test email, I get the message "invalid response from SMTP server (-592)". So this problem affects both Retrospect 8.1 for Windows and Retrospect 10.1 for Mac.\ I see a bug report has been created -- just wanted to add this tidbit to that issue. Thanks.
  13. minidomo

    E-mail Notification Not Working in 8.1

    We run both Mac and Windows versions of Retrospect here. All our Mac 10.1 installs seem to be doing fine with email notification, but the one Windows 8.1 install is not sending emails. It appears the backup is still running -- I'm just not getting any email confirmations. I can confirm that I am also seeing "Schannel" errors in the Windows logs as well. EMAIL PREFERENCES Backup server name: REGRETS From address: gutter@ourdomain.com To address: gutter@ourdomain.com Outgoing mail server: mail.ourdomain.com:26 (my outgoing server does require authentication; username and password are provided) SYSTEM CONFIGURATION Windows 7 Pro (32-bit) with Service Pack 1 4GB RAM Retrospect 8.1.0 (266) This same setup is working fine on the Mac 10.1 version of Retrospect. It produces one "Schannel" error for every scheduled event or manual test of the email notifications. Log Name: System Source: Schannel Date: 3/26/2013 12:42:14 AM Event ID: 36888 Task Category: None Level: Error Keywords: User: SYSTEM Computer: regrets1.kingdom.local Description: The following fatal alert was generated: 10. The internal error state is 10. Event Xml: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Schannel" Guid="{1F678132-5938-4686-9FDC-C8FF68F15C85}" /> <EventID>36888</EventID> <Version>0</Version> <Level>2</Level> <Task>0</Task> <Opcode>0</Opcode> <Keywords>0x8000000000000000</Keywords> <TimeCreated SystemTime="2013-03-26T04:42:14.202217200Z" /> <EventRecordID>3872111</EventRecordID> <Correlation /> <Execution ProcessID="540" ThreadID="2880" /> <Channel>System</Channel> <Computer>regrets1.kingdom.local</Computer> <Security UserID="S-1-5-18" /> </System> <EventData> <Data Name="AlertDesc">10</Data> <Data Name="ErrorState">10</Data> </EventData> </Event>
  14. One of my users today told me his computer was extremely slow to respond to commands. Without writing half a page of notes, I'm leaning to one of two causes: 1) a glitch in the Flash plug-in auto-update mechanism (seems most likely candidate) or 2) internal hard drive failure. I've reviewed the logs for that system -- only found one sign about a search function taking longer than normal, and no obvious read/write errors. But the slow operation, slow boot-up, slow shut-down are all signs I've seen before with systems trying to read/write and having problems doing so. After manually uninstalling the older version of Flash and installing the new version (and rebooting thereafter), all seems well. But, to me, the jury is still out as to whether that was the cause. This station is backed up remotely by another Windows station (Windows 7 Pro 32-bit running Retrospect 7.7.620). The client on this station is also current (7.7.114). It is backed up by duplicating the user's home folder from their computer to a local hard drive on the Retrospect computer. I reviewed recent log entries for this station, and saw the following log entries from yesterday. Today, I deleted all the contents of the target folder on the Retrospect computer and ran a full backup of the client with no errors. My question is -- do the errors in the log entries below imply hard drive failure at all? Just trying to see if there's any confirmation this user's hard drive is starting to fail. Thanks. + Duplicate using Smith at 9/19/2012 12:30 PM 9/19/2012 12:30:01 PM: Connected to Smith T-7: VssWBuildSnapshotSet: StartSnapshotSet failed, winerr -2147212522, error -3042 Can't use Open File Backup option for john on Smith, error -3042 ( there is already a Snapshot set in progress) To volume JohnSmith on CentralPlexus (Z:)... - 9/19/2012 12:30:01 PM: Copying john on Smith File "C:\Users\john\Documents\Outlook Files\JohnSmith.pst": can't read, error -1111 ( locked range conflict)
  15. So far, recreating sources using direct IP appears to have solved the problem. Thanks for the suggestion, Tim! Would still like to know if this is a bug likely to be fixed at some point or if I should always remember to use direct IP instead of multicast in the future -- so if anyone knows, please chip in. Thanks!