The good news is that the problem hasn't occurred the last 2 nights. I haven't had time to check if the backups didn't run though. It is possible that the database didn't change over the weekend and backups were skipped. Friday was a federal holiday. Now that people are back at work I'll be surprised if we don't hang tomorrow at ~5 am. Fingers crossed.
Tim Nevels wrote: > I’ve been following this thread and thought I’d post a comment. I too > was confused and thought the problem was happening on 4D Server and it > was running on a Mac with High Sierra. I think Miyako may have thought > that too. That’s why he talked about purge. FWIW, I manually ran purge on the client machine just in case it might help. > Since 4D Server is on Windows I don’t think it is a server problem > unless it is a network layer problem. I don’t recall what 4D version > you are running. But are you using the new network or “legacy” network > layer? I would try switching and see if that makes a difference. We're running 4D 15.4. Still using the legacy network layer. I don't read anything good about using the new layer, so I'll stay where we are. Unless this is a problem that is known and fixed in 15.5 I'm not going to take the time to test and upgrade. I'm basically dealing with this problem for them for free. I first asked here hoping someone more familiar with High Sierra might point to a known issue that is responsible. What is weird is that there is a correlation between the time the backup runs and the time that the client hangs. In 20+ years of working with 4D Server we haven't experienced that. Not in my recent memory at least. > There have been reports of certain versions of 4D having issues on > certain Mac models running High Sierra. Looks like you’ve run into one > of those situations. So what are your options? Where are those reports? What are the specific issues? This is why I originally asked here. Are there workarounds? > 1. Live with it. Obviously not really an option. It's not, but this incident and the time and expense we go through every time we have to do a major 4D upgrade just so that we can continue to keep using a legacy 4D application has the customer strongly considering dumping 4D after almost 23 years. The only reason they still use 4D is because the solution has served them well. > 2. Switch 4D versions and hope it is a bug that got fixed and a new > version solves the problem. Upgrading to 16 isn't an option at this time. See 1 above. > 3. It is a weird machine specific problem. Wipe the machine, > reinstall fresh High Sierra macOS and fresh 4D Remote version. > Maybe it fixes this machine problem. I've considered this as a last resort. This is a relatively new machine that was installed when we did our v15 upgrade. It only has one OS upgrade. Rebuilding the machine is a much larger job than one would expect as I have to install a bunch of additional software to be compliant with institutional cybersecurity requirements, reconfigure 3 Apache virtual hosts on top of setting up client and all of the scripts I have in place to run client 24/7/365. It is an 8-12 hour job at a minimum and would have to be done over a weekend. > 4. Work around the problem. Which is basically what I've done for 25 years of 4D development including 4D web serving on client since 95. My workarounds have been to rely on external tools that monitor 4D and keep it running. The problem now is that those tools fail. They've been in place since we moved our Mac clients to OS X (2004?). I've had to modify them over time, but they've always worked. > Write an AppleScript that you launch just before the backup starts. > Use LEP to do this. Then QUIT 4D. The script will pause for enough > time for the backup to complete. Maybe 5 minutes or whatever it is for > your situation. Then the script launches 4D Remote again and > reconnects automatically to 4D Server. The script quits. I already have an Applescript that will restart 4D client if not running. It relies on launchd though. It runs 24/7. I would need to modify the structure and run a process that will quit the client before the backup runs. I'll also have to modify all of my keep alive scripts to be aware of the backup 'window' so that they don't run during that time. I'd prefer to not have to do this unless absolutely necessary. > If you can’t fix a problem, just avoid it and work around it. Would > this be an option? As mentioned we already do to some extent, but in this case I'd like to solve the problem. Right now the workaround is to manually reboot the client each morning. We support a global user base and even in the US I have east coast web users whose day starts 3 hours earlier than mine so we've got cases now where people can't use the system. I've actually been getting up early to check on and fix the problem the past few weeks. I can't keep doing that. --- Also, I saw Jim Crate's suggestion to have a script take a screen shot. I'd already considered that. The problem is that during times when the client was down and not rebooting via scripts, I've logged in remotely and been unable to see the actual 4D message because it has been behind the system dialog that "4D has unexpectedly quit". Whenever I try to move, or dismiss, that dialog to see the actual 4D message it dissappears before I can read the error message. Thanks, Brad ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
