setup takes a long time

setup takes a long time

[Fergus Daly]

The setup program does seem to take a long time, even when it just
means "update" and even when there's nothing to update. Here's what
happens in unattended mode:

C:\Users\User0044>D:\cyg\setup-x86.exe -L D:\cyg -R D:\consoleX -Wgqmn
Starting cygwin install, version 2.884
User has backup/restore rights
Current Directory: D:\cyg
Could not open service McShield for query, start and stop. McAfee may
not be installed, or we don't have access.
root: D:\consoleX system
Selected local directory: D:\cyg
Changing gid back to original
running: D:\consoleX\bin\dash.exe "/etc/postinstall/0p_000_autorebase.dash"
running: D:\consoleX\bin\dash.exe "/etc/postinstall/0p_texlive_prep.dash"
running: D:\consoleX\bin\dash.exe "/etc/postinstall/0p_update-info-dir.dash"
running: D:\consoleX\bin\bash.exe --norc --noprofile
"/etc/postinstall/zp_adwaita-icon-theme.sh"
running: D:\consoleX\bin\bash.exe --norc --noprofile
"/etc/postinstall/zp_desktop-file-utils.sh"
running: D:\consoleX\bin\bash.exe --norc --noprofile
"/etc/postinstall/zp_fontconfig_cache_1.sh"
running: D:\consoleX\bin\bash.exe --norc --noprofile
"/etc/postinstall/zp_glib2.0.sh"
running: D:\consoleX\bin\bash.exe --norc --noprofile
"/etc/postinstall/zp_hicolor-icon-theme.sh"
running: D:\consoleX\bin\bash.exe --norc --noprofile
"/etc/postinstall/zp_man-db.sh"
running: D:\consoleX\bin\bash.exe --norc --noprofile
"/etc/postinstall/zp_shared-mime-info.sh"
running: D:\consoleX\bin\dash.exe "/etc/postinstall/zp_texlive_finish.dash"
Changing gid to Administrators
Ending cygwin install

I can kind of see the point of autorebase and update-info-dir, but why
revisit texlive every time, and why all the zp stuff, every time? Why
does setup explore McShield and McAfee? Incidentally note the switch
-m. Without it, checking sha1sum's I guess provides some kind of
protection, but it's incredibly time-consuming and seems quite
unnecessarily to cover much more than the files downloaded, even the
entire resource? In the presumably very rare event of a broken
download, could the update not more simply just abort?

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: setup takes a long time

[Jon Turney]

On 31/01/2018 06:18, Fergus Daly wrote:
> The setup program does seem to take a long time, even when it just
> means "update" and even when there's nothing to update. Here's what
> happens in unattended mode:
> 
[...]

Try this with 'ts' from moreutils, e.g:

> $ ./setup-2.884.x86_64.exe --local-install '\\necker\download\cygwin-packages' --no-admin --upgrade-also --quiet-mode --mirror-mode --no-shortcuts | ts -i
> 00:00:00 Starting cygwin install, version 2.884
> 00:00:00 User has NO backup/restore rights
> 00:00:00 Current Directory: \\necker\download\cygwin-packages
> 00:00:00 Could not open Service control manager
> 00:00:00 root: C:\cygwin64 user
> 00:00:00 Selected local directory: \\necker\download\cygwin-packages
> 00:00:13 running: C:\cygwin64\bin\dash.exe "/etc/postinstall/0p_000_autorebase.dash"
> 00:01:40 running: C:\cygwin64\bin\dash.exe "/etc/postinstall/0p_texlive_prep.dash"
> 00:00:00 running: C:\cygwin64\bin\dash.exe "/etc/postinstall/0p_update-info-dir.dash"
> 00:00:03 running: C:\cygwin64\bin\bash.exe --norc --noprofile "/etc/postinstall/zp_adwaita-icon-theme.sh"
> 00:00:00 running: C:\cygwin64\bin\bash.exe --norc --noprofile "/etc/postinstall/zp_desktop-file-utils.sh"
> 00:00:00 running: C:\cygwin64\bin\bash.exe --norc --noprofile "/etc/postinstall/zp_fontconfig_cache_1.sh"
> 00:00:14 running: C:\cygwin64\bin\bash.exe --norc --noprofile "/etc/postinstall/zp_glib2.0.sh"
> 00:00:00 running: C:\cygwin64\bin\bash.exe --norc --noprofile "/etc/postinstall/zp_gnome-themes-standard.sh"
> 00:00:00 running: C:\cygwin64\bin\bash.exe --norc --noprofile "/etc/postinstall/zp_gnome-themes.sh"
> 00:00:00 running: C:\cygwin64\bin\bash.exe --norc --noprofile "/etc/postinstall/zp_hicolor-icon-theme.sh"
> 00:00:00 running: C:\cygwin64\bin\bash.exe --norc --noprofile "/etc/postinstall/zp_man-db.sh"
> 00:00:02 running: C:\cygwin64\bin\bash.exe --norc --noprofile "/etc/postinstall/zp_mate-icon-theme.sh"
> 00:00:00 running: C:\cygwin64\bin\bash.exe --norc --noprofile "/etc/postinstall/zp_mate-themes.sh"
> 00:00:00 running: C:\cygwin64\bin\bash.exe --norc --noprofile "/etc/postinstall/zp_shared-mime-info.sh"
> 00:00:00 running: C:\cygwin64\bin\dash.exe "/etc/postinstall/zp_texlive_finish.dash"
> 00:00:02 Ending cygwin install
> I can kind of see the point of autorebase and update-info-dir, but why
> revisit texlive every time, and why all the zp stuff, every time? Why

These tasks are supposed to identify when they have no work to do, and 
do nothing quickly.  It seems that is not always the case.

> does setup explore McShield and McAfee? Incidentally note the switch
> -m. Without it, checking sha1sum's I guess provides some kind of
> protection, but it's incredibly time-consuming and seems quite
> unnecessarily to cover much more than the files downloaded, even the
> entire resource? In the presumably very rare event of a broken
> download, could the update not more simply just abort?

--local-install could indeed use some improvement.

Note that the scan is also used to filter the list of packages, so 
(without --mirror-mode) we don't offer for installation packages we 
don't have the archive for...

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: setup takes a long time

[Fergus Daly]

>> $ ./setup-2.884.x86_64.exe --local-install '\\necker\download\cygwin-packages' --no-admin --upgrade-also --quiet-mode --mirror-mode --no-shortcuts | ts -i

Thank you, using ts is really illuminating.
As an incidental query:
I deduce from the look of the snip above that you update Cygwin from
within Cygwin?
I have always done so from within a DOS Command Prompt window,
believing your way to be fatally flawed.
Is your way (much more convenient) ALWAYS OK? What if cygwin1.dll is
itself being updated?
Fergus
PS Or maybe you are using Windows PowerShell or similar.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: setup takes a long time

[Achim Gratz]

Fergus Daly writes:
> As an incidental query:
> I deduce from the look of the snip above that you update Cygwin from
> within Cygwin?

You can update one Cygwin installation from another (distinct) Cygwin
installation.  You shouldn't do that from within the same Cygwin
installation unless you really know what you're doing.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: setup takes a long time

[Buchbinder, Barry (NIH/NIAID) [E]]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1067 bytes --]

Jon Turney sent the following at Wednesday, January 31, 2018 9:02 AM
>On 31/01/2018 06:18, Fergus Daly wrote: [...]
>>
>> The setup program does seem to take a long time, even when it just
>> means "update" and even when there's nothing to update.  Here's what
>> happens in unattended mode:
>
> These tasks are supposed to identify when they have no work to do, and
> do nothing quickly.  It seems that is not always the case.

Recently brought up:
https://cygwin.com/ml/cygwin/2018-01/msg00274.html

It seems that this behavior is by design.
https://cygwin.com/ml/cygwin/2018-01/msg00275.html

FWIW, I still wouldn't mind having a command line option that skips
rebase and postinstall scripts when nothing has been updated.

Thanks,

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.

\x03B‹KCB”\x1c›Ø›\x19[H\x1c™\^[ܝ\x1cΈ\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÜ\x1c›Ø›\x19[\Ëš\x1d^[[\x03B‘TNˆ\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÙ˜\KÃB‘^[ØÝ[Y[\x18]\x1a[ÛŽˆ\b\b\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÙ^[ØÜËš\x1d^[[\x03B•[œÝXœØÜšX™H\x1a[™›Îˆ\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÛ[\vÈÝ[œÝXœØÜšX™K\Ú[\^[\x19CBƒB

Re: setup takes a long time

[Brian Inglis]

On 2018-01-31 08:34, Buchbinder, Barry (NIH/NIAID) [E] wrote:
> Jon Turney sent the following at Wednesday, January 31, 2018 9:02 AM
>> On 31/01/2018 06:18, Fergus Daly wrote: [...]
>>>
>>> The setup program does seem to take a long time, even when it just
>>> means "update" and even when there's nothing to update.  Here's what
>>> happens in unattended mode:
>>
>> These tasks are supposed to identify when they have no work to do, and
>> do nothing quickly.  It seems that is not always the case.
> 
> Recently brought up:
> https://cygwin.com/ml/cygwin/2018-01/msg00274.html
> 
> It seems that this behavior is by design.
> https://cygwin.com/ml/cygwin/2018-01/msg00275.html
> 
> FWIW, I still wouldn't mind having a command line option that skips
> rebase and postinstall scripts when nothing has been updated.

Main reason for running setup when nothing has been updated is to (re)run rebase
and other scripts that may not have completed successfully the first time for
some reason.
An option to skip might be nice for scheduled unattended updates, like hitting
Cancel at the end; as would an option to have setup find and stop cygrunsrv
server processes before starting updates, then restart cygrunsrv server
processes before exiting.

They do accept patches to setup ;^>

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: setup takes a long time

[Achim Gratz]

Fergus Daly writes:
> The setup program does seem to take a long time, even when it just
> means "update" and even when there's nothing to update. Here's what
> happens in unattended mode:
[…]

Looks completely normal.  Some of the scripts do need to look at quite a
few files before deciding if there's real work to do, so a slow disk
(spinning rust or network) can introduce noticeable delays.  On an SSD
it should be done in well under a minute.  If not, you might need to
check the settings on your antivirus solution to be less aggressive with
read-ahead for things in the Cygwin directory.

> I can kind of see the point of autorebase and update-info-dir, but why
> revisit texlive every time, and why all the zp stuff, every time?

Because that's the way to make it work reliably even around corner cases
and nobody has come up with something better yet.

Now, if you look at /var/log/setup.log.full you might see something
interesting that might need fixing.  TeXLive in particular might have
picked up some settings that trigger re-generation of many or even all
formats each time you run the script (you can run it by hand and see
what it does).  Unless you are familiar with how the TeXLive
configuration manager works, your best bet is a complete re-installation
of all packages associated with TeXLive and then it should work as
intended again (i.e. do nothing unless something has changed).

> Why does setup explore McShield and McAfee?

Some time in the past it would otherwise fail to successfully install
Cygwin on systems that had this crapware installed.  It might be
possible to just remove that from setup now, I would personally be in
favor of it.

> Incidentally note the switch -m. Without it, checking sha1sum's I
> guess provides some kind of protection, but it's incredibly
> time-consuming and seems quite unnecessarily to cover much more than
> the files downloaded, even the entire resource?

That check is there for an entirely different reason that will hopefully
no longer be supported in the not-too-distant future.  When that happens
it can go away.

> In the presumably very rare event of a broken download, could the
> update not more simply just abort?

No, it really was there originally to pick up files that you want to
install, but have no entry in setup.ini for.  If you never create your
own packages or move files by hand in your mirror directory, you should
_always_ use the -m switch.  A broken download will be identified by a
wrong SHA512 checksum (or a missing file, as it were).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple