Mail Archives: cygwin/2008/09/10/14:03:58
Dave Korn writes:
> Err, that should never happen, unless you're updating from a
> several-years-old DLL. The Cygwin DLL is intended to be backwardly
> compatible, and only rarely have their been ABI breaks. So this aspect of
> updating doesn't get tested very often.
>
Yes, I was testing an upgrade from a couple year old version: 1.5.12
> > I guess the obvious answer is to make sure NO cygwin related processes are
> > running when you run setup. But I was hoping it would just schedule the
> > files for replacement and do it on the next reboot.
>
> Well, yeh, it did do that. But there's no mechanism to schedule all the
> postinstall scripts to not be run until the next reboot, which IIUIC is what
> would be needed here for them not to crash.
I think the safest bet for me in this case is to just kill off everything and
run setup. Since I'll be doing this upgrade on close to 100 boxes, I've been
trying to devise a *relatively* unattended process.
In case it helps anyone in the future, here's a snippet of my cmd script I have
so far:
echo off
echo This will kill all cygwin related processes and update cygwin
echo Hit CTRL-C now to abort, otherwise:
pause
c:\cygwin\bin\bash.exe --login -c "ps -la|sed 's/^I/ /'|awk '{print $4}'|grep -
v WINPID >/tmp/pids.txt"
for /F %i in (c:\cygwin\tmp\pids.txt) DO taskkill /PID %i /F
del /F c:\cygwin\tmp\pids.txt
echo running setup...
\\fileserver\cygwin\setup-2.602.exe -q -L -l \\fileserver\cygwin -R C:\cygwin
echo Done
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -