Clueless! sshd ONLY fails at system startup (XP/SP3) -- FOLLOWUP
On 2017-05-25 23:21, Houder wrote: On 2017-05-25 17:36, Houder wrote: Hi, YES, I know, XP is NOT supported anymore ... However, I started out on XP ... and it has sshd running as a Window service, installed and configured (as approved by Corinna :-) ... some time ago I may have upgraded openssh over there (yes, I am now running W7) ... I cannot really remember. Yes, sometimes I visit (ssh) the "old station" (XP) for info that I am missing. (both machines are behind a firewall - rest assured) "Suddenly" (yesterday?) I noticed that the "sshd daemon" fails; it is started at system startup (i.e. an automatic service). Ahem ... it should have rephrased that ... however, from the error report in the sshd.log, it should be clear that the daemon fails as soon as it receives its first "ssh" request ... (and not before). Give me a break! Just now I decided to UNinstall the F-Secure anti-virus ... And guess what ...? Yes, NOW sshd replies again to requests after system startup! Now I wonder if I will find the same result on W7 when I install openssh. (yes, W7 also has F-Secure anti-virus installed). Anyone using F-Secure on W7 and operating the sshd? Henri -- 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: Clueless! sshd ONLY fails at system startup (XP/SP3) ...
On 2017-05-25 17:59, Andrey Repin wrote: Hi Andrey, [snip] When the service is restarted after system startup, i.c. cygrunsrv -E sshd; cygrunsrv -S sshd it then works flawlessly (which amazes me, given the error in the sshd.log) What if you `net start "Cygwin sshd"` ? You mean after system startup? It tells me that "the requested service has already been started." ... and sshd still fails when I approach it again. (yes, "net stop ...", followed by "net start ..." again does the trick) [snip] Any suggestions? (Yes, XP has F-Secure as anti-virus) The message in the sshd.log: Server listening on 0.0.0.0 port .^M # X = some port, but not 22 1 [main] sshd 3152 E:\Cygwin25\usr\sbin\sshd.exe: *** fatal error in forked process - fork: can't reserve memory for parent stack 0x3 - 0x23, (child has 0x4 - 0x24), Win32 error 487 395874 [main] sshd 3152 cygwin_exception::open_stackdumpfile: Dumping stack trace to sshd.exe.stackdump 3 [main] sshd 536 fork: child -1 - forked process 3152 died unexpectedly, retry 0, exit code 0x100, errno 11 fork: Resource temporarily unavailable^M [snip] Any "antivirus" running on that system? Yes ... as I wrote in the original post "F-Secure" has been installed, and yes, it may be the culprit ... (would have to UNinstall it, cannot switch it off temporarily). Did you try to fully rebase your installation? I did ... as instructed in /usr/share/doc/Cygwin/_autorebase.README - rebase-trigger fullrebase - shut down "Cygwin" (incuding: cygrunsrv -E sshd) - execute setup ... It did not help. But read the error report in the sshd.log again: it is not the "classical dll clash" (description by Michael Lemke :-), it is "something else" (related to the "lockstep" in which parent and child are forced by the cygwin dll when the fork syscall takes places, and yes, in those circumstance a dll clash may occur if the Cygwin dlls have not been properly rebased). As rebasing did not help, I tried some other things, but then decided, it would be far wiser to install the last valid version of Cygwin. However the result was the same ... Subsequently tried the peflags command ... reconfigured openssh in a different way (using cyg_server as the privileged account - although not required in XP) Did some things (that I cannot really remember now). Finally I decided I did not have a clue of what was going on (and of what I was doing). That is why I decided to post my problem. I am clueless. More so, as I can make sshd work by just restarting it ... Regards, Henri -- 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: [cygwin] v1.7
(I used to have a dadms account) Cygwin is open source, red hat has a paid support option. Your vendor support statement is not likely the best course of action. That being said, you may contact me directly or continue on list to help get the current version back in dadms. Ctr mail: jason.j.pyeron@mail.mil V/r, Jason pyeron - Original Message - From: Yamamoto, Anne B CIV PMRF N63 To: cygwin@cygwin.com Sent: Mon May 22 20:28:53 2017 Subject: [cygwin] v1.7 Aloha, We are currently using v1.7 but it is no longer DADMS supported. Would it be possible to get a vendor support statement email so that we may continue using this version? Thanks, Anne -- 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: bug in lrint [was: FW: Printing long int in C program under cygwin64]
On Thu, 25 May 2017 18:43:58, Steven Penny wrote:
Uh, have you actually tried this? It doesnt do anything:
$ cat alfa.c
#define __USE_MINGW_ANSI_STDIO 1
#include
int main() {
printf("%zi %zu %llu\n", __SIZE_MAX__, __SIZE_MAX__, __SIZE_MAX__);
}
$ x86_64-w64-mingw32-gcc -Wformat-signedness -o alfa alfa.c
Correcting myself: you need 2 flags to get this working:
$ x86_64-w64-mingw32-gcc -Wformat -Wformat-signedness alfa.c
alfa.c: In function ‘main’:
alfa.c:11:10: warning: format ‘%zi’ expects argument of type
‘signed size_t’, but argument 2 has type ‘long long unsigned int’
[-Wformat=]
printf("%zi %zu %llu\n", __SIZE_MAX__, __SIZE_MAX__, __SIZE_MAX__);
^
--
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: bug in lrint [was: FW: Printing long int in C program under cygwin64]
On Thu, 25 May 2017 13:17:30, Eric Blake wrote:
Correct. Newer gcc's -Wformat-signedness will flag the discrepency.
Uh, have you actually tried this? It doesnt do anything:
$ cat alfa.c
#define __USE_MINGW_ANSI_STDIO 1
#include
int main() {
printf("%zi %zu %llu\n", __SIZE_MAX__, __SIZE_MAX__, __SIZE_MAX__);
}
$ x86_64-w64-mingw32-gcc -Wformat-signedness -o alfa alfa.c
$ ./alfa
-1 18446744073709551615 18446744073709551615
--
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
System crontab with username containing a space
Hey folks :) Due to circumstances beyond my control, I've got a user account on a remote PC which contains a space in the username, i.e. "Test Computer". I've set up Cygwin and cron, and am having problems with the system crontab. I can't figure out how to put the username in there, I've tried it as is, with \ escaping the space, enclosing in double quotes. The jobs just don't get executed. There is no error message in cronevents. The jobs are implementation of cron.hourly, cron.daily etc. - I really don't want to put them in user's crontab which would contain more personal stuff. Does cron support spaces in username in the system crontab? If so, how to escape them? --Gene -- 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: Another BLODA with Cylance PROTECT? Can't rebase
On Tue, 23 May 2017, Brian Inglis wrote: On 2017-05-23 21:34, Tim McDaniel wrote: Back in ml/cygwin/2017-04/msg00238.html, Wed, 19 Apr 2017 14:25:26 -0400, "Another BLODA with Cylance PROTECT? Can't rebase", I noted that I couldn't install current cygwin, and asked for help on how to proceed. Someone at work did find the two interfering systems. * BeyondTrust BLODA product name is BeyondTrust PowerBroker Endpoint, Server, or both? I am told "BeyondTrust PowerBroker for Windows", installed on a laptop. * Cylance antivirus/antimalware was triggering on certain programs like dash Both had to be dealt with. -- Tim McDaniel -- 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: Problems with ssh-host-config and /var/run directory
On 2017-05-25 13:24, Henning Peters wrote: > I switched from 32bit to 64 bis a week ago, moved "cygwin" to "cygwin32" and > reinstalled from scratch into a new "cygwin" directory. > when trying to setup sshd using ssh-host-config, I get this message when > using StrictModes (which I want to and did before on cygwin32 on this system): > *** Warning: The owner and the Administrators need > *** Warning: to have .w. permission to /var/run. > *** Warning: Here are the current permissions and ACLS: > *** Warning: drwxrwxrwt+ 1 faroul root 0 May 19 20:56 /var/run > *** Warning: # file: /var/run > *** Warning: # owner: faroul > *** Warning: # group: root > *** Warning: # flags: --t > *** Warning: user::rwx > *** Warning: group::rwx > *** Warning: group:root:rwx > *** Warning: group:SYSTEM:rwx > *** Warning: mask:rwx > *** Warning: other:rwx > *** Warning: default:user::rwx > *** Warning: default:group::rwx > *** Warning: default:other:r-x > *** Warning: > *** Warning: Please change the user and/or group ownership, > *** Warning: permissions, or ACLs of /var/run. > *** ERROR: Problem with /var/run directory. Exiting. > I tried a lot, but cannot find any solution. > Any hints? It's telling you that the Administrators group is missing write access. Do you have a root id on your system or are you using passwd and group files? You could either change group ownership from root to Administrators: $ chgrp -cR Administrators /var/run and if your admin id is not faroul: $ chown -cR /var/run or, to add explicit Administrators group access, and default access to files created, explicit admin id ACL and DACL, and others read and search: $ setfacl -m g:Administrators:rwx,d:g:Administrators:rwx,\ u::rwx,d:g::rwx,o::r-x /var/run add Administrators and admin id to existing files: $ setfacl -m g:Administrators:rwx,u::rwx,\ o::r-x /var/run/* -- 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
Clueless! sshd ONLY fails at system startup (XP/SP3) ... minor correction
On 2017-05-25 17:36, Houder wrote: Hi, YES, I know, XP is NOT supported anymore ... However, I started out on XP ... and it has sshd running as a Window service, installed and configured (as approved by Corinna :-) ... some time ago I may have upgraded openssh over there (yes, I am now running W7) ... I cannot really remember. Yes, sometimes I visit (ssh) the "old station" (XP) for info that I am missing. (both machines are behind a firewall - rest assured) "Suddenly" (yesterday?) I noticed that the "sshd daemon" fails; it is started at system startup (i.e. an automatic service). Ahem ... it should have rephrased that ... however, from the error report in the sshd.log, it should be clear that the daemon fails as soon as it receives its first "ssh" request ... (and not before). [snip] The message in the sshd.log: Server listening on 0.0.0.0 port .^M # X = some port, but not 22 1 [main] sshd 3152 E:\Cygwin25\usr\sbin\sshd.exe: *** fatal error in forked process - fork: can't reserve memory for parent stack 0x3 - 0x23, (child has 0x4 - 0x24), Win32 error 487 395874 [main] sshd 3152 cygwin_exception::open_stackdumpfile: Dumping stack trace to sshd.exe.stackdump 3 [main] sshd 536 fork: child -1 - forked process 3152 died unexpectedly, retry 0, exit code 0x100, errno 11 fork: Resource temporarily unavailable^M Henri -- 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
Memcache/d (Orig: Re: Composer segfault on multiple configurations)
On 25/05/2017 08:50, Sky Diver wrote: Since then I went back in time and installed PHP 5.5.9, PHP 5.6.20 but the result is the same. PHP 5.5.9, PHP 5.6.2 on Cygwin? Were they even released on Cygwin? So I might end up following your steps in order to build PHP, hoping I could enable built-in memcache support while at it (Bash on Ubuntu on Windows, for example, has memcache and memcached included out of the box). Unfortunately, I think memcache is a separate package from php and it would not be compiled in by cygports. From what I read memcache is rather unmaintained and should be deprecated. Memcached should be used instead. https://github.com/oerdnj/deb.sury.org/issues/186#issuecomment-186217296 Memcache can't really be compiled for php7. Memcached can be. Taking a quick look at memcached, the memcached server compiles fine on cygwin except for one minor printf statement. Libmemcached, which php-memcached relies upon, requires a little bit more work (it's that whole "undefined symbols in shared libraries" thing). You possibly may want to consider moving your code from memcache to memcached. For most websites memcache/d is optional. If the website detects that memcache/d is not present during setup, it simply does not use it. Usually people just don't use it for development and then turn it on for production. That is unless you specifically want to run memcache/d code on Cygwin. -- 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: Problems with ssh-host-config and /var/run directory
Am 25.05.2017 um 21:24 schrieb Henning Peters: Hi, I switched from 32bit to 64 bis a week ago, moved "cygwin" to "cygwin32" and reinstalled from scratch into a new "cygwin" directory. I don't think that was a good strategy. Cygwin does use some registry entries pointing to absolute paths, i.e. you cannot just move a cygwin installation around and expect it to still work, just like that. That means your 32-bit Cygwin installation is now most likely quite broken, and I won't even speculate on the possible havoc running the orphaned 32-bit tools will cause in the 64-bit install now occupying their place. Just installing the 64-bit version to a new, aptly named folder cygwin64, would have been both simpler, and more likely to work. -- 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
Problems with ssh-host-config and /var/run directory
Hi, I switched from 32bit to 64 bis a week ago, moved "cygwin" to "cygwin32" and reinstalled from scratch into a new "cygwin" directory. Setup: Windows 7 Ultimate Ver 6.1 Build 7601 Service Pack 1 Cygwin DLL version info: DLL version: 2.8.0 DLL epoch: 19 DLL old termios: 5 DLL malloc env: 28 Cygwin conv: 181 API major: 0 API minor: 309 Shared data: 5 DLL identifier: cygwin1 Mount registry: 3 Cygwin registry name: Cygwin Installations name: Installations Cygdrive default prefix: Build date: Shared id: cygwin1S5 when trying to setup sshd using ssh-host-config, I get this message when using StrictModes (which I want to and did before on cygwin32 on this system): *** Warning: The owner and the Administrators need *** Warning: to have .w. permission to /var/run. *** Warning: Here are the current permissions and ACLS: *** Warning: drwxrwxrwt+ 1 faroul root 0 May 19 20:56 /var/run *** Warning: # file: /var/run *** Warning: # owner: faroul *** Warning: # group: root *** Warning: # flags: --t *** Warning: user::rwx *** Warning: group::rwx *** Warning: group:root:rwx *** Warning: group:SYSTEM:rwx *** Warning: mask:rwx *** Warning: other:rwx *** Warning: default:user::rwx *** Warning: default:group::rwx *** Warning: default:other:r-x *** Warning: *** Warning: Please change the user and/or group ownership, *** Warning: permissions, or ACLs of /var/run. *** ERROR: Problem with /var/run directory. Exiting. I tried a lot, but cannot find any solution. Any hints? Henning -- Henning Peters / cyg...@faroul.de -- 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: bug in lrint [was: FW: Printing long int in C program under cygwin64]
On 05/24/2017 06:36 PM, Steven Penny wrote: > On Wed, 24 May 2017 07:33:27, Eric Blake wrote: >> Buggy. size_t should be printed with %zi, not %i (since size_t and int >> are not necessarily the same type). > > Aren’t both wrong? By definition %i is a signed integer, and size_t is > unsigned. > So %zu Correct. Newer gcc's -Wformat-signedness will flag the discrepency. > or %llu would be more correct: NO. Do NOT use %llu with size_t, because it is not portable to 32-bit platforms. That's WHY %zu exists. > They all seem to do the job though: Yes. On all modern platforms, you can freely mix signed and unsigned integers and get correct (when the number is positive and does not exceed the signed maximum) or at least sane results (2s complement counterpart for all other values) regardless of which direction you mess with incorrect signedness. However, such behavior is technically not required by the C standard, which is why gcc added -Wformat-signedness. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: High cpu usage by at-spi-bus-launcher and xwin-xdg-menu
When I kill xwin-xdg-menu the X server does not exit. I have often found the X applications menu to not appear at startup at all, I will check next time if that correlates with high cpu. I will also check ~/.xsession-errors next time this happens. Right now I do not have at-spi-bus-launcher running, xwin-xdg-menu takes very little cpu and its menu is present in the notification area. I start X as follows, in a .bat file: C:\cygwin64\bin\run.exe --quote /usr/bin/bash.exe -l -c "cd; exec /usr/bin/startxwin" On Wed, May 24, 2017 at 8:32 PM, Jon Turney wrote: > On 22/05/2017 14:39, miserable variable wrote: >> >> I regularly see these two processes taking more that 25% CPU Time >> each, as reported by ProcessExplorer. > > > This shouldn't be happening. > >> I have often terminated both not been able to notice any functionality >> lost, but I am sure I am missing something. > > > I would expect killing xwin-xdg-menu to cause the X server to exit, and it's > X applications menu to disappear from the notification area. > > I'm not sure if you mean that doesn't happen, or it does but you don't > notice? > >> Is there something in my setup causing this? > > >> I have attached /var/log/XWin.0.log and output from cygcheck -s -v -r. >> The latter is quite big and exceed maximum size for this list, I have >> deleted lines matching 'missing.*python2' of which there were many to >> stay within the limit. > > > Thanks. This doesn't show any problems I can see. > > You might also take a look at ~/.xsession-errors to see if that shows > anything. > q -- 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: Bug: bash -e misbehaves with several nested
On 2017-05-25 08:40, Andrey Repin wrote:
> Greetings, Pavel Fedin!
Hello! I'd like to report a strange bug in 64-bit bash. The following
script:
cut ---
#/bin/bash -e
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
echo Works: $DIR
cut ---
Simply exits and produces no output (never reaches echo). The same script
works perfectly
>>> on 32 bits. Versions are the same:
--- cut ---
>>> It works fine for me.
>>> $ ./prova.bash
>>> Works: /tmp
>> Huh, works here too, indeed. But there's one little thing. If you just
>> copypasted this from my email, then you probably miss "#!"
>> (there's just "#", since i retyped the header, and made a typo). And with
>> this typo it really works for some reason. Could you make
>> sure once again ?
>> Apparently it has to do with -e switch.
> I doubt that.
>> + cat /home/anrdaemon/Documents/.sh/xx.sh
>> #!/bin/bash -xe
>> cat "$0"
>> DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
>> echo Works: $DIR
>> +++ dirname /home/anrdaemon/Documents/.sh/xx.sh
>> ++ cd /home/anrdaemon/Documents/.sh
>> ++ pwd
>> + DIR=/home/anrdaemon/Documents/.sh
>> + echo Works: /home/anrdaemon/Documents/.sh
>> Works: /home/anrdaemon/Documents/.sh
> At the same time,
>> #/bin/bash -xe
>> cat "$0"
>> DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
>> echo Works: $DIR
>> /home/anrdaemon/Documents/.sh/xx.sh: 4:
>> /home/anrdaemon/Documents/.sh/xx.sh: Bad substitution
>> Works: /home/anrdaemon/Documents/.sh
> If you are wondering, what's going on, …
> sh is not bash. For me. I guess, dash is a little more vocal about
> errors, than bash.
So the complaint is that sh doesn't work with bash arrays?
Hashbangs matter - print that on a T-shirt and sell it ;^>
--
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
[ANNOUNCEMENT] Updated: lyx-2.2.3-1
New version 2.2.3-1 of lyx is available in the Cygwin distribution: CHANGES Last upstream release. http://www.lyx.org/announce/2_2_3.txt DESCRIPTION LyX is a document processor that encourages an approach to writing based on the structure of your documents (WYSIWYM) and not simply their appearance (WYSIWYG). LyX combines the power and flexibility of TeX/LaTeX with the ease of use of a graphical interface. HOMEPAGE http://www.lyx.org Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . -- 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: too many environment variables on self-compiled xar archiver
On 2017-05-24 15:18, Hans-Bernhard Bröker wrote: > Am 24.05.2017 um 12:01 schrieb Andrey Repin: > >>> Did you notice this entry and does anyone know where this comes from? >>> !C:=C:\cygwin\bin > >> This is coming from CMD, and denotes current working directory on an >> indicated >> drive. > > And for (most of) all the hairy details, see > > https://blogs.msdn.microsoft.com/oldnewthing/20100506-00/?p=14133 > > If you see these, you must have printed the environment using a tool > other than CMD itself (e.g. Cygwin's "env"). Or as comment https://blogs.msdn.microsoft.com/oldnewthing/20100506-00/?p=14133#comment-830913 says, in cmd type set " to see all environment variables including those starting with "=". So the above is Cygwin "cleaning" the inherited cmd environment which contains =:=:\ for each mapped drive, and some other legacy compatible information, by changing the leading "=" to "!", so it can restore it for child process environments. -- 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: bug in lrint [was: FW: Printing long int in C program under cygwin64]
On 2017-05-24 19:31, Steven Penny wrote:
> On Wed, 24 May 2017 16:36:03, Steven Penny wrote:
>> Aren’t both wrong? By definition %i is a signed integer, and size_t is
>> unsigned.
>> So %zu or %llu would be more correct:
>> http://wikipedia.org/wiki/C_data_types
>> They all seem to do the job though:
> Correcting myself. Here is why you cannot use %zi:
> $ cat alfa.c
> #define __USE_MINGW_ANSI_STDIO 1
> #include
> int main() {
> printf("%zi %zu %llu\n", __SIZE_MAX__, __SIZE_MAX__,
> __SIZE_MAX__);
> }
> $ x86_64-w64-mingw32-gcc -o alfa alfa.c
> $ ./alfa
> -1 18446744073709551615 18446744073709551615
I think either 10+ digits or a negative value are adequate indicators
that something may have gone wrong, and -1 is a more compact format for
*_MAX, unless you need to see actual values.
--
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: UTF-8 compatibility between Windows and Cygwin
Greetings, Nellis, Kenneth! > I have (BOM-less) UTF-8 text files that I can read fine in > Cygwin, but not Windows. When I create text files in Windows > containing non-ASCII characters, I cannot read them in > Cygwin. I understand why, but wondering the best way to be > able to share text files across the two environments. Please provide `od -t x1z` of the file you are referring to. > I'm pretty sure that I want to keep my Cygwin LANG=C.UTF-8 > setting, Better use real language indication, and configure LC_ according to preferences. > but wondering what I can do on the Windows side for > compatibility and what are the side effects. On Windows side, you could actually use UTF-8. Without seeing the requested dump, I can only guess, though. > Currently > Windows's Command Prompt command chcp shows "Active code > page: 437". (Is that obsolete or even relevant?) Neither of the two, unless you consider relevance to the correct display of the results and other console-related operations. If you're often find yourself in a native console, I suggest you tweak LANG to match (i.e. LANG=ru_RU.CP866 for me) and only change it to .UTF-8 for MinTTY (it can help you with override, if you don't want to tweak your startup files). > One solution seems to be to put a BOM in each UTF-8 text > file; then the files read fine in both environments, but > that's not conveniently accomplished. That's hardly a solution, though. More like a workaround. -- With best regards, Andrey Repin Thursday, May 25, 2017 18:48:43 Sorry for my terrible english... -- 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: Clueless! sshd ONLY fails at system startup (XP/SP3) ...
Greetings, Houder! > Hi, > YES, I know, XP is NOT supported anymore ... However, I started > out on XP ... and it has sshd running as a Window service, > installed and configured (as approved by Corinna :-) > ... some time ago I may have upgraded openssh over there (yes, I > am now running W7) ... I cannot really remember. Yes, sometimes I > visit (ssh) the "old station" (XP) for info that I am missing. > (both machines are behind a firewall - rest assured) > "Suddenly" (yesterday?) I noticed that the "sshd daemon" fails; > it is started at system startup (i.e. an automatic service). > When the service is restarted after system startup, i.c. > cygrunsrv -E sshd; cygrunsrv -S sshd > it then works flawlessly (which amazes me, given the error in > the sshd.log) What if you `net start "Cygwin sshad"` ? > ... tried several things ... in the end, I reinstalled Cygwin + > openssh (a minimal installation) -- using the time machine. > However this new, minimal installation of Cywin fails in the exact > same way! > Again tried some things ... Finally, I decided to post my problem. > Any suggestions? (Yes, XP has F-Secure as anti-virus) > The message in the sshd.log: > Server listening on 0.0.0.0 port .^M # X = some port, but not 22 >1 [main] sshd 3152 E:\Cygwin25\usr\sbin\sshd.exe: *** fatal error > in forked process - fork: can't reserve memory for parent stack 0x3 > - 0x23, (child has 0x4 - 0x24), Win32 error 487 > 395874 [main] sshd 3152 cygwin_exception::open_stackdumpfile: Dumping > stack trace to sshd.exe.stackdump >3 [main] sshd 536 fork: child -1 - forked process 3152 died > unexpectedly, retry 0, exit code 0x100, errno 11 > fork: Resource temporarily unavailable^M > Do I interpret this correctly? The child (sshd) fails to "allocate > stack for the parent (sshd)" ... > WHY does this only happen at system STARTUP ? Any "antivirus" running on that system? Did you try to fully rebase your installation? -- With best regards, Andrey Repin Thursday, May 25, 2017 18:57:22 Sorry for my terrible english... -- 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
Clueless! sshd ONLY fails at system startup (XP/SP3) ...
Hi, YES, I know, XP is NOT supported anymore ... However, I started out on XP ... and it has sshd running as a Window service, installed and configured (as approved by Corinna :-) ... some time ago I may have upgraded openssh over there (yes, I am now running W7) ... I cannot really remember. Yes, sometimes I visit (ssh) the "old station" (XP) for info that I am missing. (both machines are behind a firewall - rest assured) "Suddenly" (yesterday?) I noticed that the "sshd daemon" fails; it is started at system startup (i.e. an automatic service). When the service is restarted after system startup, i.c. cygrunsrv -E sshd; cygrunsrv -S sshd it then works flawlessly (which amazes me, given the error in the sshd.log) ... tried several things ... in the end, I reinstalled Cygwin + openssh (a minimal installation) -- using the time machine. However this new, minimal installation of Cywin fails in the exact same way! Again tried some things ... Finally, I decided to post my problem. Any suggestions? (Yes, XP has F-Secure as anti-virus) The message in the sshd.log: Server listening on 0.0.0.0 port .^M # X = some port, but not 22 1 [main] sshd 3152 E:\Cygwin25\usr\sbin\sshd.exe: *** fatal error in forked process - fork: can't reserve memory for parent stack 0x3 - 0x23, (child has 0x4 - 0x24), Win32 error 487 395874 [main] sshd 3152 cygwin_exception::open_stackdumpfile: Dumping stack trace to sshd.exe.stackdump 3 [main] sshd 536 fork: child -1 - forked process 3152 died unexpectedly, retry 0, exit code 0x100, errno 11 fork: Resource temporarily unavailable^M Do I interpret this correctly? The child (sshd) fails to "allocate stack for the parent (sshd)" ... WHY does this only happen at system STARTUP ? Regards, Henri (this message should include cygcheck.out - I hope) == Cygwin Configuration Diagnostics Current System Time: Thu May 25 15:24:32 2017 Windows XP Professional Ver 5.1 Build 2600 Service Pack 3 Path: E:\Cygwin25\usr\local\bin E:\Cygwin25\bin C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem E:\Cygwin25\home\Henri\bin Output from E:\Cygwin25\bin\id.exe UID: 1003(Henri)GID: 513(None) 513(None) 544(Administrators) 545(Users) 4(INTERACTIVE) 11(Authenticated Users) 4095(CurrentSession) 66048(LOCAL) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'Henri' PWD = '/home/Henri' HOME = '/home/Henri' HOMEPATH = '\Documents and Settings\Henri' APPDATA = 'C:\Documents and Settings\Henri\Application Data' HOSTNAME = 'xp' SHELL = '/bin/bash' TERM = 'xterm-256color' PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 4 Stepping 3, GenuineIntel' WINDIR = 'C:\WINDOWS' TMPDIR = '/tmp' OLDPWD = '/usr/bin' USERDOMAIN = 'XP' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users' TEMP = '/tmp' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' USERNAME = 'Henri' PROCESSOR_LEVEL = '15' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' USERPROFILE = 'C:\Documents and Settings\Henri' LANG = 'en_US.UTF-8' CLIENTNAME = 'Console' TZ = 'Europe/Berlin' PS1 = '@@# ' LOGONSERVER = '\\XP' PROCESSOR_ARCHITECTURE = 'x86' EXECIGNORE = '*.dll' SHLVL = '1' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' QUOTING_STYLE = 'literal' HOMEDRIVE = 'C:' COMSPEC = 'C:\WINDOWS\system32\cmd.exe' TMP = '/tmp' SYSTEMROOT = 'C:\WINDOWS' PRINTER = 'HP LaserJet P1006' PROCESSOR_REVISION = '0403' PROMPT_COMMAND = 'history -a' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info' PROGRAMFILES = 'C:\Program Files' NUMBER_OF_PROCESSORS = '2' LC_TIME = 'C' SESSIONNAME = 'Console' COMPUTERNAME = 'XP' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Console\Cygwin Bash Shell (default) = 0x0071 PopupColors = 0x00f5 ColorTable00 = 0x ColorTable01 = 0x0080 ColorTable02 = 0x8000 ColorTable03 = 0x00808000 ColorTable04 = 0x0080 ColorTable05 = 0x00800080 ColorTable06 = 0x8080 ColorTable07 = 0x00c0c0c0 ColorTable08 = 0x00808080 ColorTable09 = 0x00ff ColorTable10 = 0xff00 ColorTable11 = 0x0000 ColorTable12 = 0x00ff ColorTable13 = 0x00ff00ff ColorTable14 = 0x ColorTable15 = 0x00ff InsertMode = 0x0001 QuickEdit = 0x0800 FullScreen = 0x ScreenBufferSize = 0x012c008c WindowSize = 0x0032008c WindowPosition = 0x00c102a0 FontSize = 0x000c FontFamily = 0x0036 FontWeight = 0x0190 FaceName = 'Lucida Console' CursorSize = 0x0019 HistoryBufferSize = 0x0032 NumberOfHistoryBuffers = 0x0004 HistoryNoDup = 0x HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygwin\setup HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.cygwin HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.cygwin\OpenWithList HKEY_CURRENT_USER\Software\Microso
UTF-8 compatibility between Windows and Cygwin
I have (BOM-less) UTF-8 text files that I can read fine in Cygwin, but not Windows. When I create text files in Windows containing non-ASCII characters, I cannot read them in Cygwin. I understand why, but wondering the best way to be able to share text files across the two environments. I'm pretty sure that I want to keep my Cygwin LANG=C.UTF-8 setting, but wondering what I can do on the Windows side for compatibility and what are the side effects. Currently Windows's Command Prompt command chcp shows "Active code page: 437". (Is that obsolete or even relevant?) One solution seems to be to put a BOM in each UTF-8 text file; then the files read fine in both environments, but that's not conveniently accomplished. --Ken Nellis -- 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: Apache rebase trouble
On Wed, 24 May 2017 01:56:55 +0200, Michael Enright wrote: On Tue, May 23, 2017 at 3:59 PM, Michael Lemke wrote: Lacking further clues I did the trial and error thing and removed some stuff I thought I didn't need (like GNOME). Not sure yet what I broke but my Apache is working again. Thanks for the hint that the number of known dlls could be a problem. I'd still appreciate more precise information of how rebase works and if there is a more systematic approach. The command rebase -is gives a list of the DLLs, their sizes and where they are based. The DLL size is in "field 5" as 'sort' recons fields, so rebase -is | sort -k5 will dump the DLLs in size order. Thank you. So if I take the first and last line of rebase's default output the difference in the 3rd field tells me how much space is required, correct? In my cleaned up installation it is 879.5 MB. Is it possible to give a limit up to which this number may grow? Exactly what memory/address space is being reserved here? On my system the last DLL in the output is an LLVM DLL which I believe is used by the X server. A lot of the top DLLs appear to be related to the X server, some of those are code-generation DLLs for the LLVM JIT to use. The footprint of the X server seems large. In my installation LLVM takes up a lot (and for some reason I have three different versions installed - have to get rid of some) but the biggest is qt4: orion> rebase -si | sort -k5 | tail /usr/lib/cygswrAVX2.dll base 0x4529 size 0x00c7c000 /usr/bin/cygLLVM-3.0.dll base 0x6e71 size 0x00cab000 /usr/bin/cygavcodec-54.dll base 0x5f71 size 0x00d79000 /usr/bin/cygLLVM-3.4.dll base 0x6c31 size 0x0116e000 /usr/bin/cygLLVM-3.1.dll base 0x6d48 size 0x0128a000 /usr/bin/cygicudata56.dll base 0x5806 size 0x017ed000 /usr/bin/cygicudata57.dll base 0x567d size 0x01885000 /usr/bin/cygwebkitgtk-3.0-0.dll base 0x4966 size 0x01951000 /usr/bin/cygLLVM-3.8.dll base 0x6a81 size 0x01af3000 /usr/bin/cygQtWebKit-4.dll base 0x6381 size 0x01eea000 orion> -- 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: Bug: bash -e misbehaves with several nested
Greetings, Pavel Fedin!
>> > Hello! I'd like to report a strange bug in 64-bit bash. The following
>> > script:
>> >
>> > cut ---
>> > #/bin/bash -e
>> >
>> > DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
>> > echo Works: $DIR
>> > cut ---
>> >
>> > Simply exits and produces no output (never reaches echo). The same script
>> > works perfectly
>> on 32 bits. Versions are the same:
>> >
>> > --- cut ---
>>
>> It works fine for me.
>>
>> $ ./prova.bash
>> Works: /tmp
> Huh, works here too, indeed. But there's one little thing. If you just
> copypasted this from my email, then you probably miss "#!"
> (there's just "#", since i retyped the header, and made a typo). And with
> this typo it really works for some reason. Could you make
> sure once again ?
> Apparently it has to do with -e switch.
I doubt that.
> + cat /home/anrdaemon/Documents/.sh/xx.sh
> #!/bin/bash -xe
>
> cat "$0"
> DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
> echo Works: $DIR
> +++ dirname /home/anrdaemon/Documents/.sh/xx.sh
> ++ cd /home/anrdaemon/Documents/.sh
> ++ pwd
> + DIR=/home/anrdaemon/Documents/.sh
> + echo Works: /home/anrdaemon/Documents/.sh
> Works: /home/anrdaemon/Documents/.sh
At the same time,
> #/bin/bash -xe
>
> cat "$0"
> DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
> echo Works: $DIR
> /home/anrdaemon/Documents/.sh/xx.sh: 4:
> /home/anrdaemon/Documents/.sh/xx.sh: Bad substitution
> Works: /home/anrdaemon/Documents/.sh
If you are wondering, what's going on, …
sh is not bash. For me. I guess, dash is a little more vocal about errors,
than bash.
--
With best regards,
Andrey Repin
Thursday, May 25, 2017 17:34:21
Sorry for my terrible english...
Re: too many environment variables on self-compiled xar archiver
Greetings, Hans-Bernhard Bröker! > Am 24.05.2017 um 12:01 schrieb Andrey Repin: >>> Did you notice this entry and does anyone know where this comes from? >>> !C:=C:\cygwin\bin >> This is coming from CMD, and denotes current working directory on an >> indicated >> drive. > And for (most of) all the hairy details, see > https://blogs.msdn.microsoft.com/oldnewthing/20100506-00/?p=14133 > If you see these, you must have printed the environment using a tool > other than CMD itself (e.g. Cygwin's "env"). Yes, as evident by the Cygwin paths in $PATH. -- With best regards, Andrey Repin Thursday, May 25, 2017 16:29:47 Sorry for my terrible english... -- 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: Bug: bash -e misbehaves with several nested
On 25/05/2017 11:57, Pavel Fedin wrote:
Hello!
Hello! I'd like to report a strange bug in 64-bit bash. The following script:
cut ---
#/bin/bash -e
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
echo Works: $DIR
cut ---
Simply exits and produces no output (never reaches echo). The same script works
perfectly
on 32 bits. Versions are the same:
--- cut ---
It works fine for me.
$ ./prova.bash
Works: /tmp
Huh, works here too, indeed. But there's one little thing. If you just copypasted this
from my email, then you probably miss "#!"
(there's just "#", since i retyped the header, and made a typo). And with this
typo it really works for some reason. Could you make
sure once again ?
Apparently it has to do with -e switch.
$ ./prova_bash
Works: /cygdrive/e/cygwin/tmp
$ cat prova_bash
#!/bin/bash -e
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
echo Works: $DIR
--
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: Bug: bash -e misbehaves with several nested
Hello!
> > Hello! I'd like to report a strange bug in 64-bit bash. The following
> > script:
> >
> > cut ---
> > #/bin/bash -e
> >
> > DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
> > echo Works: $DIR
> > cut ---
> >
> > Simply exits and produces no output (never reaches echo). The same script
> > works perfectly
> on 32 bits. Versions are the same:
> >
> > --- cut ---
>
> It works fine for me.
>
> $ ./prova.bash
> Works: /tmp
Huh, works here too, indeed. But there's one little thing. If you just
copypasted this from my email, then you probably miss "#!"
(there's just "#", since i retyped the header, and made a typo). And with this
typo it really works for some reason. Could you make
sure once again ?
Apparently it has to do with -e switch.
Kind regards,
Pavel Fedin
Senior Engineer
Samsung Electronics Research center Russia
> -Original Message-
> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of
> Marco Atzeri
> Sent: Wednesday, May 24, 2017 8:41 PM
> To: cygwin@cygwin.com
> Subject: Re: Bug: bash -e misbehaves with several nested
>
> On 24/05/2017 14:54, Pavel Fedin wrote:
> > Hello! I'd like to report a strange bug in 64-bit bash. The following
> > script:
> >
> > cut ---
> > #/bin/bash -e
> >
> > DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
> > echo Works: $DIR
> > cut ---
> >
> > Simply exits and produces no output (never reaches echo). The same script
> > works perfectly
> on 32 bits. Versions are the same:
> >
> > --- cut ---
>
> It works fine for me.
>
> $ ./prova.bash
> Works: /tmp
>
>
> $ uname -svr
> CYGWIN_NT-6.1 2.8.0(0.309/5/3) 2017-04-01 20:47
>
>
> --
> 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
>
--
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: Mintty does not close after "exit" command
On Wed, May 24, 2017 at 11:42 AM, Dani Moncayo wrote: > To reproduce the problem, just open the standard cygwin terminal (e.g. > by double-clicking the desktop icon), an then type the "exit" command > in the bash shell. > > I see a "logout" message for a fraction of a second, then the terminal > becomes empty (without text), but the mintty window remains visible > but unresponsive, with the title bar showing "~ (Not Responding)". I've seen this happen several times in the past few days. This may be related to the fact that I'm installing cygwin a lot these days. It may happen after installing a package that doesn't require to close any open cygwin terminal. Usually I close everything by default but since I'm installing a lot lately I sometimes skip it if it's not required (e.g. installing a php extension). Maybe you have some cygwin service running in the background (you can check it with: cygrunsrv -L). Regardless, maybe a full rebase could help. -- 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: Composer segfault on multiple configurations
On Mon, May 22, 2017 at 9:38 PM, Richard H Lee wrote: > Just in case Sky Diver or anyone else is interested in compiling php from > Cygports, here are some simple steps to do so. Thanks Richard, I may try this at some point, but am currently experiencing other instabilities. For some reason, I started getting the message "Class 'Memcache' not found" when running memcache-aware PHP code. Since then I went back in time and installed PHP 5.5.9, PHP 5.6.20 but the result is the same. There's no php-memcache extension to install (on Ubuntu, for example, that's the way to add it). I'm pretty sure I didn't go through the "pecl install memcache" process, and doing so now fails during compilation. So I might end up following your steps in order to build PHP, hoping I could enable built-in memcache support while at it (Bash on Ubuntu on Windows, for example, has memcache and memcached included out of the box). -- 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
