Re: calm: cygwin package upload report for Pierre A. Humblet

[Pierre A. Humblet]

On 2/8/2022 4:11 PM, cygwin-apps@cygwin.com wrote:

WARNING: copying 'exim-4.95-1.hint' to 'exim-4.95-1-src.hint'
INFO: srcpkg exim-4.95-1-src.tar.xz contains 0 .cygport files
INFO: cannot determine homepage: from srcpkg exim-4.95-1-src.tar.xz
ERROR: package 'exim': required key 'homepage' missing
ERROR: errors while parsing hints for package 'exim'
ERROR: error parsing /sourceware/cygwin-staging/home/Pierre A. 
Humblet/x86_64/release/exim/exim-4.95-1-src.hint
ERROR: error while reading uploaded arch x86_64 packages from maintainer Pierre 
A. Humblet
SUMMARY: 1 WARNING(s), 2 INFO(s), 4 ERROR(s)


Exim is a legacy package not relying on cygport.

Looks like calm is not happy with that.

Can it be convinced to accept it, like it used to?

Pierre

[ANNOUNCEMENT] Updated: exim-4.92.3-1

[Pierre A. Humblet]

The following package has been uploaded to the Cygwin 64 bit 
distribution: exim-4.92.3-1


Exim is a well known Mail Transfer Agent.

This is a security release of the latest Exim version, 4.92, see

http://www.exim.org/
https://github.com/Exim/exim/wiki/ChangeLog

If you have questions or comments, please send them to the Cygwin 
mailing list: cygwin at cygwin.com, mentioning "exim" in the subject line.


Pierre

--
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

Updated: exim-4.92.3-1

[Pierre A. Humblet]

The following package has been uploaded to the Cygwin 64 bit 
distribution: exim-4.92.3-1


Exim is a well known Mail Transfer Agent.

This is a security release of the latest Exim version, 4.92, see

http://www.exim.org/
https://github.com/Exim/exim/wiki/ChangeLog

If you have questions or comments, please send them to the Cygwin 
mailing list: cygwin at cygwin.com, mentioning "exim" in the subject line.


Pierre

Re: Exim & cygwin-2.6.0-1 (x86) fatal Signal 6 on start

[Pierre A. Humblet]

On 9/12/2016 8:26 AM, Ross Hemingway wrote:
Update to cygwin-2.6.0-1.  Exim has a fatal start error - exim: PID 
3756: service `exim' failed: signal 6 raised.


Rolled back to cygwin-2.5.2-1,  problem averted.



Sorry for the very long delay in answering.
The debugging below was done from a non-privileged account, and the 
setuid32() should thus fail, but the program should not abort.


It aborts in the call to "free (privs)".
"privs" are obtained by get_priv_list().
When the target user is SYSTEM, get_priv_list()  returns 
(PTOKEN_PRIVILEGES) _privs;

where "sys_privs" is a constant structure that cannot be freed.

Pierre

Breakpoint 2, setuid32 (uid=18) at 
/ext/build/mknetrel/src/cygwin-snapshot-20161214-1/winsup/cygwin/syscalls.cc:3426

3426{
(gdb) c
Continuing.

Breakpoint 3, create_token (usersid=..., new_groups=...) at 
/ext/build/mknetrel/src/cygwin-snapshot-20161214-1/winsup/cygwin/sec_auth.cc:856

856 {
(gdb) b 978
Breakpoint 4 at 0x180107e98: file 
/ext/build/mknetrel/src/cygwin-snapshot-20161214-1/winsup/cygwin/sec_auth.cc, 
line 978.

(gdb) c
Continuing.

Breakpoint 4, create_token (usersid=..., new_groups=...) at 
/ext/build/mknetrel/src/cygwin-snapshot-20161214-1/winsup/cygwin/sec_auth.cc:978

978   if (status)
(gdb) n
979 __seterrno_from_nt_status (status);
(gdb) n
993   pop_self_privilege ();
(gdb) n
994   if (token != INVALID_HANDLE_VALUE)
(gdb) n
996   if (privs)
(gdb) n
997 free (privs);
(gdb) s
free (p=0x180247e40 ) at 
/ext/build/mknetrel/src/cygwin-snapshot-20161214-1/winsup/cygwin/malloc_wrapper.cc:36

36malloc_printf ("(%p), called by %p", p, caller_return_address ());
(gdb) n
35  {
(gdb) n
36malloc_printf ("(%p), called by %p", p, caller_return_address ());
(gdb) n
37if (!use_internal)
(gdb) n
41__malloc_lock ();
(gdb) n
42dlfree (p);
(gdb) s
dlfree (mem=mem@entry=0x180247e40 ) at 
/ext/build/mknetrel/src/cygwin-snapshot-20161214-1/winsup/cygwin/malloc.cc:4688

4688  if (mem != 0) {
(gdb) p mem
$8 = (void *) 0x180247e40 
(gdb) n
4701  if (RTCHECK(ok_address(fm, p) && ok_inuse(p))) {
(gdb) n
4689mchunkptr p  = mem2chunk(mem);
(gdb) n
4701  if (RTCHECK(ok_address(fm, p) && ok_inuse(p))) {
(gdb) n
4780  USAGE_ERROR_ACTION(fm, p);
(gdb) s
abort () at 
/ext/build/mknetrel/src/cygwin-snapshot-20161214-1/winsup/cygwin/signal.cc:364

364   _my_tls.incyg++;
(gdb) n
365   sig_dispatch_pending ();
(gdb) s
364   _my_tls.incyg++;
(gdb) s
365   sig_dispatch_pending ();
(gdb) s
sig_dispatch_pending (fast=fast@entry=false) at 
/ext/build/mknetrel/src/cygwin-snapshot-20161214-1/winsup/cygwin/sigproc.cc:438

438   if (sigq.pending () && &_my_tls != _sig_tls)
(gdb) s
pending_signals::pending (this=0x180212220 , this=0x180212220 
) at 
/ext/build/mknetrel/src/cygwin-snapshot-20161214-1/winsup/cygwin/sigproc.cc:77

77bool pending () {retry = true; return !!start.next;}
(gdb) s
sig_dispatch_pending (fast=fast@entry=false) at 
/ext/build/mknetrel/src/cygwin-snapshot-20161214-1/winsup/cygwin/sigproc.cc:438

438   if (sigq.pending () && &_my_tls != _sig_tls)
(gdb) s
440 }
(gdb) s
abort () at 
/ext/build/mknetrel/src/cygwin-snapshot-20161214-1/winsup/cygwin/signal.cc:369

369   sigdelset (_mask, SIGABRT);
(gdb) s
368   sigfillset (_mask);
(gdb) s
sigfillset (set=0x9c68) at 
/ext/build/mknetrel/src/cygwin-snapshot-20161214-1/winsup/cygwin/signal.cc:506

506   *set = ~((sigset_t) 0);
(gdb) s
abort () at 
/ext/build/mknetrel/src/cygwin-snapshot-20161214-1/winsup/cygwin/signal.cc:369

369   sigdelset (_mask, SIGABRT);
(gdb) s
sigdelset (set=0x9c68, sig=6) at 
/ext/build/mknetrel/src/cygwin-snapshot-20161214-1/winsup/cygwin/signal.cc:466

466 {
(gdb) s
468   if (sig <= 0 || sig >= NSIG)
(gdb) s
466 {
(gdb) s
468   if (sig <= 0 || sig >= NSIG)
(gdb) s
475   *set &= ~SIGTOMASK (sig);
(gdb) s
477 }
(gdb) s
abort () at 
/ext/build/mknetrel/src/cygwin-snapshot-20161214-1/winsup/cygwin/signal.cc:370

370   set_signal_mask (_my_tls.sigmask, sig_mask);


--
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: cron bug

[Pierre A Humblet]

> -Original Message-
> From:  Stefan Götz
> Sent: Wednesday, January 13, 2016 12:55 AM
> 
> 
> Hello,
> 
> I have set up cron as below on a fresh Windows 10 with a fresh,
> minimal 64-bit Cygwin installation. Cronjobs are not executed and
cronevents says /usr/sbin/cron:
> PID 608: (CRON) error (can't switch user context). The output of cronbug
is attached.

> 
> When I run the service not under my own user but as an administrator, the
> result and error is the same.
> 
> 
> Thanks! Any advice is appreciated.
> 
> 
> $ cron-config

Thanks for sending the cronbug.txt, Stefan.

It shows that although you asked to run as yourself the daemon is actually
running under the SYSTEM account.
That explains the error message, but I wonder why cron-config misbehaves.
That hasn't changed in years.
Are you logged in with your "Windows id" (instead of as your local user id)?

If so there has been a similar case that has never been fully explained.

Could you do the following:
Edit /bin/cron-config and uncomment the second line (set -x)
Run the modified cron-config, reproducing exactly what you do usually
(remove the service, ask to run as yourself).
The details of what the script does will be echoed.
Then paste the whole output in an e-mail, you can send it to me privately.

Pierre


--
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: empty cron.log, user switching problem on Windows 10 with Microsoft id

[Pierre A Humblet]

> -Original Message-
> From: Jason Crawford
> Sent: Friday, December 18, 2015 2:17 AM
> 
> Hello everyone,
> Thanks for a great offering and all the help you provide.I've
> used cygwin for a few years, but not deeply.  cron is one of the tools I
> find very handy.   Recently I upgraded to Windows 10 and ran in to
> problems on my Surface Pro 3.   I installed cygwin cron (latest cygwin
> 32bit (2.873).  Cron is 4.1-63.) and it seemed to work but as soon as I 
> switched
> my laptop to use the Microsoft ID cron as Microsoft suggest,
> cron stopped working, complaining that it can not switch id's.   If I do
> a fresh install of Win10, switch to the Microsoft ID, and install cygwin
> and cron, cron won't even work once.   And if I do a fresh install of
> Win10 and never switch to the Microsoft id, cygwin cron works fine.
> When it fails, the cronevents log file complains that it can't switch user 
> id's.
> 
> I really don't do much.  I just install cygwin with cron, emacs, ssh, 
> inetutils,
> unison, wget.  Then I start up a cygwin window as
> administrator.   Then cron-config, yes (service), [] (blank CYGWIN),
> yes (self), yes (start daemon).   Then I create a trivial cron file "*/1
> * * * *  date >~/cron_is_running.txt".   crontab mycron ... and I
> wait a minute.  Then I invoke cronevents.
> 
> I want to try out all the features of that Microsoft touts as coming with use 
> of
> the Microsoft ID, but I don't want to lose cron.
> 
> What do we all suggest that I do next?

Is that only with Cron or also with other services such as passwordless sshd?

Unfortunately I have no Windows 10 nor Microsoft ID to test. 

Pierre
cron maintainer


--
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: empty cron.log

[Pierre A Humblet]

> -Original Message-
> From:  Jason Crawford
> Sent: Friday, December 18, 2015 1:01 PM
> 
> On 12/18/2015 9:50 AM, Pierre A Humblet wrote:
> >> -Original Message-
> >> From: Jason Crawford
> >> Sent: Friday, December 18, 2015 2:17 AM
> >>
> >> Hello everyone,
> >>  Thanks for a great offering and all the help you provide.I've
> >> used cygwin for a few years, but not deeply.  cron is one of the tools I
> >> find very handy.   Recently I upgraded to Windows 10 and ran in to
> >> problems on my Surface Pro 3.   I installed cygwin cron (latest cygwin
> >> 32bit (2.873).  Cron is 4.1-63.) and it seemed to work but as soon as
> >> I switched my laptop to use the Microsoft ID cron as Microsoft suggest,
> >> cron stopped working, complaining that it can not switch id's.   If I do
> >> a fresh install of Win10, switch to the Microsoft ID, and install cygwin
> >> and cron, cron won't even work once.   And if I do a fresh install of
> >> Win10 and never switch to the Microsoft id, cygwin cron works fine.
> >> When it fails, the cronevents log file complains that it can't switch user
> id's.
> >>
> >> I really don't do much.  I just install cygwin with cron, emacs, ssh,
> >> inetutils, unison, wget.  Then I start up a cygwin window as
> >> administrator.   Then cron-config, yes (service), [] (blank CYGWIN),
> >> yes (self), yes (start daemon).   Then I create a trivial cron file "*/1
> >> * * * *  date >~/cron_is_running.txt".   crontab mycron ... and I
> >> wait a minute.  Then I invoke cronevents.
> >>
> >> I want to try out all the features of that Microsoft touts as coming
> >> with use of the Microsoft ID, but I don't want to lose cron.
> >>
> >> What do we all suggest that I do next?
> > Is that only with Cron or also with other services such as passwordless
> sshd?
> I don't run sshd on the machine (as far as I know).  I only ssh out.
> That works fine without a password.   But...
> 
> But I've just tried setting up sshd on two Windows machines just now.
> I ran in to a few complications due to being a novice, but it eventually
> worked on Windows 7.I've still not gotten sshd to work on Windows 10
> if my ssh client is on another machine.  That seems to be some sort of
> network connection or firewall problem.  I can ssh from the local Win10
> machine to the local Win10 machine though.   I have only one account and
> I can ssh in to that without a password using authorized_keys.
> 
> Does that answer your question?   Is there a simpler or more helpful way
> that I can gather data for you?   I don't mind reinstalling the
> operating system if that would help.

Thanks, Jason.

I assume both cron-config and ssh-host-config asked you for the name of a 
privileged user,
and you used the same name in both cases.

You may want to try what I suggested to someone else a while ago
http://cygwin.1069669.n5.nabble.com/cron-error-can-t-switch-user-context-td61919.html

The instructions were, as follows, except that now the service should run under 
the privileged account, 
(use -u), not under SYSTEM (the default)

> Stop the cron service. 
> Use a simple crontab that runs every minute, for only one user. 
> Using cygrunsrv, create a new service runing "strace" with argument "cron" 
> under SYSTEM 
> 1)  cygrunsrv -I trace_cron -p /usr/bin/strace -a /usr/sbin/cron 
> 2)  cygrunsrv -S trace_cron 
> 3)  Let this run for no more than 2 minutes, output will be in 
> /var/log/trace_cron.log 
>  You may have to use kill -9 to stop the service (kill the cron pid) 
> 4)  Send the trace_cron.log file as an attachment. 
> 5)  Remove the trace_cron service 


Pierre



--
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

Updated: exim-4.86-1

[Pierre A. Humblet]

I have updated Exim, the Mail Transfer Agent, to release 4.86, in 32 
and 64 bit versions.


This is a regular upstream update, see 
https://github.com/Exim/exim/wiki/ChangeLog


If you have questions or comments, please send them to the Cygwin
mailing list: cygwin at cygwin.com, mentioning "exim" in the subject line.

Pierre

---

To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

Exim is in the Mail category.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:


cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at the above URL.

[ANNOUNCEMENT] Updated: exim-4.86-1

[Pierre A. Humblet]

I have updated Exim, the Mail Transfer Agent, to release 4.86, in 32 
and 64 bit versions.


This is a regular upstream update, see 
https://github.com/Exim/exim/wiki/ChangeLog


If you have questions or comments, please send them to the Cygwin
mailing list: cygwin at cygwin.com, mentioning "exim" in the subject line.

Pierre

---

To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

Exim is in the Mail category.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:


cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at the above URL.

--
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: Exim unable to send email with error unable to set gid=544 or uid=18 after update

[Pierre A Humblet]

 -Original Message-
 From: Peter Senft
 Sent: Friday, April 24, 2015 10:56 AM
 
 Hi,
 
 I had a perfectly fine running exim configuration, that delivered mail to a
 smart host and rewrote the sender address to be a specific one (necessary
 for the smart host). Then, through the installation of some additional tools, 
 I
 also got an update for Exim (now Exim version 4.84
 #1 built 25-Jan-2015 22:16:19). Since then I receive the following error
 message, when I try to send emails:
 
 - snip -
 2015-04-24 14:20:21 unable to set gid=544 or uid=18 (euid=197108):
 privilege not needed
 - snap -
 snip

I have just uploaded exim-4.84-2. 
Hopefully that will take care of the issue.
Thanks for the report.

Pierre



--
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: Exim unable to send email with error unable to set gid=544 or uid=18 after update

[Pierre A Humblet]

 -Original Message-
 From:  Peter Senft
 Sent: Friday, April 24, 2015 10:56 AM
 
 Hi,
 
 I had a perfectly fine running exim configuration, that delivered mail to a
 smart host and rewrote the sender address to be a specific one (necessary
 for the smart host). Then, through the installation of some additional tools, 
 I
 also got an update for Exim (now Exim version 4.84
 #1 built 25-Jan-2015 22:16:19). Since then I receive the following error
 message, when I try to send emails:
 
 - snip -
 2015-04-24 14:20:21 unable to set gid=544 or uid=18 (euid=197108):
 privilege not needed
 - snap -

Sorry about that Peter. That must be a bug I introduced in the latest Cygwin 
port of exim when I improved its security.
I will look into it ASAP but meanwhile you should revert to the previous 
version of exim.

Pierre 



--
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: [PATCH] Add-on to gethostbyname2

[Pierre A. Humblet]

-Original Message-
From: Pierre A Humblet
Sent: Friday, January 23, 2015 9:30 AM

 From: Corinna Vinschen
 Sent: Friday, January 23, 2015 5:48 AM

 On Jan 22 21:05, Pierre A. Humblet wrote:
  Add-on to gethostbyname2, as discussed previously on main list.
  The diff is also attached.
 

 Do you have some wording for the release info in the docs, please?

Make gethostbyname2 handle numerical host addresses as well as the 
reserved domain names localhost and invalid.


Actually it should be numeric host addresses

Pierre

Updated: exim-4.84-1

[Pierre A Humblet]

A release of exim 4.84 (a Mail Transfer Agent) is now available in the
32-bit and 64-bit Cygwin distributions.

This is the first Cygwin 64-bit release of exim.

If you have questions or comments, please send them to the cygwin mailing
list at: cygwin (at) cygwin (dot) com ,
mentioning exim in the subject line.

Pierre

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look at
the List-Unsubscribe:  tag in the email header of this message. Send email
to the address specified there. It will be in the format:

 cygwin-announce-unsubscribe-you=yourdomain.com at cygwin.com

 If you need more information on unsubscribing, start reading here:

 http://sourceware.org/lists.html#unsubscribe-simple

 Please read *all* of the information on unsubscribing that is available
starting at this URL.

[ANNOUNCEMENT] Updated: exim-4.84-1

[Pierre A Humblet]

A release of exim 4.84 (a Mail Transfer Agent) is now available in the
32-bit and 64-bit Cygwin distributions.

This is the first Cygwin 64-bit release of exim.

If you have questions or comments, please send them to the cygwin mailing
list at: cygwin (at) cygwin (dot) com ,
mentioning exim in the subject line.

Pierre

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look at
the List-Unsubscribe:  tag in the email header of this message. Send email
to the address specified there. It will be in the format:

 cygwin-announce-unsubscribe-you=yourdomain.com at cygwin.com

 If you need more information on unsubscribing, start reading here:

 http://sourceware.org/lists.html#unsubscribe-simple

 Please read *all* of the information on unsubscribing that is available
starting at this URL.

--
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: cron 4.1

[Pierre A Humblet]

A new release of the Cygwin port of cron 4.1 is available in the 32-bit and
64-bit Cygwin distributions.

The change allows the cron-config script to handle new cron installations in
the upcoming Cygwin release, which does not rely on /etc/{password,group}.

Pierre

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com , mentioning cron in
the subject line.


  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look at
the List-Unsubscribe:  tag in the email header of this message. Send email
to the address specified there. It will be in the format:

 cygwin-announce-unsubscribe-you=yourdomain.com at cygwin.com

 If you need more information on unsubscribing, start reading here:

 http://sourceware.org/lists.html#unsubscribe-simple

 Please read *all* of the information on unsubscribing that is available
starting at this URL.

--
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

[PATCH] Add-on to gethostbyname2

[Pierre A. Humblet]

Add-on to gethostbyname2, as discussed previously on main list.
The diff is also attached.


Pierre

2015-01-22  Pierre A. Humblet pie...@phumblet.no-ip.org

* net.cc (cygwin_inet_pton): Declare.
(gethostby_specials): New function.
(gethostby_helper): Change returned addrtype in 4-to-6 case.
(gethostbyname2): Call gethostby_specials.



cvs diff -up net.cc
Index: net.cc
===
RCS file: /cvs/src/src/winsup/cygwin/net.cc,v
retrieving revision 1.322
diff -u -p -r1.322 net.cc
--- net.cc  20 Jan 2015 18:23:19 -  1.322
+++ net.cc  23 Jan 2015 00:02:22 -
@@ -72,6 +72,7 @@ extern C
   int __stdcall rcmd (char **ahost, unsigned short inport, char *locuser,
  char *remuser, char *cmd, SOCKET * fd2p);
   int sscanf (const char *, const char *, ...);
+  int cygwin_inet_pton(int, const char *, void *);
   int cygwin_inet_aton(const char *, struct in_addr *);
   const char *cygwin_inet_ntop (int, const void *, char *, socklen_t);
   int dn_length1(const unsigned char *, const unsigned char *,
@@ -1168,6 +1169,97 @@ memcpy4to6 (char *dst, const u_char *src
   memcpy (dst + 12, src, NS_INADDRSZ);
 }

+/* gethostby_specials: RFC 6761
+   Handles numerical addresses and special names for gethostbyname2 */
+static hostent *
+gethostby_specials (const char *name, const int af,
+   const int addrsize_in, const int addrsize_out)
+{
+  int namelen = strlen (name);
+  /* Ignore a final '.' */
+  if ((namelen == 0) || ((namelen -= (name[namelen - 1] == '.')) == 0))  {
+set_errno (EINVAL);
+h_errno = NETDB_INTERNAL;
+return NULL;
+  }
+
+  int res;
+  u_char address[NS_IN6ADDRSZ];
+  /* Test for numerical addresses */
+  res = cygwin_inet_pton(af, name, address);
+  /* Test for special domain names */
+  if (res != 1) {
+{
+  char const match[] = invalid;
+  int const matchlen = sizeof(match) - 1;
+  int start = namelen - matchlen;
+  if ((start = 0)  ((start == 0) || (name[start-1] == '.'))
+  (strncasecmp (name[start], match , matchlen) == 0)) {
+   h_errno = HOST_NOT_FOUND;
+   return NULL;
+  }
+}
+{
+  char const match[] = localhost;
+  int const matchlen = sizeof(match) - 1;
+  int start = namelen - matchlen;
+  if ((start = 0)  ((start == 0) || (name[start-1] == '.'))
+  (strncasecmp (name[start], match , matchlen) == 0)) {
+   res = 1;
+   if (af == AF_INET) {
+ address[0] = 127;
+ address[1] = address[2] = 0;
+ address[3] = 1;
+   }
+   else {
+ memset (address, 0, NS_IN6ADDRSZ);
+ address[NS_IN6ADDRSZ-1] = 1;
+   }
+  }
+}
+  }
+  if (res != 1)
+return NULL;
+
+  int const alias_count = 0, address_count = 1;
+  char * string_ptr;
+  int sz = DWORD_round (sizeof(hostent))
++ sizeof (char *) * (alias_count + address_count + 2)
++ namelen + 1
++ address_count * addrsize_out;
+  hostent *ret = realloc_ent (sz,  (hostent *) NULL);
+  if (!ret)
+{
+  /* errno is already set */
+  h_errno = NETDB_INTERNAL;
+  return NULL;
+}
+
+  ret-h_addrtype = af;
+  ret-h_length = addrsize_out;
+  ret-h_aliases = (char **) (((char *) ret) + DWORD_round (sizeof(hostent)));
+  ret-h_addr_list = ret-h_aliases + alias_count + 1;
+  string_ptr = (char *) (ret-h_addr_list + address_count + 1);
+  ret-h_name = string_ptr;
+
+  memcpy (string_ptr, name, namelen);
+  string_ptr[namelen] = 0;
+  string_ptr += namelen + 1;
+
+  ret-h_addr_list[0] = string_ptr;
+  if (addrsize_in != addrsize_out) {
+memcpy4to6 (string_ptr, address);
+ret-h_addrtype = AF_INET6;
+  }
+  else
+memcpy (string_ptr, address, addrsize_out);
+
+  ret-h_aliases[alias_count] = NULL;
+  ret-h_addr_list[address_count] = NULL;
+
+  return ret;
+}
+
 static hostent *
 gethostby_helper (const char *name, const int af, const int type,
  const int addrsize_in, const int addrsize_out)
@@ -1352,8 +1444,10 @@ gethostby_helper (const char *name, cons
  string_ptr += curptr-namelen1;
}
  ret-h_addr_list[address_count++] = string_ptr;
- if (addrsize_in != addrsize_out)
+ if (addrsize_in != addrsize_out) {
memcpy4to6 (string_ptr, curptr-data);
+   ret-h_addrtype =  AF_INET6;
+ }
  else
memcpy (string_ptr, curptr-data, addrsize_in);
  string_ptr += addrsize_out;
@@ -1405,7 +1499,10 @@ gethostbyname2 (const char *name, int af
  __leave;
}

-  res = gethostby_helper (name, af, type, addrsize_in, addrsize_out);
+  h_errno = NETDB_SUCCESS;
+  res = gethostby_specials (name, af, addrsize_in, addrsize_out);
+  if ((res == NULL)  (h_errno == NETDB_SUCCESS))
+ res = gethostby_helper (name, af, type, addrsize_in, addrsize_out);
 }
   __except (EFAULT) {}
   __endtry


net.cc.diff
Description

RE: Resolving localhost on Windows 7 (for exim)

[Pierre A. Humblet]

 -Original Message-
 From: Corinna Vinschen
 Sent: Tuesday, January 13, 2015 05:37
 
 On Jan 12 18:14, Corinna Vinschen wrote:
  On Jan 12 17:51, Corinna Vinschen wrote:
   On Jan 12 11:16, Pierre A. Humblet wrote:
Now the bad news:  the exim daemon crashes.
   
The reason is this:
$ getent passwd exim
NT SERVICE+exim:*:376394:376394:U-NT
SERVICE\exim,S-1-5-80-3213360373-4072665756-2198108471-
 1641386292-
839958090:/:/sbin/nologin
   
So even though I am requesting just exim I am getting an entry for NT
 SERVICE+exim
  
   That's definitely a bug and I can easily reproduce it.  I'm not sure
   yet how this happens, but this is really not ok.  I'll have a look ASAP.
 
  Oh darn, I especially *implemented* this behaviour, for the sake of
  being able to fetch the TrustedInstaller account by name.
 
  And then TrustedInstaller gets the account name NT
 SERVICE+TrustedInstaller
  anyway, so I'm rather puzzled what I was thinking back in November.
 
  Fitting: getent passwd NT SERVICE+servicename does *not* work,
  except for NT SERVICE+TrustedInstaller.  Oh well.
 
  I'll prepare a fix today or (more likely) tomorrow.
 
 Done.  I uploaded a snapshot with this change to
 https://cygwin.com/snapshots/  Please give it a try.

Works fine, thanks a lot.

Also earlier in this thread I reported that DnsQuery was sometime 
failing to resolve localhost with an error (not the question/answer snafu).
What happens is that if you ask e.g. to resolve localhost for a MX record,
DnsQuery answers that localhost does not exist and it repeats that answer
even for A and  record for the next 15-20 min (surely the TTL).
That's a bug I can live with (it may depend partially on the upstream
nameservers). It will be mitigated when I add functionality to
gethostbyname2 as discussed previously.

Pierre


--
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: Resolving localhost on Windows 7 (for exim)

[Pierre A. Humblet]

 -Original Message-
 From: Corinna Vinschen
 Sent: Thursday, January 08, 2015 08:24
 
 Hi Pierre,
 
 On Jan  5 09:03, Pierre A. Humblet wrote:
  While porting exim to Windows 64 I have observed strange results when
  resolving localhost
 
  On Windows XP,
 
  Resolv: search localhost type 28
  Resolv: query localhost type 28
  Resolv: DnsQuery: 0 (Windows)
  Resolv: localhost Section 0 Type 28 Windows Record Length 16
  08:02:06  3760 DNS lookup of localhost () succeeded
  Resolv: search localhost type 1
  Resolv: query localhost type 1
  Resolv: DnsQuery: 0 (Windows)
  Resolv: localhost Section 1 Type 1 Windows Record Length 4
  08:44:13  5552 DNS lookup of localhost (A) succeeded
 
  We see that for IPV4 localhost things are fine.
  Windows returns an answer section (1) and Cygwin processes it correctly.
 
  However for IPV6 it returned a question section (0) but with data in it.
  Cygwin essentially drops that.
  That's why above the application tried an A record after getting the
   record, which was empty.
 
 
  However of Windows 7
  CYGWIN_NT-6.1 Dell3020 1.7.33-2(0.280/5/3) 2014-11-13 15:47 x86_64
  Cygwin
 
  Resolv: search localhost type 28
  Resolv: query localhost type 28
  Resolv: DnsQuery: 0 (Windows)
  Resolv: localhost Section 0 Type 28 Windows Record Length 16
  08:22:24 140244 DNS lookup of localhost () succeeded
  Resolv: search localhost type 1
  Resolv: query localhost type 1
  Resolv: DnsQuery: 0 (Windows)
  Resolv: localhost Section 0 Type 1 Windows Record Length 4
 
  We see that Windows returns question sections in both cases and
  localhost is never resolved.
  From what I have seen Windows never returns question section in normal
  cases so I suggest inserting the following on line 251 of
  minires-os-if.c, to essentially turn question sections in answer
  sections (after  while (rr) { )
 
  if ((rr-Flags.DW  0x3) == 0) {
  DPRINTF(debug, Got section 0 %s %d with data length %d\n,
  DomName, Type, rr-wDataLength);
  if (rr-wDataLength  0)
  rr-Flags.DW |= 1; // Make it an answer section as
  there is data }
 
 Can you please send at least a real patch?  Without the formatting matching
 the surrounding code I'm totally unsure where to apply this code.  A
 ChangeLog entry would be helpful as well.

Here they are. 

cvs diff -up minires-os-if.c
Index: minires-os-if.c
===
RCS file: /cvs/src/src/winsup/cygwin/libc/minires-os-if.c,v
retrieving revision 1.15
diff -u -p -r1.15 minires-os-if.c
--- minires-os-if.c 23 Apr 2013 09:44:35 -  1.15
+++ minires-os-if.c 12 Jan 2015 03:39:27 -
@@ -249,6 +249,13 @@ static int cygwin_query(res_state statp,
rr = pQueryResultsSet;
section = 0;
while (rr) {
+/* Some Windows versions return questions when providing locally
+   generated answers, for example for localhost or for the computer name 
*/
+if (((rr-Flags.DW  0x3) == DnsSectionQuestion) 
+   (rr-wDataLength  0)) {
+  DPRINTF(debug, Changing record below from question to answer\n);
+  rr-Flags.DW ^= DnsSectionQuestion ^ DnsSectionAnswer;
+}
  if (!counts[0]  (rr-Flags.DW  0x3)) {
/* No question. Adopt the first name as the name in the question */
if ((len = dn_comp(rr-pName, ptr, AnsLength - 4,

2015-01-11  Pierre A. Humblet pie...@phumblet.no-ip.org

 * minires-os-if.c (cygwin_query): Change questions into answers.


  It would be nice if this would be tried ASAP.
  However I am not setup currently to build cygwin.
 
 It's not exactly tricky to set this up...

Right, I had it all downloaded and working in one evening.
CYGWIN_NT-6.1 Dell3020 1.7.34(0.283/5/3) 2015-01-11 18:48 x86_64 Cygwin

With the above changes localhost is resolved fine.
Now the bad news:  the exim daemon crashes.

The reason is this:
$ getent passwd exim
NT SERVICE+exim:*:376394:376394:U-NT 
SERVICE\exim,S-1-5-80-3213360373-4072665756-2198108471-1641386292-839958090:/:/sbin/nologin

So even though I am requesting just exim I am getting an entry for NT 
SERVICE+exim
Talk about aliasing.
The way the exim code works, when an exim user exists (per getpwnam) the 
daemon setuids to it.
Here it's trying to setuid to a service. 
This would break every exim installation.

Pierre



--
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

Resolving localhost on Windows 7 (for exim)

[Pierre A. Humblet]

While porting exim to Windows 64 I have observed strange results when 
resolving localhost


On Windows XP,

Resolv: search localhost type 28
Resolv: query localhost type 28
Resolv: DnsQuery: 0 (Windows)
Resolv: localhost Section 0 Type 28 Windows Record Length 16
08:02:06  3760 DNS lookup of localhost () succeeded
Resolv: search localhost type 1
Resolv: query localhost type 1
Resolv: DnsQuery: 0 (Windows)
Resolv: localhost Section 1 Type 1 Windows Record Length 4
08:44:13  5552 DNS lookup of localhost (A) succeeded

We see that for IPV4 localhost things are fine.
Windows returns an answer section (1) and Cygwin processes it correctly.

However for IPV6 it returned a question section (0) but with data in it.
Cygwin essentially drops that.
That's why above the application tried an A record after getting the 
 record, which was empty.



However of Windows 7
CYGWIN_NT-6.1 Dell3020 1.7.33-2(0.280/5/3) 2014-11-13 15:47 x86_64 Cygwin

Resolv: search localhost type 28
Resolv: query localhost type 28
Resolv: DnsQuery: 0 (Windows)
Resolv: localhost Section 0 Type 28 Windows Record Length 16
08:22:24 140244 DNS lookup of localhost () succeeded
Resolv: search localhost type 1
Resolv: query localhost type 1
Resolv: DnsQuery: 0 (Windows)
Resolv: localhost Section 0 Type 1 Windows Record Length 4

We see that Windows returns question sections in both cases and 
localhost is never resolved.
From what I have seen Windows never returns question section in 
normal cases so I suggest
inserting the following on line 251 of minires-os-if.c, to 
essentially turn question sections

in answer sections (after  while (rr) { )

if ((rr-Flags.DW  0x3) == 0) {
DPRINTF(debug, Got section 0 %s %d with data length %d\n, 
DomName, Type, rr-wDataLength);

if (rr-wDataLength  0)
rr-Flags.DW |= 1; // Make it an answer section as 
there is data

}
It would be nice if this would be tried ASAP.
However I am not setup currently to build cygwin.


Occasionally I also see localhost queries fail.
I have not been able to pinpoint what causes that.

Resolv: search localhost type 28
Resolv: query localhost type 28
Resolv: DnsQuery: 9003 (Windows)
08:00:14 145640 DNS lookup of localhost () gave HOST_NOT_FOUND
08:00:14 145640 returning DNS_NOMATCH
Resolv: search localhost type 1
Resolv: query localhost type 1
Resolv: DnsQuery: 9003 (Windows)


In light of RFC 6761 we should handle localhost in gethostbyname2, 
for both IP4 and IP6

While we are at it we should also handle numerical domains w.x.y.z there.
That's less urgent, I can do that in the coming weeks.
I
Pierre



--
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

group permission on 1.7.34

[Pierre A. Humblet]

ls -l appears to always report rwx for group on 1.7.34

$ uname -a
CYGWIN_NT-6.1 PHUMBLET-LAP01W 1.7.34(0.281/5/3) 2014-11-13 16:14 i686 Cygwin

phumblet@PHUMBLET-LAP01W ~
$ getfacl ~/.ssh
# file: /home/phumblet/.ssh
# owner: phumblet
# group: Domain Users
user::rwx
group::---
group:SYSTEM:rwx
group:Administrators:rwx
mask:rwx
other:---
default:user::rwx
default:user:phumblet:rwx
default:group::r-x
default:group:SYSTEM:rwx
default:group:Administrators:rwx
default:mask:rwx
default:other:r-x


$ ls -ld ~/.ssh
drwxrwx---+ 1 phumblet Domain Users 0 Jan 10  2011 /home/phumblet/.ssh

The group perms should be ---

Also /winsup/Cygwin in cvs on the web only shows ChangeLogs and
subdirectories

Pierre


--
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: TEST RELEASE: Cygwin 1.7.33-0.8

[Pierre A. Humblet]

 -Original Message-
 From: Corinna Vinschen
 Sent: Mon, 10 Nov 2014 12:09:17 +0100
 On Nov  7 13:04, Pierre A. Humblet wrote:
   -Original Message-
   From: Pierre A. Humblet 
   Sent: Thursday, November 06, 2014 16:09
   
-Original Message-
 From: Corinna Vinschen
Sent: Thursday, November 06, 2014 13:51
   
On Nov  6 13:38, Kelley Cook wrote:
 On Thu, Nov 6, 2014 at 10:52 AM, Corinna Vinschen wrote:
  Hi Cygwin friends and users,
 
 
  I just released a 7th TEST version of the next upcoming Cygwin
  release, 1.7.33-0.7.
 

 I discovered that /usr/bin/cron-config which is part of the cron
 package will need to be updated as it attempts to parse /etc/group
.
  
Right, it should use getent instead.  Pierre?
  
snip
  I just realized that deleting the /etc/passwd file in existing domain
  systems may change usernames, which will break cron and other programs
  that use files named after usernames. Also the (local) privileged
  username will change.

 Yes.  Is there a way to accommodate that?  Maybe a postinstall script
 checking for existing user cron files and renaming them if required?

That's possible but it must be a postinstall than runs when an updated
Cygwin is installed (or deinstalled), not when cron is, except if we try to
synchronize both.

 The privileged user name shouldn't matter much after configuration.

Agreed, but see below

 For now I have made the following changes to cron-config:
   calling getent
   checking if /etc/passwd exists
   dealing with the extended names for privileged users (they may
   contain a +, don't use EREs)  

 I just scanned it quickly, but the change looks good.

OK. Do you want to produce a test release for the crons?

snip

 Note also the discussion with Christian starting at
 https://cygwin.com/ml/cygwin/2014-11/msg00095.html

I am fine with the prefix but there is something we should agree on about
the special 
privileged names like cyg_server.

What I did is to create an entry for them in /etc/passwd. The reason is that
the shell 
is changed to /bin/false and I don't want to deal with setting that in the
Windows 
databases (I can't test all possible variations).
Now when we create a passwd entry, we can include the prefix, as I did, or
remove it.
csih and the other similar scripts should agree on that, otherwise they may
reuse
the privileged user (based on the Windows database) but create different
passwd entries.
Of course removing the prefix can create a conflict with a cyg_server domain
user.

Pierre




--
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: TEST RELEASE: Cygwin 1.7.33-0.7

[Pierre A. Humblet]

 -Original Message-
 From: Pierre A. Humblet 
 Sent: Thursday, November 06, 2014 16:09
 
  -Original Message-
  From: Corinna Vinschen
  Sent: Thursday, November 06, 2014 13:51
 
  On Nov  6 13:38, Kelley Cook wrote:
   On Thu, Nov 6, 2014 at 10:52 AM, Corinna Vinschen wrote:
Hi Cygwin friends and users,
   
   
I just released a 7th TEST version of the next upcoming Cygwin
release, 1.7.33-0.7.
   
  
   I discovered that /usr/bin/cron-config which is part of the cron
   package will need to be updated as it attempts to parse /etc/group .
 
  Right, it should use getent instead.  Pierre?
 
 Right, and ditto for exim config and postinstall How much time do I have?
 
 Now cron-config checks if a username appears multiple times in passwd.
 Typically one instance is a domain id and the other one is a local id.
 That causes havoc with cron
 It happens fairly frequently; there was even such a bug report recently.
 
 How does getent handle that case? Is it detectable from a config file?
 
Corinna

I just realized that deleting the /etc/passwd file in existing domain systems 
may change usernames, which will break cron and other programs that use files 
named after usernames. Also the (local) privileged username will change.

For now I have made the following changes to cron-config:
  calling getent
  checking if /etc/passwd exists
  dealing with the extended names for privileged users (they may contain a +, 
don't use EREs)  
Do you intend to keep mkpasswd/mkgroup ?

I still don't have a 64 bit system, but it's coming this year. It will take me 
some time to prepare a new cron package and get familiar with the new package 
upload procedure. 
I am attaching a cron-config diff. Feel free to update the 32 and 64 bit cron 
packages if you want that done quickly.
cronbug does not seem to require any changes.

Pierre



cron-config.diff
Description: Binary data
--
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: TEST RELEASE: Cygwin 1.7.33-0.7

[Pierre A. Humblet]

 -Original Message-
 From: Corinna Vinschen 
 Sent: Thursday, November 06, 2014 13:51
 
 On Nov  6 13:38, Kelley Cook wrote:
  On Thu, Nov 6, 2014 at 10:52 AM, Corinna Vinschen wrote:
   Hi Cygwin friends and users,
  
  
   I just released a 7th TEST version of the next upcoming Cygwin
   release, 1.7.33-0.7.
  
 
  I discovered that /usr/bin/cron-config which is part of the cron
  package will need to be updated as it attempts to parse /etc/group .
 
 Right, it should use getent instead.  Pierre?
 
Right, and ditto for exim config and postinstall
How much time do I have?

Now cron-config checks if a username appears multiple times in passwd.
Typically one instance is a domain id and the other one is a local id.
That causes havoc with cron
It happens fairly frequently; there was even such a bug report recently.

How does getent handle that case? Is it detectable from a config file?

Pierre


--
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: MTA packaging (exim, postfix, sendmail, ssmtp)

[Pierre A. Humblet]

 -Original Message-
 From: Christian Franke
 Sent: Wednesday, October 08, 2014 12:32
 
 Yaakov Selkowitz wrote:
  On 2014-10-08 07:52, Corinna Vinschen wrote:
  On Oct  6 17:19, Yaakov Selkowitz wrote:
  Because MTAs must be user-configured, and we certainly don't want to
  lose the selection during package upgrades, the alternatives cannot
  be handled in package postinst/prerm.  I think the only way to make
  this work is for each MTA config script to handle these instead by
  including the following snippets in the respective MTA config
  scripts.
 
  Please review this carefully in case I missed anything.
 
  The ssmtp part looks ok to me.  Two questions:
 
  - Don't we have to add something to preremove as well?
 
  No, because we don't distinguish between removing and upgrading a
  package in preremove.  Whenever a user wishes to switch MTAs, they
  will need to run alternatives --set, preferably via the MTA config
  scripts.
 
 The cron package is also affected. Its postinstall script sets a symlink
 /usr/sbin/sendmail - /usr/bin/cronlog if sendmail does not exist. This
would
 break alternatives setting in MTA configure script because alternatives
would
 never replace the existing symlink.
 
 Possible workaround: Add rm -f /usr/sbin/sendmail ... to MTA configure
 scripts.

I was going to mention that and suggest to add another alternative in
cron-config 
/usr/sbin/alternatives --install /usr/sbin/sendmail mta /usr/bin/cronlog 0 

That way all cases are treated uniformly.
I don't dispute that it may be safer to rm the old (pre alternatives)
sendmail, mailq, etc links before installing with alternatives 
  
I am fine with the proposal for exim, except that I was not planning to add
rmail, rsmtp, and runq
Those are for compatibility with smail. 
I never included them in the cygwin distribution and nobody  has ever
complained.

Also exim itself can run perfectly fine if the mta alternatives is set to
another mta, except that mailq and sendmail won't call exim.
So in exim-config I was going to present the current mta alternative to the
user, explain the above, and ask if it should be changed.

Pierre

RE: MTA packaging (exim, postfix, sendmail, ssmtp)

[Pierre A. Humblet]

 -Original Message-
 From: Yaakov Selkowitz Sent: Wednesday, October 08, 2014 13:59
 
 On 2014-10-08 12:01, Pierre A. Humblet wrote:
  -Original Message-
  I was going to mention that and suggest to add another alternative in
  cron-config /usr/sbin/alternatives --install /usr/sbin/sendmail mta
  /usr/bin/cronlog 0
 
 Except that cronlog isn't a real MTA.  What I think should happen instead
is
 cron should use cronlog if sendmail isn't present.

That means a change to the C code, much easier to do it in cron-config.
What's the harm?
cronlog prints an error message if it is not called from cron, so trying to
use it as an mta will fail immediately, with feedback to the user.
  
  Also exim itself can run perfectly fine if the mta alternatives is set
  to another mta, except that mailq and sendmail won't call exim.
  So in exim-config I was going to present the current mta alternative
  to the user, explain the above, and ask if it should be changed.

In some cases (don't want to start a long discussion) it makes sense for
applications to send mail with ssmtp, which can be configured to send the
mail to exim running on localhost. That can be done by setting the mta to
ssmtp, as applications look for sendmail.

 IOW /usr/bin/exim can be called directly?  True, and I suspect that would
be
 the case for the other MTAs (certainly ssmtp).  But in that case, is there
a
 need to run exim-config?

There is a ton of other stuff to do in exim-config, from setting the
hostname the outside world should see to calling cygrunsrv the right way.

Pierre

RE: MTA packaging (exim, postfix, sendmail, ssmtp)

[Pierre A. Humblet]

 -Original Message-
 From: Yaakov Selkowitz
 Sent: Thursday, August 28, 2014 19:25

 Corinna, Christian, Daniel, Pierre,
 
 While I'm working out the details of allowing all your MTA packages to
 coexist, it would be helpful if you could clarify under what
circumstances, if
 any, you expect that your MTA could function as /usr/sbin/sendmail for the
 purposes of sending outgoing mail without any configuration on the part of
 users.

Exim could send outgoing mail out of the box if the destination server can
be reached using dns.
With many ISPs blocking port 25, a gateway must usually be configured.  
Of course a MTA does much more than sending outgoing mail, and that requires
configuring a service etc...
Because of that Exim is not currently packaged to do anything without
requiring configuration (in fact, out of the box exim is a symlink to
exim-config) , but it would not be hard to allow it.

Pierre

RE: [ITP] Sendmail 8.14.9

[Pierre A. Humblet]

 -Original Message-
 From: Corinna Vinschen
 Sent: Thursday, August 28, 2014 12:00
 
 On Aug 28 12:27, Corinna Vinschen wrote:
  On Aug 27 11:16, Pierre A. Humblet wrote:
From:  Corinna Vinschen
Anyway, to have some working example, here's how Fedora does it:
   
The binaries, or symlinks to the actual binaries are called:
   
  /usr/sbin/sendmail.sendmail
  /usr/bin/mailq.sendmail
  /usr/bin/newaliases.sendmail
   
  /usr/sbin/sendmail.exim
  /usr/bin/mailq.exim
  /usr/bin/newaliases.exim
   
  /usr/sbin/sendmail.postfix
  /usr/bin/mailq.postfix
  /usr/bin/newaliases.postfix
   
  [analog for other MTAs]
   
Sendmail, mailq, newalias (etc.) are alternatives symlinks:
   
  /usr/sbin/sendmail - /etc/alternatives/mta
  /usr/bin/mailq - /etc/alternatives/mta-mailq
  /usr/bin/newaliases - /etc/alternatives/mta-newaliases
   
And in /etc/alternatives are the symlinks to the actual binaries,
as configured by postinstall or the user:
   
  /etc/alternatives/mta - /usr/sbin/sendmail.exim
  /etc/alternatives/mta-mailq - /usr/bin/mailq.exim
  /etc/alternatives/mta-newaliases - /usr/bin/newaliases.exim
   
In fact, there are more than these three symlinks, mainly to rmail
and to the man pages for the aforementioned binaries.
   
Maybe we can shamelessly borrow this scheme?!?
   
  
   I am fine with the idea, except that I don’t see the need for things
   such as /usr/sbin/sendmail.exim The executables can be installed in
   the current locations (/usr/bin for exim) and symbolic links such as
   /etc/alternatives/mta can point directly to the executables.
 
  That's ok, I guess.
 
   Also it
   looks like we don't need to use the alternatives package itself,
   although we reuse the /etc/alternatives directory and naming scheme
  
   Below is what I would do in the MTA postinstall and -config files,
   using mailq as an example I am assuming that /usr/bin/mailq will not
   be created by setup.
  
   In the postinstall:
   If /usr/bin/mailq is a symbolic link NOT already pointing to
   /etc/alternatives/mta-mailq {
  create a symbolic link /etc/alternative/mta-mailq pointing to
 /usr/bin/mailq's target
  replace the target of /usr/bin/mailq to
   /etc/alternatives/mta-mailq } else if /usr/bin/mailq is a file {
  rename /usr/bin/mailq to /usr/bin/mailq.somemta
 create a symbolic link /etc/alternatives/mta-mailq pointing to
 /usr/bin/mailq.somemta
 create a symbolic link /usr/bin/mailq to
   /etc/alternatives/mta-mailq
 
 This part won't work as expected btw.  If the sendmail package installs the
 actual binaries under the names reserved for the symlinks to the user-
 defined MTA tools, then you change the installation.
 
 Consider what happens when you have an exim installation and deliberately
 or accidentally install sendmail:  It will overwrite your symlinks and break a
 perfectly fine exim installation.
 
 Same when uninstalling: Assuming you have exim and sendmail installed,
 with the symlinks pointing to exim, then you uninstall the sendmail package.
 Setup will remove the symlinks but the mailq.somemta
 binaries will stay in /usr/bin since setup doesn't know about them.
 
 I think the right thing to do would be to install either renamed binaries, as
 Fedora does it, or to keep the names and install the binaries into some
 different directory (perhaps something like
 /usr/lib/sendmail/bin) and symlink to this dir.

I was assuming that from now on no package would ever install /usr/bin/mailq 
(etc). Only postinstalls would create it. 
With that assumption, I don't understand what you mean but I may not have given 
enough info.

The stuff in the postinstall is only meant for the transition phase when 
/usr/bin/mailq (etc) is NOT pointing to /etc/alternatives/mta-mailq.

Today the only Cywin package creating /usr/bin/mailq is exim, AFAIK. It is a 
symlink pointing to /usr/bin/exim. If an updated exim is installed before 
sendmail, setup should have removed the old /usr/bin/mailq, a new one will be 
created in the postinstall as outlined and things will be OK.

If for some reason the old one is not removed (or if sendmail is installed 
before exim is reinstalled), /usr/bin/mailq will be set to point to 
/etc/alternatives/mta-mailq, which be set to point to /usr/bin/exim. So the 
exim installation is OK.

The case where /usr/bin/mailq is a file is only meant to cover the case where a 
user has compiled and installed some package (not through setup) that contains 
a binary /usr/bin/mailq. It would be renamed to mailq.somemta, not breaking 
anything.

But you are right that there is a flaw: if sendmail is installed before exim is 
updated, the sendmail postinstall will have created the new link, eventually 
pointing to exim. Exim would keep working fine. The user could then (during 
sendmail-config)  change the link to point to sendmail. If the user

RE: [ITP] Sendmail 8.14.9

[Pierre A. Humblet]

 -Original Message-
 From:  Corinna Vinschen
 Sent: Tuesday, August 26, 2014 14:50
 
 On Aug 26 09:51, Pierre A. Humblet wrote:
   -Original Message-
   From:  Yaakov Selkowitz
   Sent: Friday, August 22, 2014 17:40
  
   On 2014-08-22 13:19, D. Boland wrote:
On Aug 22 07:43, D. Boland wrote:
I re-packaged Sendmail with cygport. See:
   
http://cygwin.boland.nl/x86/release/sendmail/
   
Packaging looks good in theory.
   
Unfortunately we have a problem.
   
On inspection of your binary package I noticed that we have
conflicts with exim and ssmtp packages:
   [snip]
 
  Whatever we do should be transparent to users who have already
  installed ssmtp or exim and are updating to a newer version.
 
 I guess that's exactly the problem.  Consider somebody has installed exim or
 ssmtp and then installs sendmail accidentally or out of curiosity.  This
 immediately overwrites the symlinks and even if the user never actually uses
 sendmail, the MTA installation is broken.
 
 I don't have a clear concept yet if and how we should use alternatives to fix
 this problem.
 
 Anyway, to have some working example, here's how Fedora does it:
 
 The binaries, or symlinks to the actual binaries are called:
 
   /usr/sbin/sendmail.sendmail
   /usr/bin/mailq.sendmail
   /usr/bin/newaliases.sendmail
 
   /usr/sbin/sendmail.exim
   /usr/bin/mailq.exim
   /usr/bin/newaliases.exim
 
   /usr/sbin/sendmail.postfix
   /usr/bin/mailq.postfix
   /usr/bin/newaliases.postfix
 
   [analog for other MTAs]
 
 Sendmail, mailq, newalias (etc.) are alternatives symlinks:
 
   /usr/sbin/sendmail - /etc/alternatives/mta
   /usr/bin/mailq - /etc/alternatives/mta-mailq
   /usr/bin/newaliases - /etc/alternatives/mta-newaliases
 
 And in /etc/alternatives are the symlinks to the actual binaries, as 
 configured
 by postinstall or the user:
 
   /etc/alternatives/mta - /usr/sbin/sendmail.exim
   /etc/alternatives/mta-mailq - /usr/bin/mailq.exim
   /etc/alternatives/mta-newaliases - /usr/bin/newaliases.exim
 
 In fact, there are more than these three symlinks, mainly to rmail and to the
 man pages for the aforementioned binaries.
 
 Maybe we can shamelessly borrow this scheme?!?
 

I am fine with the idea, except that I don’t see the need for things such as 
/usr/sbin/sendmail.exim
The executables can be installed in the current locations (/usr/bin for exim) 
and symbolic links such as /etc/alternatives/mta can point directly to the 
executables.
Also it looks like we don't need to use the alternatives package itself, 
although we reuse the /etc/alternatives directory and naming scheme

Below is what I would do in the MTA postinstall and -config files, using mailq 
as an example
I am assuming that /usr/bin/mailq will not be created by setup.

In the postinstall:
If /usr/bin/mailq is a symbolic link NOT already pointing to 
/etc/alternatives/mta-mailq {
   create a symbolic link /etc/alternative/mta-mailq pointing to 
/usr/bin/mailq's target
   replace the target of /usr/bin/mailq to /etc/alternatives/mta-mailq
}
else if /usr/bin/mailq is a file {
   rename /usr/bin/mailq to /usr/bin/mailq.somemta
  create a symbolic link /etc/alternatives/mta-mailq pointing to 
/usr/bin/mailq.somemta
  create a symbolic link /usr/bin/mailq to /etc/alternatives/mta-mailq
}
else if /usr/bin/mailq does not exist {
  create a symbolic link /usr/bin/mailq pointing to 
/etc/alternatives/mta-mailq
  if the MTA has been installed previously (like, old configuration or 
log files already exists) {
  create a symbolic link  /etc/alternatives/mta-mailq pointing to a 
suitable target (if any, created by setup) for the MTA being installed
  }
}
The point of the above is not to break existing installations when updating.
Unexpected cases (like /usr/bin/mailq is a directory) are handled in the 
MTA-config file.

In the MTA-config file executed by the user
- verify that /usr/bin/mailq is a symbolic link to /etc/alternatives/mta-mailq, 
fix the situation if necessary
- present a dialog to the user with the current value of the target and ask if 
it should be changed to the current MTA

Pierre

RE: [ITP] Sendmail 8.14.9

[Pierre A. Humblet]

 -Original Message-
 From:  Yaakov Selkowitz
 Sent: Friday, August 22, 2014 17:40
 
 On 2014-08-22 13:19, D. Boland wrote:
  On Aug 22 07:43, D. Boland wrote:
  I re-packaged Sendmail with cygport. See:
 
  http://cygwin.boland.nl/x86/release/sendmail/
 
  Packaging looks good in theory.
 
  Unfortunately we have a problem.
 
  On inspection of your binary package I noticed that we have conflicts
  with exim and ssmtp packages:
 [snip]
  What we'll have to do to fix this problem is to convert all three
  packages to use alternatives.  The alternatives package exists and is
  already used by a couple of other packages which would otherwise
  conflict, so there's precendent.  And on Fedora, the various mail
  packages all use alternatives, too, to install their packages in
  parallel and conflict-free.
 [snip]
 
 
  Why not let the user choose one program? Putting both Exim and
  Sendmail on one box is confusing, to say the least. Sendmail is very
  tough to understand. You don't want another (very similar looking) mail
 exchanger to add to the confusion.
 
 Cygwin's setup*.exe does not support the concept of conflicts (one
 package blocking others from being installed), nor does it prevent file
 clobbering if multiple packages provide the same file.  Since there is no
way
 to stop multiple MTAs from being installed, it is necessary to insure that
they
 do so properly.
 
 This needs to be handled properly, that's all, and that can take time.
 If Pierre doesn't respond soon, we can step in to help with exim.
 
I should have time one evening this week to do whatever it takes. 
However I am not sure we need alternatives to handle conflicts in this case.
In the exim package /usr/bin/mailq and /usr/bin/newaliases are just symbolic
links to exim (newaliases is just a noop provided only to keep some 3rd
party scripts from failing). It would be easy to pull them out of the
package and to recreate them under user control in the exim config script.
Hopefully other MTAs can do something similar.
The symbolic link /usr/sbin/sendmail is not used by exim. It can be set from
the exim config script to allow third party programs to find the local MTA.

Whatever we do should be transparent to users who have already installed
ssmtp or exim and are updating to a newer version.

Pierre

RE: Unable to get cygwin cron to work

[Pierre A. Humblet]

 -Original Message-
 From: cygwin-owne at cygwin.com on Behalf Of Denis
 Sent: Friday, August 15, 2014 21:39
 
 I'm trying unsuccesfully to get cron to work under 64-bit cywin under Win7
 Pro.  First, I tried running as myself (running cygwin with system
 administrator privilege):
 
 $ cron-config
 Do you want to install the cron daemon as a service? (yes/no) yes Enter
the
 value of CYGWIN for the daemon: [ ]
 
 Do you want the cron daemon to run as yourself? (yes/no) yes
 
 WARNING: User dkertz appears 2 times in /etc/passwd.
 This may confuse the system
 Edit /etc/passwd and assign unique user ids.
 
snip

 From the above you can see the warning about my login appearing twice in
 /etc/passwd:
 
 $ grep dkertz /etc/passwd
 dkertz:unused:1003:513:dkertz,U-USNAVN0D011H46\dkertz,
 S-1-5-21-2470246883-414681431-158823764-1003:/home/dkertz:/bin/bash
 dkertz:unused:295587:10513:U-NA02\dkertz,
 S-1-5-21-2112754840-354624142-596004286-
 285587:/home/dkertz:/bin/bash
 
 USNAVN0D011H46 is the PC machine name and NA02 is the domain set up by
 corporate IT.  Does this suggest IT has messed up?  I log into the PC
using the
 na02\dkertz login.
 
 Thinking this login duplication might be the problem, I changed
/etc/passwd
 to contain only the first login and then only the second login with the
same
 results - logon failure when running cron-config.
 
snip
 
 Now the cron runs but a scheduled cron job doesn't run and this is what
the
 cronevents shows:
 
 2014/08/15 19:41:01 [SYSTEM] /usr/sbin/cron: PID 4692: (dkertz) WRONG
 FILE OWNER (tabs/dkertz)
 

There is no doubt that your problems are caused by the duplicate entry.
There is no enough info to explain everything but note that according to
http://cygwin.com/ml/cygwin/2014-02/msg00306.html
when an entry can't be found in /etc/passwd it is now autogenerated.

So I suggest that you try the following to sort things out better:
- restore the original /etc/passwd with the 2 dkertz
- manually edit /etc/passwd and rename one of them, for example one of them
to NA02_dkertz
- if you have renamed the dkertz you have login with, log out of Cygwin and
start a new shell
- make sure the crontab in /var/cron/tabs/ has the name of and is owned by
the dkertz you want, and is readable by administrators
- try starting cron again. If starting as yourself, make sure you are the
one who owns the crontab.
Sorry I can't help more, but I don' have a 64 bit system nor easy access to
a domain account and I have not kept track with the way Cygwin maps user
names.

Pierre

 


--
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: Minires truncates host names

[Pierre A. Humblet]

 -Original Message-
 From: D. Boland
 Sent: Sunday, July 06, 2014 03:08
 
 Thanks for the swift reply!
 
 I looked at Sendmails' source code. Here's the snippet which produces 
 the output from my first email. It's taken from the file
sendmail/domain.c:
 
 sm_dprintf(dns_getcanonname: trying %s.%s
(%s)\n,
 host, *dp, # if NETINET6
 qtype == T_ ?  :
 # endif /* NETINET6 */
 qtype == T_A ? A :
 qtype == T_MX ? MX :
 ???);
 errno = 0;
 ret = res_querydomain(host, *dp, C_IN, qtype,
   answer.qb2, sizeof(answer.qb2));
 
 
 As you can see, it first prints the host to be looked up, and then 
 passes the string unaltered to res_querydomain.
 

You are right, there is a bug in res_querydomain, 
Line 737 *(ptr++ - 1) = '.';   should be
*ptr++ = '.';
 
I would also add a debug printf at the top of the function:
DPRINTF(statp-options  RES_DEBUG, querydomain \%s\  \%s\ type %d\n,
Name, DomName, Type);

Unfortunately I am not setup to build Cygwin so I can't test the above nor
submit a proper patch.

Pierre


--
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: Minires truncates host names

[Pierre A. Humblet]

 -Original Message-
 From: D. Boland
 Sent: Saturday, July 05, 2014 16:12
 
 Hi Group,
 
 I finally got Sendmail ported to Cygwin. But when looking up valid
hostnames
 from sender addresses, Minires fails. Here's the output, testing one of
 Sendmails' rules.
 
 $ echo check_mail dan...@cygwin.com | /usr/sbin/sendmail -d8.20 -bt
 readcf: option TrustedUser may cause problems on systems
 which do not support fchown() if UseMSP is not set.
 ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter ruleset
 address
  check_mail input: daniel @ cygwin . com
 Basic_check_mail   input: daniel @ cygwin . com
 tls_client input: $| MAIL
 TLS_connection input:
 TLS_connection   returns:
 tls_client   returns:
 CanonAddr  input:  daniel @ cygwin . com 
 canonify   input:  daniel @ cygwin . com 
 Canonify2  input: daniel  @ cygwin . com 
 dns_getcanonname(cygwin.com, trymx=1)
 dns_getcanonname: trying cygwin.com. (A)
 Minires: query cygwin.co. type 1
 Minires: DnsQuery: 9003 (Windows)
 NO: errno=0, h_errno=1
 Canonify2returns: daniel  @ cygwin . com 
 canonify returns: daniel  @ cygwin . com 
 Parse0 input: daniel  @ cygwin . com 
 Parse0   returns: daniel  @ cygwin . com 
 CanonAddrreturns: daniel  @ cygwin . com 
 Basic_check_mail returns: $# error $@ 5 . 1 . 8 $: 553 Domain of sender
 address  
 does not exist
 check_mail   returns: $# error $@ 5 . 1 . 8 $: 553 Domain of sender
 address  
 does not exist
 
 
 As can be seen, Minires queries cygwin.co., not cygwin.com. Is this a
 bug? Is there a way to test Minires lookups outside of Sendmail?

The Minires output above is produced at the top of the res_nquery function
by the following lines

int res_nquery( res_state statp, const char * DomName, int Class, int Type, 
695 unsigned char * AnsPtr, int AnsLength) 
696 { 
697   u_char packet[PACKETSZ]; 
698   int len; 
699  
700   DPRINTF(statp-options  RES_DEBUG, query \%s\ type %d\n, DomName,
Type);  

To me it looks like the string was already truncated when it was passed to
the function.

You can test e.g. by using exim -d+resolver  -bt   dan...@cygwin.com

It's wonderful that you got sendmail to work.

Pierre
 



--
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: HEADSUP: New getent tool to read passwd and group data

[Pierre A. Humblet]

 From:  Corinna Vinschen
 Sent: Friday, February 21, 2014 15:28
 On Feb 21 12:47, Pierre A. Humblet wrote:
   From: cygwin-apps-owner[...]
On Behalf Of Corinna Vinschen
   Sent: Thursday, February 20, 2014 14:38
   To: cygwin-apps[...]
  
   Hi guys,
  
  
   I just uploaded the new getent package and sent the announcement,
  
   I'm repeating myself here because this is really important and I'm
   not sure everybody on this list reads the cygwin and cygwin-announce
 lists.
  
   In short, we want to get rid of the requirement to maintain
   /etc/passwd and /etc/group files, per
   http://cygwin.com/ml/cygwin/2014-02/msg00306.html
  
   In future, tools and scripts, especially service installation helper
   scripts like my ssh-host-config, must not rely on being able to grep
   user and group information from /etc/passwd and /etc/group.
  
   Rather, the scripts should be changed to use the getent tool as soon
   as possible.  Usage for checking passwd:
  
 $ getent passwd username...
  
   I'd like to ask all maintainers providing such scripts, including
   myself, to look into their packages and fix them to use the getent tool.
  
 
  Corinna,
 
  For packages such as exim we need to find the uid of System and of
 Administrator, which the user can set any which way in passwd.
  So we lookup the SID (not the username) to get the uid (or gid).
 
 The SID of the administrator or the SID of the administrors group?
 The SID of the local administrator makes only marginal sense to me.
 What do you need it for?

I mean the administrators group.
It's needed for example to set the ownership of the configuration file.
The daemon checks that the file is owned/writable only by privileged users.
Similarly in cron the crontab files need to be readable by admins. cronbug 
checks for that
 
  Is there an equivalent mechanism using getent ?
  Else, could Cygwin disregard the passwd entries for these 2 users and use
 only the fixed values determined by the mapping from Windows?
 
 You should not have to expect a name change for the SYSTEM and the
 Administrators account.  It should be entirely sufficient to check for the 
 user
 Administrator and the user SYSTEM or +SYSTEM.  

Is that independent of local language?

 If you really want to check
 by SID, feel free to enumerate all accounts by just omitting the username and
 scan for the SID you're looking for:

   $ getent passwd | grep ',S-1-5-32-544:'
 
   $ getent group | grep ':S-1-5-18:'

OK, thanks, that will work. 
We have had cases of people in very large organizations trying to build the 
password with mkpasswd -d and that ended up taking hours. Won't the above run 
in the same issue?  This needs to run in postinstall.

Pierre
 

[RFU] exim-4.80.1-1

[Pierre A. Humblet]

Please upload exim-4.80.1-1 from

ftp://phumblet.no-ip.org/exim-4.80.1-1/exim-4.80.1-1.tar.bz2
ftp://phumblet.no-ip.org/exim-4.80.1-1/exim-4.80.1-1-src.tar.bz2
ftp://phumblet.no-ip.org/exim-4.80.1-1/setup.hint

and keep exim-4.76-1.

Pierre

RE: Maintainers please weigh in on 64-bit Cygwin

[Pierre A. Humblet]

 From: cygwin-apps-ow...@cygwin.com 
 
 I'd like to have a feel for how the 64-bit version of Cygwin will impact
package
 maintainers.
 
 So, I'd appreciate some discussion about this.
 
 1) Do you have a 64-bit version of Windows available?
No
 2) If no, would you be willing to install one?
Not in the short run
 3) Are you willing to download the current 64-bit Cygwin and start porting
 your stuff, knowing that there are still bugs?
N/A
 4) Or, would you rather wait for 64-bit to be completely stable before
 attempting anything?
Yes, preferably with cross-compiling
 5) Does the existence of two different architectures make you think that
it is
 time for you to stop offering the package?
No
 6) Would you be willing to have another person doing the 64-bit port for
you?
Yes. It would then make sense for that person to handle both versions.
 7) Are you ok with a 64-bit alpha release being made available which
contains
 your packages built by someone else?
Yes
 There are probably other considerations that I haven't thought of.  Any
 insights welcome.

Pierre

ls / under chroot

[Pierre A. Humblet]

The following output was observed when implementing anonymous ftp (chrooted)
on XP with the latest Cygwin
Looks like the /cygdrive, /dev and /proc entries are generated even for
chrooted /

ftp ls
200 PORT command successful.
150 Opening ASCII mode data connection for '/bin/ls'.
total 24
dr-xr-xr-x  1 Guest None  0 Nov  5 21:37 cygdrive
dr-xr-xr-x  1 Guest None  0 Nov  5 21:37 dev
-rw-r-  1 Guest None  46956 Nov  5 20:17 ftpd.c
proc: No such file or directory
226 Transfer complete.

Pierre


--
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 mounts not detected by cronjob

[Pierre A. Humblet]

 -Original Message-
 From: Sandile Mnqayi
 Sent: Wednesday, January 18, 2012 08:01
 
 Hello,
 
 Please suggest a solution to the issue of the cygwin mounts not being
visible to
 the cronjobs.
 
  echo 'D:/Program\040Files/International\0407.0 /usr/local/bin ntfs binary
0 0'
  /etc/fstab I have performed above mount and cron does not see this
entry, please advise?

I am not sure when edits to /etc/fstab become active. Is it shown by mount?
Also is D a local disk or a network drive? If the latter, use the
//machine/share format
as the letter drives need not be the same under Cron.
Note that if it's a network drive you may also have access issues that can
be fixed by
running cron as yourself or by using advanced authentication methods,
see /usr/share/doc/Cygwin/cron-.README

Pierre


--
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: cron still not working - even after rerunning cron config

[Pierre A. Humblet]

 -Original Message-
 From:  Mike Brown
 Sent: Friday, December 16, 2011 15:31
 To: cygwin mail list
 
 I desperately need to get this fixed as I will be leaving for a trip on
the 20th and
 have some cron stuff to run while I am gone.
 
 I ran cron-diagnose.sh, which now runs the cron-config, and changed from
just-
 me to local system and that still didn't fix the problem.  A ps -eaf shows
that
 cron is now UID SYSTEM and not 0.  But that did not make a difference.  I
set up
 the following entry in my crontab:
 
 12 14 * * *   touch /tmp/crontest
 
 The time came and went and no zero length file showed up.
 
 Running cronevents, the list had the following error line:
 
 2011/12/16 14:12:01 [SYSTEM] /usr/sbin/cron: PID 2524: (Vidiot) WRONG FILE
 OWNER (tabs/Vidiot)
 
 Which file is it exactly complaining about?  My crontab file, which worked
 under 1.5?  What is needed to fix it?  Where is the crontab file placed?

Yes, it is in /var/cron/tabs/
Problems like this have been reported when a user  is both a local user
and a domain user (2  entries in /etc/passwd).
Cron with suid to the 1st matching passwd entry 
  
Pierre



--
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: exim-4.76-1 fails to remove lock from spooler on delivery

[Pierre A. Humblet]

 -Original Message-
 From: cygwin-owner on behalf Of Corinna Vinschen
 Sent: Thursday, October 27, 2011 3:47 AM
 
 On Oct 26 16:33, Pierre A. Humblet wrote:
snip
  I was able to replicate the problem on Windows 7:
  The delivery process crashes because it can't load winmm.dll
 
snip
 
  So it's a Cygwin issue... I think it has been discussed before but I
  am not sure if there is a solution.
 
 Cygwin from CVS doesn't use winmm anymore, unless you need access to
 the audio I/O.  Try the latest developer snapshot from
 http://cygwin.com/snapshots/

Thanks. I believe that is likely to fix issues with cron as well.

Pierre  


--
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: exim-4.76-1 fails to remove lock from spooler on delivery

[Pierre A. Humblet]

 -Original Message-
 From: cygwin-owner On Behalf Of Zdzislaw Meglicki
 Sent: Tuesday, October 25, 2011 17:30 PM
 
 I have a problem with exim-4.76-1 on my Cygwin installation under Windows
 7. On having received a message addressed to a local user, exim creates
the
 lock file in the /var/spool/mail directory and ... freezes. The message
shows
 up in mailq as frozen. I have to remove the lock file manually, then run
 exim -M on the message ID for its final delivery into the user file.

Is that 100% reproducible on your system? 
Is there an entry in an exim log, normally in /var/log/exim/ ?
I couldn't reproduce the problem on XP.

Pierre


--
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 - Windows server 2003 - Cron started - Job run - No effect

[Pierre A. Humblet]

 -Original Message-
 From: cygwin-owner On Behalf Of 6lv1
 Sent: Wednesday, October 26, 2011 10:55 AM
 
 Dear Cygwin community,
 
 I'm beating with my self in order to set up a simple cron job in a Cygwin
 environment (setup.exe version 2.738) under Windows server 2003. At first
I
 encountered some difficulties to start cron service but now it starts
correctly
 and cron logs its run my job.
 
 For information, here what I used to set up cron:

FYI, there is a cron-config script that would have done everything for you.
It will also check the sanity of the environment
See also the cron README file in /usr/share/doc/Cygwin/

The command itself may have produced some info.
If /usr/sbin/sendmail is a link to /usr/bin/cronlog  any  command output is
placed  in ~/cron.log

Pierre


--
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: exim-4.76-1 fails to remove lock from spooler on delivery

[Pierre A. Humblet]

 -Original Message-
 From: Zdzislaw Meglicki 
 Sent: Wednesday, October 26, 2011 13:43 PM
 
 Hello Pierre,
 
 We are getting somewhere. First, the system went down, because it was
 patching itself and needed to reboot. Normal for Windows.
 
 I'm now sitting in front of the machine. I have stopped exim and cleaned
all
 logs in /var/log/exim. Then restarted it. Then I e-mailed a message from
 perth.ovpit.indiana.edu to gusta at yanchep.ovpit.indiana.edu to reproduce
 the problem and inspected he logs.
 
 Here's what I find:
 
 1. In the /var/spool/mail directory, the message has been written on the
 destination file gustav.
 2. The lock file, /var/spool/mail/gustav.lock, which wasn't there
originally, is
 there now and remains unremoved.
 3. There is an entry in /var/log/exim/exim_panic.log that looks as
follows:
 
 root@yanchep $ cat exim_panic.log
 2011-10-26 13:33:46 LTOOS9-0002MK-LW failed to read delivery status for
 gus...@yanchep.ovpit.indiana.edu from delivery subprocess
 2011-10-26 13:33:46 LTOOS9-0002MK-LW appendfile transport process
 returned non-zero status 0x0001: terminated by signal 1 root@yanchep $

I was able to replicate the problem on Windows 7:
The delivery process crashes because it can't load winmm.dll

16:06:33  3572 writing data block fd=6 size=1 timeout=0
  6 [main] exim 3572 C:\Program Files\cygwin\bin\exim-4.76-1.exe: ***
fatal error - unable to load C:\Windows\system32\winmm.dll, Win32 error 1114
16:06:33  5620 LOG: MAIN PANIC
16:06:33  5620   failed to read delivery status for phumblet@phumblet-lap01w
from delivery subprocess

So it's a Cygwin issue... I think it has been discussed before but I am not
sure if there is a solution.

Pierre


--
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

[Patch] gethostby_helper

[Pierre A. Humblet]

This patch has already been already applied.
Diff in attachment and also below.

Pierre

2011-08-16  Pierre Humblet pierre.humb...@ieee.org

* net.cc (gethostby_helper): Remove DEBUGGING code from and
streamline the second pass.

Index: net.cc
===
RCS file: /cvs/src/src/winsup/cygwin/net.cc,v
retrieving revision 1.289
diff -u -p -r1.289 net.cc
--- net.cc  4 Aug 2011 08:22:11 -   1.289
+++ net.cc  16 Aug 2011 23:31:44 -
@@ -1198,57 +1198,34 @@ gethostby_helper (const char *name, cons
   string_ptr = (char *) (ret-h_addr_list + address_count + 1);

   /* Rescan the answers */
-  ancount = alias_count + address_count; /* Valid records */
   alias_count = address_count = 0;
+  prevptr-set_next (prevptr + 1);

-  for (i = 0, curptr = anptr; i  ancount; i++, curptr = curptr-next ())
+  for (curptr = anptr; curptr = prevptr; curptr = curptr-next ())
 {
   antype = curptr-type;
   if (antype == ns_t_cname)
{
- complen = dn_expand (msg, eomsg, curptr-name (), 
string_ptr, string_size);

-#ifdef DEBUGGING
- if (complen != curptr-complen)
-   goto debugging;
-#endif
+ dn_expand (msg, eomsg, curptr-name (), string_ptr, 
curptr-namelen1);

  ret-h_aliases[alias_count++] = string_ptr;
- namelen1 = curptr-namelen1;
- string_ptr += namelen1;
- string_size -= namelen1;
- continue;
+ string_ptr += curptr-namelen1;
}
-  if (antype == type)
+  else
+   {
+ if (address_count == 0)
{
- if (address_count == 0)
-   {
- complen = dn_expand (msg, eomsg, curptr-name(), 
string_ptr, string_size);

-#ifdef DEBUGGING
- if (complen != curptr-complen)
-   goto debugging;
-#endif
- ret-h_name = string_ptr;
- namelen1 = curptr-namelen1;
- string_ptr += namelen1;
- string_size -= namelen1;
-   }
- ret-h_addr_list[address_count++] = string_ptr;
- if (addrsize_in != addrsize_out)
-   memcpy4to6 (string_ptr, curptr-data);
- else
-   memcpy (string_ptr, curptr-data, addrsize_in);
- string_ptr += addrsize_out;
- string_size -= addrsize_out;
- continue;
-   }
-#ifdef DEBUGGING
-  /* Should not get here */
-  goto debugging;
-#endif
+ dn_expand (msg, eomsg, curptr-name (), string_ptr, 
curptr-namelen1);

+ ret-h_name = string_ptr;
+ string_ptr += curptr-namelen1;
+   }
+ ret-h_addr_list[address_count++] = string_ptr;
+ if (addrsize_in != addrsize_out)
+   memcpy4to6 (string_ptr, curptr-data);
+ else
+   memcpy (string_ptr, curptr-data, addrsize_in);
+ string_ptr += addrsize_out;
+   }
 }
-#ifdef DEBUGGING
-  if (string_size  0)
-goto debugging;
-#endif

   free (msg);

@@ -1263,16 +1240,6 @@ gethostby_helper (const char *name, cons
  Should it be NO_RECOVERY ? */
   h_errno = TRY_AGAIN;
   return NULL;
-
-
-#ifdef DEBUGGING
- debugging:
-   system_printf (Please debug.);
-   free (msg);
-   free (ret);
-   h_errno = NO_RECOVERY;
-   return NULL;
-#endif
 }

 /* gethostbyname2: standards? */

net.cc.diff
Description: Binary data

FW: buffer size calculation in gethostby_helper()

[Pierre A. Humblet]

[bounced message]

Hi Jan,

Thanks for your help. 
For some reason my message below is taking time to appear on Cygwin.com
If it does not appear could you forward it?
It's not the first time that that particular list ignores my messages :(

By the way, if you still get an error with the fixes suggested below tell me 
what dns query you are making and I will try to duplicate it next week.

Pierre

-Original Message-
From: Pierre A. Humblet [mailto:Pierre dot Humblet at ieee dot org] 
Sent: Friday, August 12, 2011 10:41 AM
To: cygwin at cygwin dot com  
Subject: RE: buffer size calculation in gethostby_helper()

 -Original Message-
 From: Corinna Vinschen 
 Sent: Friday, August 12, 2011 6:29 AM
 
 On Aug 12 03:10, Jan Kolar wrote:
 
  Dear Corinna,
  Please note that in net.cc, some kind of
string_size += addrsize_out; is missing somewhere, 
  which affects a buffer allocation.
  See the two locations in diff.
  [...]
  DIFF
  $ cd /usr/src/cygwin-1.7.6-1/winsup/  diff -up 
  ../rozbalene-orig-src.tar.bz2/cygwin-1.7.6-1/winsup/cygwin/net.cc
  cygwin/net.cc
  ---
  ../rozbalene-orig-src.tar.bz2/cygwin-1.7.6-1/winsup/cygwin/net.cc
  2010-08-16 15:55:07.0 +0200
  +++ cygwin/net.cc2011-08-12 00:07:51.709992400 +0200
  @@ -1109,6 +1109,8 @@ gethostby_helper (const char *name, cons
 else if (address_len != namelen1)
   continue;
 address_count++;
  +  string_size += addrsize_out; // jk-2011 hope this fixes 
  + the BUG below

The initial logic seems to be OK: In the following statement
sz = DWORD_round (sizeof(hostent))
   + sizeof (char *) * (alias_count + address_count + 2)
   + string_size
   + address_count * addrsize_out;
the incremented address_count generates two increases in sz:
a chunk of size sizeof(char *) and another one of size addrsize_out.
So the patch adding addrsize_out shouldn't be needed.

  +  system_printf (Note: JK hopping to fix the -4 bug in net.cc 
  saying (if defed DEBUGGING) 'Please debug.' );
   }
 /* Update the records */
 curptr-type = antype; /* Host byte order */ @@ -1192,7 
  +1194,7 @@ gethostby_helper (const char *name, cons
 else
   memcpy (string_ptr, curptr-data, addrsize_in);
 string_ptr += addrsize_out;
  -  string_size -= addrsize_out;
  +  string_size -= addrsize_out; // jk-2011 FIXME BUG:   this makes 
  it -4 sometimes - before my fix.

The bug is here: logically string_size shouldn't be decremented as it is used 
to account for name sizes, not for addresses.
Note that at this point string_size is only used for debugging and the bug 
generates a false alarm.
It's weird that it only shows up now.
I see two ways of fixing it:
1) add string_size += addrsize_out; as in the patch but then adjust the 
computation of sz or
2)  remove the extraneous string_size -= addrsize_out and in the  #ifdef 
DEBUGGING below replace
if (string_size  0)  by
if (string_ptr  ((char *) ret) + sz) 

 continue;
   }
   #ifdef DEBUGGING
 
 This looks basically correct to me, but the original code is not from me.
 Pierre, would you mind to have a look?
 
Sorry about that. I could fix it myself next week if desired.

Pierre





--
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: Errors in Exim, rebaseall, inetd.

[Pierre A. Humblet]

At 06:46 AM 12/17/2010, Ross Hemingway wrote:

Hi,
I have installed cygwin and Exim into 3 different Server 2008R2 
(64bit).  I'd like to report the following errors that are 
consistent through out.  This applies to all version of 1.7.x so far.


1/ Exim install script does not complete through the regular 
setup.exe system.  The script never gets its .done file extension, 
so it pops up an error did not complete, but it does seem to have 
completed its install task regardless.


2/ Exim will not run error free, until you do a rebaseall on the 
installed cygwin.  The errors are seen when it tries to do a 
mailing, and it creates a lot of permissions access 
errors.  Rebasing the system fixes it.


3/  rebaseall script has a fault on line 91, where   if [ ! -w 
$TmpDir ].This always returns an error, despite the file 
location being OK and writable.  It's probably a permission issue 
again.  If we comment out this code part, the script does its job OK.


4/  inetd.exe:  This is not an error, but a big inconvenience.  When 
this inetd is installed as a service (cygrunsrv -I), and then 
started as a service (net start inetd), it does not keep a 
Services.msc presence. Hence you cannot stop it (net stop 
inetd).  The only way to stop it is with a force kill process on the inetd.exe.


Thanks for the report about exim. The need to rebaseall on many 
systems has already
been mentioned several times. I will make sure that this is clear in 
the documentation

and perhaps add a warning in exim-config.
About the postinstall, it's the first time this problem is reported. 
Has setup changed its
criterion to add the done extension ? It is normal for the last 
command in the script

to fail.

Pierre


--
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: Cron 'WRONG FILE OWNER' Problem Cygwin 1.7/Windows 7

[Pierre A. Humblet]

At 04:56 PM 12/15/2010, Bruce Bailey wrote:


Hi

I had been happily using 'cron' on cygwin for quite a while.  After 
updating the user password using cron-config, suddenly cron refuses 
to read my cron tab, putting 'WRONG FILE OWNER' in the Windows application log.


Has this been seen and resolved?


Do you have two baileyb users, one with uid 32638 and owning the crontab
and another one with uid 1006 and being setuid by cron?

-rw-r- 1 baileyb root 1173 2010-12-13 07:51 /var/cron/tabs/baileyb
-rw-r- 1 32638 0 1173 2010-12-13 07:51 /var/cron/tabs/baileyb

Output from C:\cygwin\bin\id.exe
UID: 1006(baileyb)  GID: 513(None)
513(None)   0(root) 544(Administrators) 545(Users)
30633(por_ccusers)

Pierre 



--
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: Cron jobs don't run

[Pierre A. Humblet]

At 04:59 PM 11/1/2010, Janos Dohanics wrote:

I'm trying to set up cron jobs in a new cygwin installation. The cron
service is running, but jobs are not executed.

I ran cron_diagnose.sh which says The SYSTEM user cannot access the
mount point /usr/bin. mount shows:


On cygwin 1.5:
C:~: fgrep -1 'access' /bin/cron_diagnose.sh | fgrep cannot
echo The SYSTEM user cannot access the mount point ${mnt_point}.
On cygwin 1.7
C:~: fgrep -1 'access' /bin/cron_diagnose.sh | fgrep cannot

So you are using an old version of cron_diagnose.

To debug, start with a crontab that executes a simple
command  such as date  /tmp/cron.out every minute.
You can use cronevents to view the log.
If you need more help, run cronbug and send it as an attachment.

Pierre


--
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: res_send() doesn't work with osquery enabled

[Pierre A. Humblet]

- Original Message - 
From: Corinna Vinschen 
To: cygwin-patches
Sent: Thursday, August 26, 2010 12:38


| Pierre, would you mind to take a look?
| 
| On Aug 26 19:07, pse...@egg6.net wrote:
|  Currently res_init() checks for availability of the native windows
|  function DnsQuery_A. If the function is found, it's preferred over the
|  cygwin implementation and res_query is set up to use it.
|  As DnsQuery_A finds the configured name servers itself, the current code
|  assumes we can avoid loading the dns server list with GetNetworkParams().
|  
|  However, the assumption that everybody would use res_query is wrong. Some
|  programs may use res_mkquery() and res_send() or may only read the list of
|  servers from _res.nsaddr_list and send/receive the queries/replies
|  themselves. res_send() also relies on nsaddr_list.

It's true that the behavior described above is legitimate, even if nobody had 
ever 
requested it. If people want to access nsaddr_list after calling res_ninit, 
loading 
iphlpapi.dll every time (as the patch does) is unavoidable.

The other change has res_nsend return an error if no server can be found.
Alternatively the error could be reported by res_ninit, by removing the second
condition in 
if (statp-nscount == 0  !statp-os_query) {
errno = ENONET;
statp-res_h_errno = NETDB_INTERNAL;

Hypothetically this could affect some installations where iphlpapi doesn't 
report any
servers although the Windows resolver can find a server (but I don't see how 
this
could happen), so it's safer to proceed as in the patch.
However the patch should send errno to ENONET and set res_h_errno to
NETDB_INTERNAL

Except for the previous comment, I am fine with the patch.

Pierre

Re: Will cron runnnnig as a service cause the server to lock up?

[Pierre A. Humblet]

- Original Message - 
From: Blaine Miller 
To: cygwin
Sent: Thursday, August 26, 2010 12:59


| I'm running cron as a service. Twice this week this server has died and 
| needed cold rebooting to get the system back.
| 
| Questions - First, will cron as a service on a Windows 2003 R2, standard 
| system cause this sort of behavior?

This has never been reported, as far as I know.
You run cron as yourself, if I remember correctly. This avoids various setuid
issues. Except for that, cron is a plain vanilla program. 

| Second, if it does, how do I run cron to keep it from 
| doing this?
| 
| A snippet of the errors I'm getting are:
| 
| cron: unknown option -- D
| usage: /usr/sbin/cron [-n] [-x [ext,sch,proc,pars,load,misc,test,bit]]
| 

Where does the -D come from?
That used to be an option in cron 3. It is now replaced by -n
Without -n, cron will not remain under the control of cygrunsrv.

| My crontable is:
| 
| $ crontab -l
| # DO NOT EDIT THIS FILE - edit the master and reinstall.
| # (/tmp/crontab.yRr11boUdm installed on Thu Aug 19 14:17:23 2010)
| # (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie 
| Exp $)
| 00 05 * * * /cygdrive/c/scripts/xfer_vvm_mysql.sh
| 00 05 * * * /cygdrive/c/scripts/xfer_vvm_ora.sh
| 00 05 * * * /cygdrive/c/scripts/xfer_nab_vnnab.sh
| 00 10 * * * /cygdrive/c/scripts/xfer_nab_csnab.sh
| 00 06 * * * /cygdrive/c/scripts/xfer_dellsrv20.sh
| 00 06 * * * /cygdrive/c/scripts/xfer_directory.sh
| 00 06 * * * /cygdrive/c/scripts/xfer_perforce.sh
| 00 06 * * 2 /cygdrive/c/scripts/xfer_fileserv.sh
| 
| 
| As you can see, I'm not passing any paramets to the cron daemon...

Remember that PATH may not be the same under cron as under 
interactive bash. So find and other tools may use a Windows version.
But that doesn't explain a crash.

Pierre


--
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: cron fails to start as a service in Win2k3R2 64bit

[Pierre A. Humblet]

- Original Message - 
From: Blaine Miller 
To: cygwin
Sent: Thursday, August 19, 2010 17:47


| The only way I've been able to get cron running is manually by starting 
| the crond via execution of cron.exe.
| 
| Attached are my cygcheck.txt and crontab.
| 
| I get the following error after I install and start the cron service...
| 
| cygrunsrv: Error starting a service: QueryServiceStatus:  Win32 error 1062:


Did you use cron-config to configure cron?

If the problem persists run cronbug and send the output as an attachment.

Pierre


--
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: cron fails to start as a service in Win2k3R2 64bit

[Pierre A. Humblet]

- Original Message - 
From: Blaine Miller 
To: cygwin
Sent: Friday, August 20, 2010 11:33


| Pierre,
| 
| I tried using cron-config and it failed. Please find attached my 
| cronbug.txt...

OK, I see that you are running cron as yourself (Administrator).

The problem is that you have several cron running, probably from
the time when you were running cron manually
2116 1 2116 2116 ? 500 13:49:24 /usr/sbin/cron

I 3664 2116 2116 3664 ? 500 05:00:01 /usr/sbin/cron

I 3896 2116 2116 3896 ? 500 05:00:01 /usr/sbin/cron

I 3464 2116 2116 3464 ? 500 06:00:01 /usr/sbin/cron

Kill them all and run cron-config again, keeping (not removing) the existing 
service.

Pierre
 

--
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: Using ssmtp called in a script called by a crontab entry...

[Pierre A. Humblet]

- Original Message - 
From: Blaine Miller 
To: cygwin
Sent: Friday, August 20, 2010 17:51


| Hello,
| 
| I have a need for ssmtp to send out a *job completed* email from within 
| a script that is called as an entry in a cron table. I've read all I can 
| from the *Installing and configuring ssmtp* man pages as well as the 
| Knowledgebase and FAQ's on the cygwin site. From what I gather it should 
| be possible to do this.

Seen from the cron point of view, if the cron job produces any output on stdout
or stderr, the output will be placed in an e-mail sent to you (you can 
configure the
address in the MAILTO variable).
As as recall, the ssmtp-config script will ask you if you want sendmail to 
point to
ssmtp. If you answer yes, cron will use ssmtp to send the e-mail.

Pierre

--
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: Sendmail linked to cronlog?

[Pierre A. Humblet]

- Original Message - 
From: Refr Bruhl 
To: Cygwin Mail List 
Sent: Thursday, July 01, 2010 13:01
Subject: Sendmail linked to cronlog?


| Ok this is just humorous
| 
| While configure was running for mailutils 2.1 I noticed sendmail was in 
/usr/sbin
| 
| Thinking that odd, I had not seen a sendmail option in the set up options I 
did an ls on it
| 
| Its pointing to /usr/bin/cronlog? 

Right. That's because cron requires a sendmail and if you install cron on a 
system
without a mailer then the postinstall script links sendmail to cronlog.
cronlog is written so as to return an error if not called from cron.

If you install ssmtp or exim and run the xxx-config script, it will offer to 
point 
sendmail to ssmtp or exim.

I don't know what mailutils does in that respect.

Pierre

 

--
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: Fw: Using cron with network share

[Pierre A. Humblet]

- Original Message - 
From: Larry Hall (Cygwin) 
To: cygwin
Sent: Monday, June 21, 2010 22:06


| On 6/21/2010 2:08 PM, Oren Cheyette wrote:
|  ** apologies about the bad formatting in the earlier reply **
| 
|  Well, I apologize for being dense, but I'm not getting it. I read the
|  document you link to quite a few times before posting my query.
| 
| OK, I didn't know that.
| 
|  I initially tried running the service under my own account (as
|  suggested in the faq) with my username  password entered at prompts
|  from cron-config. No luck. Then I added the mount point to the system
|  fstab and tried again. No luck. Then I changed cron to run as system
|  rather than user, just to see. Still no luck. I also tried adding my
|  username  password to the registry using passwd -R.
| 
| How about skipping the drive altogether and directly mounting the UNC
| path?  If that's not working for you, perhaps you want to try just
| doing the simple net use syntax to try to flush out the specifics of
| your problem.  Again, I'd recommend using UNC paths rather than dealing
| with possible conflicts of network drives (using the same drive
| designation as two different users or in two different contexts can result
| in access problems for the second use).
| 

I agree with Larry. The mount in fstab is  S:\SFCore /sfcore
but S: may not me mapped when running as a service.
Use a UNC path in fstab and run the cron daemon as yourself.

Pierre

  

--
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: Need advice regarding cron---unable to start cron

[Pierre A. Humblet]

At 07:50 AM 6/12/2010, Ravindra Divi wrote:

Hi,
 I installed cygwin on windows server 2003 and am trying to learn 
about cron.

 I created a simple script as follows:
 #!/usr/bin/bash
 #move the file every 1 min
 echo 'date'  datelog.txt
 mv datelog.txt outbound

 I then created a crontab using the command crontab -e as follows:

snip



 but nothing is happening. I was able to successfully run the script
 manually. But when trying to accomplish it through cron, nothing 
happens. I checked the services in start --administrative 
tools--services and I see cron Daemon running. I dont see anything 
in logs either.Please advise.


Did you use cron-config to start cron?

I see the cron daemon is running under the Local System account, 
which on server 2003
is only possible in some cases. This is explained in 
/usr/share/doc/Cygwin/cron-X.README,

in cron-config and in the Cygwin doc (about setuid).
The doc also recommends running cronbug and sending the output as an 
attachment.


Pierre
  



--
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: 1.7.5: question about running cron tasks as normal local user (no domain users / no local admin group users)

[Pierre A. Humblet]

- Original Message - 
From: Adi B Treiner 
To: Cygwin
Cc: Pierre.Humblet
Sent: Friday, June 04, 2010 10:43


Hello Pierre,

thanks fort the response.

 Did you upgrade from 1.5 to 1.7.5 or did you go through some 1.7.X?

I think I upgraded from 1.5 to 1.7.5 directly.

 This problem may be due to the way the groups are computed in Cygwin
 1.7 but there must be something special about your install, otherwise
 would see more reports. It's significant that you are on a non-US 
 system.

 Actually there was a change in Feb 2010
 http://cygwin.com/ml/cygwin-cvs/2010-q1/msg00109.html
 to fix a bug on non-US systems. But this may have caused a bug in your
 older Windows 2000 ...

I updated cygwin last week - so I think the above change should be
considered within of my build.

 Could you
 - compile and run the attached program
 - in a shell, type

snip
***
Hi Adi,

all the output you provided looks perfecty normal.
Perhaps I should have asked if you have tried running rebaseall.
If not, please try it.

Pierre


--
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: 1.7.5: question about running cron tasks as normal local user (no domain users / no local admin group users)

[Pierre A. Humblet]

At 08:57 AM 6/3/2010, Adi B Treiner wrote:

Hello,

After upgrading to version 1.7.5 running cron tasks for normal local
users doesnt work anymore.

For those users cron always reports the following error:
cron.exe: *** fatal error - could not load user32, Win32 error 1114

This seems to be related to similar issues as described for ssh
authentication via privat/public keys.

I followed all the suggestion for the above topic but this doesnt solve
the issue for running cron tasks.


I dont have any problem with ssh authentication via private/public key
pairs - so I think my configuration should be appropriate.


My virtual Windows box running under Windows 2000 Professional.
I only have local Users ( no domain users ).

The Problem doesnt happen for users of the local admin group - for those
users it works as expcted.


Even the problem didnt occur with the old 1.5 version.

Please could someone point me how to solve the issue.


Hi,

Did you upgrade from 1.5 to 1.7.5 or did you go through some 1.7.X?

This problem may be due to the way the groups are computed in Cygwin 1.7
but there must be something special about your install, otherwise we would
see more reports. It's significant that you are on a non-US system.

Actually there was a change in Feb 2010
http://cygwin.com/ml/cygwin-cvs/2010-q1/msg00109.html
to fix a bug on non-US systems. But this may have caused a bug in your
older Windows 2000 ...

Could you
- compile and run the attached program
- in a shell, type
cacls 'c:\WINDOWS\system32\user32.dll'(or where ever 
user32 is on your system)

cacls 'c:\WINDOWS\system32'
and send me the outputs ?

Thanks

Pierre

#include stdio.h
#include windows.h
#include sys/cygwin.h
/* Macro to define variable length SID structures */
#define SID(n, name, sid...) \
struct { \
BYTE  Revision; \
BYTE  SubAuthorityCount; \
SID_IDENTIFIER_AUTHORITY IdentifierAuthority; \
DWORD SubAuthority[n]; \
} name = { SID_REVISION, n, {SECURITY_NT_AUTHORITY}, {sid}}

SID(1, BuiltInSid, SECURITY_BUILTIN_DOMAIN_RID);
SID(2, AdminsSid, SECURITY_BUILTIN_DOMAIN_RID, DOMAIN_ALIAS_RID_ADMINS);

void printw(WCHAR * name, DWORD len)
{
unsigned int i;
for (i = 0; i  len; i++)
printf(%d , name[i]);
printf(\n);
for (i = 0; i  len; i++)
printf(%c, name[i]);
printf(\n);
}

void print(char * name, DWORD len)
{
unsigned int i;
for (i = 0; i  len; i++)
printf(%d , name[i]);
printf(\n);
for (i = 0; i  len; i++)
printf(%c, name[i]);
printf(\n);
}

void lookupw(void *psid, char *name)
{
WCHAR group[100], domain[100];
DWORD x, glen = 99, domlen = 99;
SID_NAME_USE use = 0;
x = LookupAccountSidW(NULL, psid, group, glen, domain, domlen,
  use);
printf(%s use %d res %lu\n, name, use, x);
if (x) {
printw(group, glen);
printw(domain, domlen);
}
}

void lookup (void * psid, char * name)
{
char group[100], domain[100];
DWORD x, glen = 99, domlen = 99;
SID_NAME_USE use = 0;
x = LookupAccountSidA (NULL, psid, group, glen,
domain, domlen, use);
printf(%s use %d res %ld\n, name, use, x);
if (x) {
print(group, glen);
print(domain, domlen);
}
}   

int main(void)
{
printf(= testcyg ==\nuname -a: );
fflush(stdout);
system(uname -a);
printf(\nnarrow:\n);
lookup(BuiltInSid, BuiltIn);
lookup(AdminsSid, Admins);
printf(\nwide:\n);
lookupw(BuiltInSid, BuiltIn);
lookupw(AdminsSid, Admins);
printf(= the end ==\n);
return 0;
}

--
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: crontab problem

[Pierre A. Humblet]

At 02:49 PM 5/30/2010, System wrote:

Hi.
I`m using CYGWIN Posix environment under windows xp sp2 (ru)
But i have problem with crontab.
It didnt start as service anyway.


If anythink is unclear let me know.
See the attach file.
Thanks in advance.


Hi,

PATH is unusual: C:\cygwin\step\bin

The cygcheck that is called from cronbug reports problems with your 
installation


Not Found: awk
Not Found: bash
Not Found: cat
Not Found: cp
Not Found: cpp (good!)
Not Found: crontab
Not Found: find
Not Found: gcc
Not Found: gdb
Not Found: grep
Not Found: kill
Not Found: ld
Not Found: ls
Not Found: make
Not Found: mv
Not Found: patch
Found: c:\Perl\bin\perl.exe
Not Found: rm
Not Found: sed
Not Found: ssh
Not Found: sh
Not Found: tar
Not Found: test
Not Found: vi
Not Found: vimgcheck

and also cannot find cygrunsrv

Fix your installation (check with cygcheck) and run cron-config again.
Did cron-config complain about cygrunsrv not being available?

Pierre



--
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: cron error can't switch user context

[Pierre A. Humblet]

- Original Message - 
From: Tom Schutter
To: cygwin
Sent: Friday, April 16, 2010 15:29


|I have attached cronbug.txt as per the cron-config instructions.
|
| Note that the original cronbug.txt was over 5MB.  I edited cronbug.txt and 
removed 46000 lines 
of cronevents output.  Is there any way of cleaning out old cron entries from 
the event log?
|
| On Fri 2010-04-16 13:42, Tom Schutter wrote:
|  I have number of machines running Windows2003 and Cygwin 1.7.5.  On most 
cron works.  But on 
one (lemon) it does not.  It appears that on lemon cron cannot switch the user 
context.
| 
|  Cronevents on lemon shows:
| 
|  2010/04/15 17:19:01 [SYSTEM] /usr/sbin/cron: PID 656: (tschutter) CMD 
(/usr/bin/python 
/cygdrive/f/production-sync/production-sync.py)
|  2010/04/15 17:19:01 [SYSTEM] /usr/sbin/cron: PID 656: (CRON) error (can't 
switch user 
context)
| 
|  /var/log/cron.log is empty on all machines.
| 
|  The cron daemon is running as SYSTEM on all machines.
| 
|  cyglsa is running on all machines.
| 

Hi,

I should perhaps modify cronbug to use tail with cronevents, but it's unusual 
to see
a report that cron is broken yet there are 46000 lines in the log!
I assume cron used to work, then something happened and it stopped working.
Or there is something special about the tschutter account.
Can you identify the something ?
Any difference between the lemon and the others?

It's  most likly not a cron problem, but something to do with cyglsa. I have 
never
used it, don't have a system like yours to test and there is no such previous 
report.
So not sure what to recommend.
Does password-less ssh work for tschutter ?
If you can't identify the something, you could try to strace cron on the lemon
and on another machine. Here is the recipe.

Stop the cron service.
Use a simple crontab that runs every minute, for only one user.
Using cygrunsrv, create a new service runing strace with argument cron 
under SYSTEM
1)  cygrunsrv -I trace_cron -p /usr/bin/strace -a /usr/sbin/cron
2)  cygrunsrv -S trace_cron
3)  Let this run for no more than 2 minutes, output will be in 
/var/log/trace_cron.log
 You may have to use kill -9 to stop the service (kill the cron pid)
4)  Send the trace_cron.log file as an attachment.
5)  Remove the trace_cron service
Restart cron

Pierre 


--
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: Please upload cron 4.1-59

[Pierre A. Humblet]

- Original Message - 
From: Eric Blake
To: cygwin-apps
Sent: Friday, March 12, 2010 10:38


 Done. I also edited your setup.hint to drop the requires: cygwin, as that is 
 now automatic.

Thanks

 Should I also delete 4.1-6 and 4.1-7?

Yes, those were for cygwin 1.5

Pierer

Re: cron-config has a debug set -x

[Pierre A. Humblet]

- Original Message - 
From: Tom Schutter 
To: cygwin
Sent: Thursday, March 11, 2010 14:36


| The current cron-config has as the second line:
| 
|  set -x

Thanks for the report. I will fix that this evening.

Pierre

--
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: cron fails to run as a service

[Pierre A. Humblet]

At 02:13 AM 3/2/2010, Paul McFerrin wrote:
I've been using cron for more that a few weeks without any 
problems, until my needs changed.  I installed cron as a service 
using cygrunsrv.  I keep getting errors about creating 
lockfile.  I removed the lockfile but it got created again.  At 
first, I got the Win32 error and ran the cron_diagnose.sh script and 
got it further along but still nogo.  Attached is a copy of 
cronbug.txt as instructed.  It is trying to start cron, but cron 
fails to start as a service.  It run perfectly when not a service/


One difference:  the service control manager added a -n option to 
my cron command that I did not specify.  How can I turn off this feature??


Paul,

The -n switch keeps cron in the foreground. This is advisable when 
cron runs under cygrunsrv.


Some of your problems are due to launching a new cron daemon while an 
old one is still running.

If you experiment with cron, you can view the cron log by using cronevents

2010/03/01 01:38:45 [Paul] /usr/sbin/cron: PID 368: (CRON) STARTUP (V5.0)
2010/03/01 01:47:26 [Paul] /usr/sbin/cron: PID 2508: (CRON) DEATH 
(can't lock /var/run/cron.pid, otherpid may be 368: Resource 
temporarily unavailable)


I will think about your SIGHUP request when I have more time.
How do other Cygwin services handle this?

Pierre


--
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: cron fails to run as a service

[Pierre A. Humblet]

- Original Message - 
From: Paul McFerrin 
To: Pierre A. Humblet pierre.humb...@ieee.org
Sent: Tuesday, March 02, 2010 12:03


| Pierre A. Humblet wrote:
| 
|  Some of your problems are due to launching a new cron daemon while an 
|  old one is still running.
| 
| What old cron.  This is the firts setup.  

In the log snippet below the old cron is pid 368. You are trying to launch
a new cron with pid 2508.

| As to your SIGHUP question, 
| my experience is limited to such items as httpd for web server.  They 
| let SIGHUP to kill it off. During shutdown, I send SIGHUP to all process 
| group leaders.follwed by signal 9 about 15 seconds later.  If they 
| survive SIGHUP, signal 9 will do them in.

Re. SIGHUP, the cron man page says On receipt of a SIGHUP, the
cron daemon will close and reopen  its  log file. 

However cron will terminate cleanly on SIGTERM and SIGINT.
If you run cron under cygrunsrv, see cygrunsrv --help to see what can be
done in case of shutdown. (--shutsig and --XXXshutdown)

| 
|  If you experiment with cron, you can view the cron log by using 
|  cronevents
| 
|  2010/03/01 01:38:45 [Paul] /usr/sbin/cron: PID 368: (CRON) STARTUP (V5.0)
|  2010/03/01 01:47:26 [Paul] /usr/sbin/cron: PID 2508: (CRON) DEATH 
|  (can't lock /var/run/cron.pid, otherpid may be 368: Resource 
|  temporarily unavailable)

Pierre

--
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: exim-4.70-1

[Pierre A. Humblet]

I have updated Exim, the Mail Transfer Agent, to version 4.70.

News
- Adds native support for DKIM.
- For details, see
* ftp://ftp.exim.org/pub/exim/ChangeLogs/NewStuff-4.70
* ftp://ftp.exim.org/pub/exim/ChangeLogs/ChangeLog-4.70

  and /usr/share/doc/exim-4.70/NewStuff

If you have questions or comments, please send them to the Cygwin
mailing list: cygwin@cygwin.com, mentioning exim in the subject line.

Pierre

---


To update your installation, click on the Install Cygwin now link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

Exim is in the Mail category.


*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the List-Unsubscribe:  tag in the email header of this message.
Send email to the address specified there.  It will be in the format:


cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simplehttp://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at the above URL.





--
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

Please upload exim-4.70-1

[Pierre A. Humblet]

Please upload exim-4.70-1 from

http://mysite.verizon.net/phumblet/exim-4.70-1/exim-4.70-1.tar.bz2
http://mysite.verizon.net/phumblet/exim-4.70-1/exim-4.70-1-src.tar.bz2
http://mysite.verizon.net/phumblet/exim-4.70-1/setup.hint

and keep exim-4.69-51.

Thanks

Pierre

[PATCH] check_access()

[Pierre A. Humblet]

This fixes problem # 3 in http://cygwin.com/ml/cygwin/2010-02/msg00330.html

Pierre

Index: ChangeLog
===
RCS file: /cvs/src/src/winsup/cygwin/ChangeLog,v
retrieving revision 1.4845
diff -u -r1.4845 ChangeLog
--- ChangeLog   25 Feb 2010 16:55:01 -  1.4845
+++ ChangeLog   26 Feb 2010 01:29:30 -
@@ -1,3 +1,8 @@
+2010-02-26  Pierre Humblet pierre.humb...@ieee.org
+
+   * security.cc (check_access): Use user.imp_token if appropriate.
+Set errno and return if DuplicateTokenEx fails .
+
 2010-02-25  Corinna Vinschen  cori...@vinschen.de

* lc_era.h (lc_era_t): Fix apparent glibc bug in ja_JP era definition.



Index: security.cc
===
RCS file: /cvs/src/src/winsup/cygwin/security.cc,v
retrieving revision 1.239
diff -u -p -r1.239 security.cc
--- security.cc 3 Nov 2009 09:31:45 -   1.239
+++ security.cc 26 Feb 2010 01:24:13 -
@@ -751,16 +751,17 @@ check_access (security_descriptor sd, G
? cygheap-user.imp_token ()
: hProcImpToken);

-  if (!tok  !DuplicateTokenEx (hProcToken, MAXIMUM_ALLOWED, NULL,
-SecurityImpersonation, TokenImpersonation,
-hProcImpToken))
-#ifdef DEBUGGING
-   system_printf (DuplicateTokenEx failed, %E);
-#else
-   syscall_printf (DuplicateTokenEx failed, %E);
-#endif
-  else
-tok = hProcImpToken;
+  if (!tok)
+{
+  if (!DuplicateTokenEx (hProcToken, MAXIMUM_ALLOWED, NULL,
+   SecurityImpersonation, TokenImpersonation,
+   hProcImpToken))
+ {
+__seterrno ();
+return ret;
+ }
+  tok = hProcImpToken;
+}

   if (!AccessCheck (sd, tok, desired, mapping, pset, plen, 
granted, status))

 __seterrno ();

Re: Please upload cron 4.1-58

[Pierre A. Humblet]

At 08:01 AM 2/17/2010, Eric Blake wrote:


requires: bash cygwin libgcc1 coreutils

And you should be omitting the 'requires: cygwin' dependency as redundant,
now that upset/setup.exe guarantees it.


Does that hurt anything or is it just style?

Pierre 

Please upload cron 4.1-58

[Pierre A. Humblet]

... and keep 4.1-57 No change in setup.hint.

The files can be found in

http://mysite.verizon.net/phumblet/cron-4.1-58/cron-4.1-58.tar.bz2
http://mysite.verizon.net/phumblet/cron-4.1-58/cron-4.1-58-src.tar.bz2
http://mysite.verizon.net/phumblet/cron-4.1-58/setup.hint

Thanks.

Pierre

Re: /usr/bin/cron-config can render a Win2K3 box unusable

[Pierre A. Humblet]

At 03:44 PM 2/16/2010, Patrick Rynhart wrote:

I'm on Windows Server 2003 and carefully read through
/usr/share/doc/Cygwin/cron-4.1-57.README prior to configuring cron.
The guide discusses how a privileged user account is required in order
to run cron.  The script  /usr/bin/cron-config gives you the option of
creating a user account on behalf (e.g. cyg_server) or using your own
account, i.e.


Good point, will do.

Pierre


--
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: cron Windows 7

[Pierre A. Humblet]

- Original Message - 
From: Corinna Vinschen
To: cygwin
Sent: Friday, February 12, 2010 5:09
| On Feb 11 18:01, Pierre A. Humblet wrote:
|  - Original Message - 
|  From: Corinna Vinschen
|  To: cygwin@cygwin.com
|  Sent: Thursday, February 11, 2010 13:52
|  |
|  | Uh oh.  Is the name of the BUILTIN group not BUILTIN on non-English
|  | systems?  If so, the code in get_user_local_groups must be changed to
|  | emit the correct name, rather than just storing the fixed string
|  | BUILTIN\\ in builtin_grp.
| 
|  Will do, this weekend at the latest. Matthias did a preliminary test on Win 
7.
|  I learned that in German BUILTIN is VORDEFINIERT :)
|  I wonder if the translation is a Win 7 feature or if has been there all the 
time.
|
| I think it was always there, but I'm not sure.

It's hard to believe that the bug has always been there on foreign machines...
A few other things:

1) I had the feeling that we have already discussed this in the past.
Take a look at
http://www.cygwin.com/ml/cygwin-patches/2002-q4/msg00255.html
(last line). Thanks to google :)

2) About http://cygwin.com/ml/cygwin/2010-01/msg00334.html
USERS is already always added to the token. It's done in 
get_token_group_sidlist.
This raises the possibility that fixing the language problem won't fix the 
current bugs
were user32 can't be loaded, and also with ws2_32.dll in your message

3) There is another major bug: scripts don't get executed while impersonated.
The problem is in access.

cron has setuid and tries to run sendmail == /bin/cronlog
  502 3438682 [main] cron 4000 av::fixup: C:\Program 
Files\cygwin_1.7\bin\cronlog is possibly a 
script
 1832 3440514 [main] cron 4000 seterrno_from_win_error: 
../../../../src/winsup/cygwin/security.cc:766 windows erro$
   61 3440575 [main] cron 4000 geterrno_from_win_error: windows error 6 == 
errno 9
   21 3440596 [main] cron 4000 __set_errno: void seterrno_from_win_error(const 
char*, int, 
DWORD):319 val 9
   21 3440617 [main] cron 4000 check_file_access: flags 1, ret -1net helpmsg 6

net helpmsg 6
The handle is invalid.

I will get to it but if you have an idea let me know.

4) Finally I noticed that perl doesn't run with the cygwin0.dll I built in cvs 
(last nite).
Not sure if you see that too.

Pierre 


--
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: cron Windows 7

[Pierre A. Humblet]

- Original Message - 
From: Corinna Vinschen 
Sent: Friday, February 12, 2010 12:4311474


| On Feb 12 18:39, Corinna Vinschen wrote:
|  On Feb 12 10:19, Pierre A. Humblet wrote:
|   From: Corinna Vinschen
|   | I think it was always there, but I'm not sure.
|   
|   It's hard to believe that the bug has always been there on foreign 
machines...
|   A few other things:
|   
|   1) I had the feeling that we have already discussed this in the past.
|   Take a look at
|   http://www.cygwin.com/ml/cygwin-patches/2002-q4/msg00255.html
|   (last line). Thanks to google :)
|  
|  Cool!  Look at the date!  So I did it again wrong after you already
|  fixed it in 2002.  Oh well.  Btw, I tested this today and it seems the
|  patch is working.  I'll just change it to use a well_known_builtin_sid
|  rather than creating the SID on the fly.
| 
| Nevertheless, would you mind to test it as well?  Easy chance that I
| missed something.

Matthias just tested what I did last night, which was based on what
you had sent, but also defining well_known_users_sid in security.h etc.. 
Now cron works on his system. Looks like we are duplicating efforts!

I just refreshed cvs and get_token_group_sidlist still has:
  grp_list *= well_known_users_sid;

I was also looking at the lsaauth code and noticed you exclude all
well-known groups.
Does lsa put them in the token anyway? Otherwise how does 
USERS get in there?

I have many other observations but that will be for later.

Pierre





--
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: cron Windows 7

[Pierre A. Humblet]

- Original Message - 
From: Corinna Vinschen 
To: cygwin@cygwin.com
Sent: Friday, February 12, 2010 13:47



| On Feb 12 13:33, Pierre A. Humblet wrote:
| |  Matthias just tested what I did last night, which was based on what
|  you had sent, but also defining well_known_users_sid in security.h etc.. 
| 
| Sorry, but I don't understand what you mean.  well_known_users_sid
| *is* already defined in security.h since my patch from 2010-01-08.

Oops, I meant well_known_builtin_sid, like what you just did.

|  Now cron works on his system. Looks like we are duplicating efforts!
|  
|  I just refreshed cvs and get_token_group_sidlist still has:
|grp_list *= well_known_users_sid;
| 
| Yes, sure.  What's the problem?  You wrote in
| http://cygwin.com/ml/cygwin/2010-02/msg00291.html that always adding
| well_known_users_sid is a good idea from your POV.  I currently don't
| understand what you're trying to say.

Sorry, I misunderstood your earlier e-mail. I shouldn't multitask!

Pierre


--
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: uw-imap-imapd: suggestions for cyg_server issue

[Pierre A. Humblet]

The problem you will run into is that 544 can be changed (e.g. to 0).
It's better to do it learn it dynamically.
The following is from the cron package source code.

in .h
#if defined(__CYGWIN__)
#include windows.h
#include sys/cygwin.h
/* Macro to define variable length SID structures */
#define SID(n, name, sid...) \
struct  { \
  BYTE  Revision; \
  BYTE  SubAuthorityCount; \
  SID_IDENTIFIER_AUTHORITY IdentifierAuthority; \
  DWORD SubAuthority[n]; \
} name = { SID_REVISION, n, {SECURITY_NT_AUTHORITY}, {sid}}

in .c
 
#else /* __CYGWIN__ */
if (is_winnt) {
SID(2, AdminsSid, SECURITY_BUILTIN_DOMAIN_RID, 
DOMAIN_ALIAS_RID_ADMINS);
int admins_gid = cygwin_internal(CW_GET_GID_FROM_SID, 
AdminsSid);


Pierre

- Original Message - 
From: Shaddy Baddah hel...@shaddybaddah.name
To: cygwin-apps@cygwin.com
Sent: Thursday, February 11, 2010 17:27
Subject: uw-imap-imapd: suggestions for cyg_server issue


| Hi,
| 
| I have discovered that there is an issue with imapd when installed on
| Vista/W7. When started through inetd, any imap connection is
| preauthenticated onto the cyg_server account running the inetd Windows
| service.
| 
| I have traced the issue to the root uid emulation employed by the
| Cygwin specific code, used to correct the Unix model of only uid 0
| being privileged. It only performs the emulation if the SYSTEM user is
| the process owner.
| 
| Cygwin uses cyg_server as a necessary alternative for all releases
| Windows 2003 server onwards.
| 
| There are two solutions here. The first I consider a workaround. The
| /usr/share/doc/Cygwin/uw-imap-2007.README could document that a user
| could remap the uids of SYSTEM and cyg_server in /etc/passwd so that
| cyg_server took SYSTEMS RID 18 as its uid.
| 
| The second is the patch (that can be applied to the cygport
| ./uw-imap-2007-2.cygport prepare 'ed source) I have attached. The
| patch checks the gids for the process (using POSIX getgroups()) and
| searches for the Administrators group RID 544. The attached patch
| describes this non-direct approach to identifying cyg_server, and
| avoiding preauth.
| 
| Your thoughts on this would be greatly appreciated.
| 
| Regards,
| Shaddy
| 
| PS: I segued onto this from my screen debugging because I remembered
| this issue, and thought it might be related to any potential problem
| with the Cygwin privilege model. Time permitting, I will be getting
| back onto that problem (as it does block me from using screen
| properly).
| 
| 
|

Re: uw-imap-imapd: suggestions for cyg_server issue

[Pierre A. Humblet]

At 06:11 PM 2/11/2010, Shaddy Baddah wrote:

Hi Pierre,

On 11/02/2010 10:39 PM, Pierre A. Humblet wrote:

The problem you will run into is that 544 can be changed (e.g. to 0).
It's better to do it learn it dynamically.
The following is from the cron package source code.

snip

Thanks for that. Yes, I have a similar patch I made in my experimental
branch. I make one, IMO, slightly stronger assumption (than having a
fixed RID) that enables the check to be all POSIX.

I assume that the correct SID is always in the password field for both
passwd and group. I then search for these files for the SIDs of SYSTEM
user and Administrators group. The checks from there are the same.

The problem with this patch is, for consistency, I would have had to
do the same for checkpw() in imap-2007/src/osdep/unix/ckp_cyg.c,
which also assumes SYSTEM RID. This had two problems, a) increased
complexity, b) my method to eliminate cyg_server is to eliminate
Administrators. Firstly, I wouldn't be able to check for this using
pure POSIX, as I don't get the luxury of getgroups() until after the
user is logged in. Secondly, many users are in the Administrators
group. It would not do to eliminate them from logging in. I would need
some other heuristic to detect the cyg_server user (if I want to avoid
a known names list, like csih helper).

Thanks,
Shaddy

PS: Respectfully, you may want to do
http://cygwin.com/acronyms/#PCYMTNQREAIYR to avoid the below
situation. Thanks in advance.


Sorry for not removing your e-mail address, I  try not to forget.
I don't know imap nor the consequences of performing the emulation 
when it's not required,

just avoiding using a fixed 544.

A stronger test would be to get the privileges, but I don't know how 
to do that with Posix.
Perhaps we could add a cygwin_internal() call to detect that, if it's 
really necessary.


A Posix but somewhat cumbersome test would be to seteuid to any other 
existing uid (e.g. system).
If it succeeds, it's privileged and you can setuid back to what you 
started from.

Just brainstorming

Pierre
  

Re: cron Windows 7

[Pierre A. Humblet]

- Original Message - 
From: Shaddy Baddah
To: Pierre A. Humblet
Cc: cygwin
Sent: Wednesday, February 10, 2010 23:36


| Hi,
|
| On 11/02/2010 3:28 AM, Pierre A. Humblet wrote:
|  I got reports that cron is having problems with Cygwin 1.7.1 on
|  Windows 7 - 32 bits.
|  They occur only with seteuid method 1, not with method 2 nor method 3.
|
| Based purely on the above (and not the rest of the report... sorry) I
| suspect it might be due to a problem that has just been fixed in CVS
| (http://cygwin.com/ml/cygwin-developers/2010-02/msg00037.html). If you
| have time to kill before someone of authority intervenes, you may want
| to try a snapshot (http://cygwin.com/snapshots/) and see if it helps.
|

Thanks Shaddy, I will point this to the user.
However according to the mails on the developers' list I don't see why the
changes would apply to Method 1.

Pierre

No, that's not quite correct.  If you call LogonUser (or the cyglsa sort
of password-less authentication) successfully, the system returns the
non-elevated token as well as the elevated token as a so-called linked
token.  In case of pubkey authentication, Cygwin refers to the elevated
token and uses that to switch the user context.  In case of password
authentication it does not do that so far.

In CVS it does now.

That's fantastic. Works great (I mean in terms of elevation of privelege). I 
suspect this is 
going to please, or at least be noticed by a lot of users.




--
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: cron Windows 7

[Pierre A. Humblet]

- Original Message - 
From: Corinna Vinschen 
To: cygwin@cygwin.com
Sent: Thursday, February 11, 2010 8:41


| 
| No, that's not related.  But we had a few reports on the list already
| concerning sshd and it seemed to be a problem with using a non-Domain
| cyg_server user running sshd, which lead to a crippled token:
| http://cygwin.com/ml/cygwin/2010-01/msg00334.html
| This is not related to W7, but should be a problem starting with
| Windows Server 2003.
| 
| Pierre, you know a lot about this authentication stuff in Cygwin, you
| applied a couple of patches yourself, and you have a copyright
| assignment in place.  If you think there's another problem lurking,
| please help with debugging and patches.

In this case there are no Domain issues. On this topic, I like your
suggestion to add BUILTIN\Users when the DC does not answer.
Alternatively mkgroup could add all the domain users to the Users group 
(that way it could be customized to each site, if needed). Variations: add
such a switch to mkgroup or create a script to add the info.
 
Just to be clear I attempted to reproduce on Vista, but there it worked fine.
I don't have access to more advanced systems.

So the only bug I can fix is to add the missing space in get_registry_hive_path 
:(

I can also look into pruning out unneeded (and expensive on Win 7) calls
to fhandler_console::need_invisible
I have been trying to find a description of why it's needed (flashing windows?).
Are there some well defined tests?

Pierre  

--
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: cron Windows 7

[Pierre A. Humblet]

- Original Message - 
From: Corinna Vinschen 
To: cygwin@cygwin.com
Sent: Thursday, February 11, 2010 10:17
| 
| If a domain isn't involved, why fails loading user32 DLL?!?  In that
| case there should be no issue with the user account since the local
| SAM replies with the correct group list.  Or not?!?

The only strange output is
get_user_local_groups: LookupAccountName(BUILTIN\Administratoren), Win32 error 
1332
but there should be other groups, like Users.

If we want to eliminate that possibility:
Matthias , could you edit /etc/passwd and change your gid from 513 to 545,
or edit /etc/group and add your id (text, not uid) in the last (currently 
empty) 
field of the 545 group.

| Well, in the long run I'd like to drop the chance to add groups by adding
| users to /etc/group.  This allows overriding AD settings for no good reason.
I would at least keep it as backup. There have been reported cases were the DC
does not answer due to temporary network reasons.

B.t.w. I just tried mkgroup -lu on my local XP (still 1.5). It does NOT 
populate users
in some groups, in particular  Users (545)
Also when I ssh into my home XP (1.7), I get 
mkgroup (376): [1722] The RPC server is unavailable.
both with explicit passwd or when using authorized_keys.

Pierre

--
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: cron Windows 7

[Pierre A. Humblet]

- Original Message - 
From: Corinna Vinschen 
To: cygwin@cygwin.com
Sent: Thursday, February 11, 2010 13:52
| 
| Uh oh.  Is the name of the BUILTIN group not BUILTIN on non-English
| systems?  If so, the code in get_user_local_groups must be changed to
| emit the correct name, rather than just storing the fixed string
| BUILTIN\\ in builtin_grp.

Will do, this weekend at the latest. Matthias did a preliminary test on Win 7.
I learned that in German BUILTIN is VORDEFINIERT :)
I wonder if the translation is a Win 7 feature or if has been there all the 
time.

Pierre 


--
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: dup3/O_CLOEXEC/F_DUPFD_CLOEXEC

[Pierre A. Humblet]

At 05:52 PM 1/15/2010, Pierre A. Humblet wrote:


The scenario you describe (one packet only, with a long delay between accept
and WSAEventSelect) could easily be tested to settle the matter.
Put a sleep before fdsock !


To close the matter, I have done just that, putting a 60 s sleep in 
:accept4 between the call to Windows accept and fdsock. Packet 
doesn't get lost :)

Server:
2010_1_17.22:31:41 Listening
2010_1_17.22:32:43 Accepted
2010_1_17.22:32:43 Read 6 hello
Client:
2010_1_17.22:31:43 Connecting to localhost
2010_1_17.22:31:43 Connected to localhost
2010_1_17.22:31:43 Written 6 hello
2010_1_17.22:32:58 Exiting

Pierre

Re: dup3/O_CLOEXEC/F_DUPFD_CLOEXEC

[Pierre A. Humblet]

- Original Message - 
From: Corinna Vinschen 
To: cygwin-patches
Sent: Friday, January 15, 2010 10:42

| On Jan 14 17:09, Corinna Vinschen wrote:
|  On Jan 14 08:39, Pierre A. Humblet wrote:
|   
|   For the same reason we should also have SOCK_CLOEXEC, and
|   SOCK_NONBLOCK while we are at it. I would use them in minires.
|  
|  Sure, but probably not yet, as far as my hack time is concerned.  But
|  of course SHTDI, PTC, and all that.  I'd be glad for it, actually.
| 
| It was simpler than I anticipated.  I just applied a patch to implement
| accept4, and SOCK_NONBLOCK as well as SOCK_CLOEXEC for socket,
| socketpair and accept4.
 
Thanks, I was just looking into that.
I see an issue with accept/accept4 and was going to ask you how to handle it.

Before your changes in Cygwin the socket returned by accept had the same 
blocking
(and async) property as the listening socket.
Apparently this conforms to BSD but not to Linux (even old versions without 
accept4),
http://www.kernel.org/doc/man-pages/online/pages/man2/accept.2.html
POSIX is silent on the topic.

After your changes the new socket is non-blocking if either the listening 
socket was
non-blocking or SOCK_NONBLOCK is specified. This does not conform to Linux.

Why not have accept4 conform to Linux but keep the old behavior of accept by
changing accept in net.cc to 
res = fh-accept4 (peer, len, fh-is_nonblocking () ? SOCK_NONBLOCK : 0);

There is a similar Linux discrepancy with async_io. 

Pierre

Re: dup3/O_CLOEXEC/F_DUPFD_CLOEXEC

[Pierre A. Humblet]

- Original Message - 
From: Corinna Vinschen
To: cygwin-patches
Sent: Friday, January 15, 2010 15:34


| On Jan 15 21:22, Corinna Vinschen wrote:
|  On Jan 15 15:04, Pierre A. Humblet wrote:
|   I see an issue with accept/accept4 and was going to ask you how to
|   handle it.
|  
|   Before your changes in Cygwin the socket returned by accept had the
|   same blocking (and async) property as the listening socket.
|   Apparently this conforms to BSD but not to Linux (even old versions
|   without accept4),
|   http://www.kernel.org/doc/man-pages/online/pages/man2/accept.2.html
|   POSIX is silent on the topic.
|  
|   After your changes the new socket is non-blocking if either the
|   listening socket was non-blocking or SOCK_NONBLOCK is specified. This
|   does not conform to Linux.
|  
|   Why not have accept4 conform to Linux but keep the old behavior of accept 
by
|   changing accept in net.cc to
|   res = fh-accept4 (peer, len, fh-is_nonblocking () ? SOCK_NONBLOCK : 0);
|  
|   There is a similar Linux discrepancy with async_io.
| 
|  I have no problem to change the SOCK_NONBLOCK stuff as you proposed.
| 
|  I don't like the idea to introduce such a new flag for ASYNC which
|  doesn't exist on Linux, though.  How important is the async mode anyway?
|  Will we really get any problems with existing apps if we switch to the
|  Linux behaviour for async?
|
| Oh, hang on.  I guess we should better stick to the BSD behaviour.
| Any call to WSAAsyncSelect or WSAEventSelect clears Winsock's internal
| network event queue.  This could lead to connection errors.  Given
| that, the switch to a specific mode should stay the responsibility
| of the application, shouldn't it?

I know next to nothing about this but notice that :accept4 calls fdsock
which calls init_events which calls WSAEventSelect .
Isn't that what you want to avoid?
On the other hand I don't see how you can avoid it given this:

Any WSAEventSelect association and network events selection set for the 
listening socket apply 
to the accepted socket. For example, if a listening socket has WSAEventSelect 
association of 
hEventObject with FD_ACCEPT, FD_READ, and FD_WRITE, then any socket accepted on 
that listening 
socket will also have FD_ACCEPT, FD_READ, and FD_WRITE network events 
associated with the same 
hEventObject. If a different hEventObject or network events are desired, the 
application should 
call WSAEventSelect, passing the accepted socket and the desired new 
information.

Pierre

Re: dup3/O_CLOEXEC/F_DUPFD_CLOEXEC

[Pierre A. Humblet]

- Original Message - 
From: Corinna Vinschen
To: cygwin-patches
Sent: Friday, January 15, 2010 17:03


| On Jan 15 16:33, Pierre A. Humblet wrote:
|  From: Corinna Vinschen
|  | Oh, hang on.  I guess we should better stick to the BSD behaviour.
|  | Any call to WSAAsyncSelect or WSAEventSelect clears Winsock's internal
|  | network event queue.  This could lead to connection errors.  Given
|  | that, the switch to a specific mode should stay the responsibility
|  | of the application, shouldn't it?
| 
|  I know next to nothing about this but notice that :accept4 calls fdsock
|  which calls init_events which calls WSAEventSelect .
|  Isn't that what you want to avoid?
|
| Oh, right.  I'm wondering how this is supposed to work at all in
| WinSock, if an application is using, say, blocking listening sockets and
| only wants to use event driven IO on the accepted sockets.  It looks
| like this is impossible without the danger of losing information.  In
| theory, if the peer sends exactly one packet, the accepting socket could
| wait forever for the packet if it arrived before WSAEventSelect has been
| called.  The FD_READ will never show up.  The alternative is I'm just
| exaggerating the potential problem.  I don't know.
|
|  On the other hand I don't see how you can avoid it given this:
| 
|  Any WSAEventSelect association and network events selection set for the 
listening socket 
apply
|  to the accepted socket. For example, if a listening socket has 
WSAEventSelect association of
|  hEventObject with FD_ACCEPT, FD_READ, and FD_WRITE, then any socket 
accepted on that 
listening
|  socket will also have FD_ACCEPT, FD_READ, and FD_WRITE network events 
associated with the 
same
|  hEventObject. If a different hEventObject or network events are desired, 
the application 
should
|  call WSAEventSelect, passing the accepted socket and the desired new 
information.
|
| The event mask is not the problem since the mask given to WSAEventSelect
| is always the same in Cygwin, the whole set, regardless of how the
| socket is used.  The problem is that every socket needs its own
| event object so WSAEventSelect has to be called anyway.

I agree. It would be nice if the new event could be initialized to the value of 
the old.
Then we could have too many events for the new socket, but that's OK.

I am also wondering if we are misreading the doc. It says:
For FD_READ, FD_OOB, and FD_ACCEPT network events, network event recording
and event object signaling are level-triggered.
and it goes on to provide an example where the event is reenabled if there is 
still data.
The example given about the clears the internal network event record is of a
completely different nature.
The scenario you describe (one packet only, with a long delay between accept
and WSAEventSelect) could easily be tested to settle the matter.
Put a sleep before fdsock !

| What this means is, the accepted socket isn't in async mode anymore
| since the WSAEventSelect call in init_events has ended it.  So the async
| flag is erroneously preserved and we will have to apply this patch AFAICS.

At least we follow Linux :)

Pierre

Re: dup3/O_CLOEXEC/F_DUPFD_CLOEXEC

[Pierre A. Humblet]

At 08:17 AM 1/14/2010, Corinna Vinschen wrote:

On Jan 14 06:02, Eric Blake wrote:


 In a multi-threaded app, any fd that is opened only temporarily, such as
 the one in mq_open, should be opened with O_CLOEXEC, so that no other
 thread can win a race and do a fork/exec inside the window when the
 temporary fd was open.  So even though mq_open does not leak an fd to the
 current process, it should pass O_CLOEXEC as part of its internal open()
 call in order to avoid leaking the fd to unrelated child processes.

Uh, ok, that makes sense.

I'll send a revised patch later today.  It will also include the pipe2
implementation.


For the same reason we should also have SOCK_CLOEXEC, and 
SOCK_NONBLOCK while we are at it. I would use them in minires.


Pierre

Re: 1.7.0(0.214/5/3) cron service appears to be working, but no results are found

[Pierre A. Humblet]

- Original Message - 
From: Larry W. Virden
To: Cygwin
Sent: Thursday, December 03, 2009 11:05


| --- On Wed, 12/2/09, Pierre A. Humblet pierre.humb...@ieee.org wrote:
|
|
| 
|  Larry,
| 
|  Everything looks fine to me. Cron runs, reloads the crontab
|  when it changes and execs the
|  commands.
|
| Well, in one sense that is good news - that is, that at least we have things 
set up 
appropriately.
|
snip
|
| I do know that we don't have a sendmail/exim/ssmtp set up in our Cygwin 1.7 
environment. 
Normally in a Unix/Linux type environment, cron would email errors to me. In 
the cron README 
file, I see that what I should be seeing is a cron.log file if there are any 
errors. I don't 
have a $HOME/cron.log (but maybe HOME isn't defined in the cron environment).
| The readme also mentions /tmp/cron*.log and /tmp/cron*log.err, but I don't 
have one of those 
either.
|
Right, if you don't install a mailer, cron writes what would be in the mail to 
a cron.log file 
in the HOME directory. HOME is obtained from /etc/password, if not defined in 
the crontab.

| The readme goes on to mention /etc/cron.d and /etc/crontab but neither of 
these exist in my 
environment. Should they, and if so, does anyone have any idea what the 
specifics are for 
creating them? I only see references to their existence in the cron readme.
|
That's optional, don't worry.

snip
| However, at one point in time, MKS Toolkit was installed here. For the past 
few months, an 
installer file remained, but the actual files used for services, etc. were 
removed. I worked 
with the admin this morning to force the removal of even the installation files 
today.  About 
the only thing left are a few registry entries the admin said had to do with 
license info, etc.

I don't think that's relevant.
| 
|  So either the exec fails (unfortunately that is not
|  reported) or some error occurs. Are there
|  any cron related files in /tmp or in the home directory of
|  lwv27 ? If so do they contain useful
|  info?
|
| There do not appear to be any cron related files in /tmp or /home/lwv27.

I think it's a problem with the exec. Here is what you should do to help:
1) Set your crontab to do something very simple (touch /tmp/xxx) every minute 
(* * * * *)
2) Launch cron, or if already running, wait one minute until it has reloaded 
the crontab
3) With ps -a identify the cron daemon pid
4) In bash, type
strace -p cron_pid   |   tee strace.txt
Do that at a time where cron is inactive, i.e. away from a minute boundary (use 
date).
This will trace cron and its subprocesses, displaying the text on the screen 
and saving it in 
strace.txt
Output will only appear initially and then every minute.
You may have to be in the Administrators group on your machine to do that. If 
need be ask
your admin to help.
5) After two cron runs, stop strace
To do that, open another bash window and type kill -9 cron_pid

Send me the strace.txt file as an attachment.

Thanks for your help

Pierre


--
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: 1.7.0(0.214/5/3) cron service appears to be working, but no results are found

[Pierre A. Humblet]

- Original Message - 
From: Larry W. Virden
To: Cygwin
Sent: Wednesday, December 02, 2009 15:28


|I have been struggling to get Cygwin 1.7 cron to execute. I've been working 
with the admin who 
has rights to install Cygwin to get things set up appropriately. After another 
round of changing 
things, what I am now seeing are application event log entries that _appear_ to 
indicate that 
the cron service is running. That is, I see entries that show what appears to 
be the command 
running. The entry is listed as informational. No errors appear in the event 
log entry.
|
|
| However, when I try a simple thing like
| 12 15 * * * /usr/bin/mkdir /tmp/TEST.cron
|
| just so I can see if things are working, the time comes and goes and the
| directory isn't created. Not only that, but /var/log/cron.log is empty as is 
/var/log/cygserver.log .
|
| I am attaching the cronbug.txt file to this posting. I was wondering whether 
anyone could see 
something in the setup described that might still be causing the peculiar 
behavior.
|
| One additional note. When I run the cronbug, I see these messages:
| The report is written to the file ./cronbug.txt
| /usr/bin/cygrunsrv: warning: OpenService failed for 'TapiSrv': Win32 error 5
| Access is denied.
|
| WARNING: The Windows application log contains cron
| related errors. Lookup the details in ./cronbug.txt
|
| I think that the application log errors may be referring to the errors that 
were occurring 
when we were previously attempting to get cron running but with an incorrect 
user.
|
| I have looked several times and haven't seen any errors from today; but I 
also still don't see 
the directory I was expecting to see.

Larry,

Everything looks fine to me. Cron runs, reloads the crontab when it changes and 
execs the 
commands.
I have no idea about the OpenService failed for 'TapiSrv': Win32 error 5, but 
I don't think it 
matters.
It's normal that /var/log/cron.log is empty, errors are logged in the Windows 
log.

Just to make sure, you are running Cygwin 1.7. Did you ever have Cygwin 1.5 on 
this machine and 
use cron? I want to exclude any strange interference between the two services.

So either the exec fails (unfortunately that is not reported) or some error 
occurs. Are there 
any cron related files in /tmp or in the home directory of lwv27 ? If so do 
they contain useful 
info?

Cron has been reported to work fine under Cygwin 1.7. We don't have a lot of 
experience with it, 
but I don't see why the switch would matter.

Pierre



--
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: Cron on Windows 7 as a Service Does Not Execute Jobs

[Pierre A. Humblet]

At 06:43 PM 11/20/2009, randomerror wrote:

All,

I can't seem to get cron to execute jobs under Windows 7 (Ultimate.) 
Here are the things I've done...



Installed cygwin for all users, and fixed some permission problems.
Configured sshd and it works fine.
Configured exim (without running it as a service) and it works fine 
(delivers mail through a smart host).



Configured cron through cron-config running under cyg_server (that 
was created by sshd,) and it runs but does not execute jobs.
Cronevents shows that the job commands are running, but in reality 
they are not:


2009/11/20 17:49:02 [cyg_server] /usr/sbin/cron: PID 4080: (user) 
CMD (echo test)
2009/11/20 17:50:01 [cyg_server] /usr/sbin/cron: PID 4028: (user) 
CMD (echo test)
2009/11/20 17:53:01 [cyg_server] /usr/sbin/cron: PID 3384: (user) 
CMD (sleep 30)
2009/11/20 17:54:01 [cyg_server] /usr/sbin/cron: PID 1404: (user) 
CMD (sleep 30)
2009/11/20 18:24:01 [cyg_server] /usr/sbin/cron: PID 3928: (user) 
CMD (echo test  /tmp/abcd)
2009/11/20 18:25:01 [cyg_server] /usr/sbin/cron: PID 2004: (user) 
CMD (echo test  /tmp/abcd)


The sleep job was to test whether I can see the job run with ps; I could not.


So I ran cron from the command line (starting MinTTY as an 
Administrator) as follows:


/usr/sbin/cron -n -x ext,sch,proc,pars,load,misc,bit

This worked: jobs were being executed and output was e-mailed via exim.


Next, I tried to run cron as SYSTEM but that of course failed, with 
cron starting and immediately stopping.
Lastly, I used strace to attach to the running cron service, which 
works up until the point that the job execution would begin:


$ ps -ef
 UID PIDPPID TTY STIME COMMAND
cyg_serv3752   1   ?  13:53:57 /usr/bin/cygrunsrv
cyg_serv21723752   ?  13:53:57 /usr/sbin/sshd
cyg_serv1020   1   ?  17:47:17 /usr/bin/cygrunsrv
cyg_serv11441020   ?  17:47:17 /usr/sbin/cron
   janos3240   1   ?  18:28:21 /usr/bin/mintty
   janos11683240   0  18:28:22 /usr/bin/bash
   janos21921168   0  18:29:58 /usr/bin/ps

u...@host ~
$ strace -f -p 1144
**
Program name: C:\cygwin\usr\sbin\cron.exe (pid 1144, ppid 1020)
App version:  1005.24, api: 0.156
DLL version:  1005.25, api: 0.156
DLL build:2008-06-12 19:34
OS version:   Windows NT-6.1
Heap size:402653184
Date/Time:2009-11-20 18:35:19
**
.
.
.
  183 42989963 [main] cron 3012 build_env: envp 0x61169EB0, envc 28
   46 42990009 [main] cron 3012 child_info::child_info: subproc_ready 0x198
 8151 42998160 [main] cron 3012 spawn_guts: 3012 = spawn_guts 
(/bin/sh, C:\cygwin\bin\sh.exe -c /bin/echo test)
   98 42998258 [main] cron 3012! spawn_guts: new process name 
C:\cygwin\bin\sh.exe
  135 42998393 [main] cron 3012! _pinfo::dup_proc_pipe: duped 
wr_proc_pipe 0x4 for pid 3012(2056)

Windows process 4080 attached
Windows process 3004 attached
Windows process 3012 attached
strace: couldn't attach to subprocess 2056 for debugging, windows error 5

This crashes cron, so it needs to be restarted.


Does anybody have any pointers on what else to check or how else to 
diagnose why the jobs are not running?


Regards,

John


You have done everything right, AFAICS, and a pretty good debugging job.
I see user in the log, is that an actual user name ?

Except for that, as far as cron is concerned, everything looks OK.
Presumably you have seen a successful setuid in the strace.
Cron prints the log line and execs sh, without checking if it 
succeeds, but there

is nothing it can do about that. It's a cygwin issue.
Presumably you are using 1.7
Unfortunately I don't have Windows 7 to reproduce the problem.

Not sure what to suggest. Perhaps running strace  cron as a service
would give you more info. That will fill /var/log/cron.log pretty fast :)


Pierre (cron maintainer)




  



--
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: crontab 1.12 issuing error about

[Pierre A. Humblet]

- Original Message - 
From: Larry W. Virden 
To: Cygwin
| 
| --- On Mon, 10/26/09, Pierre A. Humblet pierre.humb...@ieee.org writes:
|  Up to now you have only described Windows problems:
|  CAS\Olentangy probably cannot login as a service or has the
|  wrong password
|  and there is some permission issue using cygrunsrv for
|  querying.
| 
|  You didn't explain what you did that caused cron to run
|  under CAS\Olentangy
|  and you never got to the point where cron was running and
|  producing any output.
| 
| Is there a web page somewhere that my administrator can read about 
| the setup? We've been googling and trying things described at sites like
| http://csc.csudh.edu/kleyba/cygwin-cron.pdf . Following that 
| cygwin-cron information, he installed the cron parts, changed the 
| permissions, ran the cron-config, ran the crontab -e. The cygrunsrvc 
| says that the cron service has been defined. From reading those 
| instructions, we expected that the cron would be running.

There are instructions in /usr/share/doc/Cygwin/cron-XXX.README
In principle running cron-config and reading the crontan and cron man
pages suffice.
In your case the main problem is the way you have setup the CAS\Olentangy
user. You have never explained that. So the suggestion is to reinstall with
cron-config and run cron under the SYSTEM account.

| 
|  As you have Windows XP you could run the cron daemon under
|  the system account.
| 
|  To debug the TapiSrv error, could you run
|  cygcheck -srv
|  and
|  cygrunsrv --list --verbose
|  and see if they produce that error?
|  You may have to redirect stdout to /dev/null to isolate
|  stderr.
| 
| 
| Thanks for the guidance. When the admin runs
| $ cygrunsrv -srv  /dev/null
| cygrunsrv: --termsig is only allowed with --install

Thanks but my request was to run cygcheck -srv

| Try 'cygrunsrv --help' for more information
| $  cygrunsrv -Q cron
| Service : cron
| Display name: Cron daemon
| Current State   : Stopped
| Command : /usr/sbin/cron -n
| 
| $ cygrunsrv --list --verbose
| Service : cron
| Display name: Cron daemon
| Current State   : Stopped
| Command : /usr/sbin/cron -n
| stdin path  : /dev/null
| stdout path : /var/log/cron.log
| stderr path : /var/log/cron.log
| Environment : CYGWIN=ntsec
| Process Type: Own Process
| Startup : Automatic
| Account : CAS\Olentangy

Thanks, everything is OK.

| We tried to run cron directly from the command line, to see if we 
| could get some kind of error message, and it started, but in the 
| event log we found:
| 2009/10/26 15:07:01 [ntsa13] /usr/sbin/cron: PID 18644: (lwv27) CMD 
| (/home/lwv27/bin/tstbash.txt  /tmp/bash.txt 21)
| 2009/10/26 15:07:02 [ntsa13] /usr/sbin/cron: PID 18644: (CRON) error 
| (can't switch user context)
| 2009/10/26 15:10:01 [ntsa13] /usr/sbin/cron: PID 16116: (lwv27) CMD 
| (/home/lwv27/bin/cron.sPATH)
| 2009/10/26 15:10:01 [ntsa13] /usr/sbin/cron: PID 16116: (CRON) error 
| (can't switch user context)

That makes perfect sense. cron started under the ntsa13 account (the admin)
and could not run your (lwv27) crontab.
Did you see anything in the log about ntsa13's crontab commands?

| 
| During searching on the internet, etc. about this error, I ran across 
| a reference to needing a passwd -R with Cygwin 1.7 so that the cron 
| could change users.

Yes, that's an alternative that avoids issues with network drives etc..
I have never tried it. You may want to start a separate thread 
to report that problem, I am not sure if the passwd maintainer will read this.
 
| When I try to register my passwd, I get this in return:
| $ passwd -R
| This functionality stores a password in the registry for usage by services
| which need to change the user context and require network access.  Typical
| applications are interactive remote logons using sshd, cron task, etc.
| This password will always tried first when any privileged application is
| about to switch the user context.
| 
| Note that storing even obfuscated passwords in the registry is not overly
| secure.  Use this feature only if the machine is adequately locked down.
| Don't use this feature if you don't need network access within a remote
| session.
| 
| You can delete your stored password by specifying an empty password.
| 
| Enter your current password:
| Re-enter your current password:
| Storing password failed: Function not implemented
| 
| When the administrator tries to run
| $ passwd -R lwv27
| all that we see is the USAGE statement for passwd.

Pierre


--
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: crontab 1.12 issuing error about

[Pierre A. Humblet]

- Original Message - 
From: Larry W. Virden
To: Cygwin
Sent: Monday, October 26, 2009 8:56


| My administrator has been trying to get the cron service to run on our cygwin 
1.7 
environments. After installing the various packages, he performed the 
permission changes on my 
machine on /etc/passwd,
| /etc/group, /var, /var/cron, /var/cron/tab.
|
| When cron-config runs, he sees:
| $ cron-config
| Cron is already installed as a service under account CAS\Olentangy.
| Do you want to remove or reinstall it? (yes/no) no
| Running cron_diagnose ...
| ... no problem found.
|
| Do you want to start the cron daemon as a service now? (yes/no) yes
| cygrunsrv: Error starting a service: StartService:  Win32 error 1069:
| The service did not start due to a logon failure.
|

snip
|
| Then, he ran
|
| $  cygrunsrv.exe -S cron
| cygrunsrv: Error starting a service: StartService:  Win32 error 1069:
| The service did not start due to a logon failure.
|
| (He is logged in as ntsa13; I am logged in as lwv27).
|
| Next, per the instructions, I ran cronbug. This gave me a file, which I'm 
attaching, and the 
following error was output to stderr rather than into the file.
|
|
| /cygdrive/c/products/cygwin_1.7/bin/cygrunsrv: warning: OpenService failed 
for 'TapiSrv': 
Win32 error 5
| Access is denied.
|
| I've checked the events viewer on this machine, and the only crontab related 
events are the 
ones mentioned in the cronevents output, which are, as I mentioned, the BEGIN 
EDIT, REPLACE, END 
EDIT, LIST messages.
|
| We are not certain what the next step should be.
|

Up to now you have only described Windows problems:
CAS\Olentangy probably cannot login as a service or has the wrong password
and there is some permission issue using cygrunsrv for querying.

You didn't explain what you did that caused cron to run under CAS\Olentangy
and you never got to the point where cron was running and producing any output.

As you have Windows XP you could run the cron daemon under the system account.

To debug the TapiSrv error, could you run
cygcheck -srv
and
cygrunsrv --list --verbose
and see if they produce that error?
You may have to redirect stdout to /dev/null to isolate stderr.

Pierre


--
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: cron cannot change user

[Pierre A. Humblet]

- Original Message - 
From: Mike Schmidt m...@intello.com
To: Pierre A. Humblet pierre.humb...@ieee.org
Cc: cygwin@cygwin.com
Sent: Friday, August 14, 2009 2:18 AM
|
| Pierre A. Humblet wrote:
|  - Original Message - 
|  From: Mike Schmidt
|  To: cygwin
|  Sent: Thursday, August 13, 2009 2:09 PM
| 
| 
|  | On all the systems where cron works I did NOT run cron-config. I used
|  | the following line to install cron:
|  | cygrunsrv --install cron --path=/usr/sbin/cron --desc='Cygwin cron
|  | service' --type=auto --neverexits -a '-n'
|  |
|  | It has always worked for me.
|  |
|  | Nothing cron-related in /tmp
|  |
|  | When it stopped working on 1 system, I ran cron-config on that system.
|  | Here is the result:
|  | snip
|  | Running cron_diagnose ...
|  | It appears that you do not have an entry for:
|  |NT AUTHORITY\SYSTEM
|  | in /etc/passwd.
| 
|  OK, that happens because your environment has
|  USERDOMAIN=NT AUTHORITY
|  USERNAME=SYSTEM
|  and that confuses cron-config (it's trying to check you have a passwd entry)
|  I suspect that you are logged in under ssh or some such.
|  It's a Cygwin issue with a long history, but it's not something to worry 
about for cron.
|  I will fix that test.
| 
| 
| True enough. I am running remotely under ssh at this point. My company
| has a number of digital signage systems in the field running windows (
| Usually it's under linux, but sometimes we have no choice) and I need to
| install cygwin along with ssh and cron snd other stuff to fit my support
| needs. So I try to do this invisibly, since otherwise I am operating in
| full view of whatever audience there may be.
|  | 
|  | attached is the cronbug.txt
|  |
|  | Note that if I run cron-config on any of the systems that work perfectly
|  | fine, I get the same warnings about the account and the environment, but
|  | when I restore the service with the cygrunserv command above, it works
|  | fine. Only this 1 system refuses. They use the same userids and
|  | configuration as far as I can tell.
| 
| 
|  What do you mean by refuses?
| 
| 
| I mean that all the cron jobs on the system that refuses are not
| executed (or their results are not kept)
| 
|  As far as I can see from the log, cron does change to the impact user and 
the command 
runs.
|  What led you to the Subject: of your e-mail?
|  What's happening  to all the  echo `date`  /tmp/date you have been running 
recently ?
|  It's kind of weird they don't run every minute.
| 
| 
| The commands don't run as far as I can tell. All of these commands log
| into logfiles in /home/impact, and this works fine if I run cron
| manually (not as a service)  or if I run the commands manually under the
| impact account. /tmp/date is properly when cron is not a service. It was
| a debug tool I put in there just to make sure that I had something that
| didn't depend on the account at all. As for the subject of my email, I
| suppose that is more a guess than anything else.
|  I also see some MAIL (mailed 56 bytes of output but got status 0x0001)
|  That would happen if /tmp is not writable. Any reason that would be the 
case ?
|  Just to be sure, please edit /bin/cronlog and change all exit 1 to exit 
123.
| 
| 
| .ls -l /:
| drwxrwx---+  2 SYSTEM root0 Aug  8 03:59 bin/
| dr-xr-xr-x   1  0 root0 Dec 31  1969 cygdrive/
| drwxrwx---+  2 SYSTEM root0 Jun 16 20:20 dev/
| drwxr-xr-x+ 10 SYSTEM root0 Aug  2 22:03 etc/
| drwxrwxrwx+  5 impact None0 Aug  8 01:20 home/
| drwxrwx---+ 11 SYSTEM root0 Aug  8 01:10 lib/
| dr-xr-xr-x   1 impact None0 Nov 30  2006 proc/
| drwxrwx---+  3 SYSTEM root0 Jun 16 20:20 srv/
| drwxrwxrwt+  2 SYSTEM root0 Aug 13 21:19 tmp/
| drwxrwx---+ 12 SYSTEM root0 Jun 16 20:19 usr/
| drwxr-xr-x+  9 SYSTEM root0 Jun 16 20:31 var/
|
| ls -l /tmp
| total 1.0K
| -rw-r--r-- 1 impact None 29 Aug 13 04:00 date
|
| The date file come from the last time I ran cron manually. When the
| system rebooted at 4am (daily reboot) cron came back as a service, and
| /tmp/date stopped.
| None of the log files written by the other commands are modified, and
| one of the commands (./agent.exe register) does a heartbeat via a wget
| to another system, which is definitely not happening.
|
| After changing the exit 1 to exit 123 in /bin/cronlog, I see no changes.
| What is that supposed to do?  I also then commented out the rm commands
| that delete the temp files. Even after the cronevents showed mail
| messages there are none of the expected  files in /tmp.
|
| I noticed on the neighbor system (that works perfectly) that even there
| the events listed in cronevents do not quite correspond to what cron
| actually does. For example, the 'check_jezam'  script  actually runs
| every minute,  based on its own log. But cronevents only records every
| second or third call.
|
| Back to the broken system: here is the log after I changed cronlog with
| exit

Re: cron cannot change user

[Pierre A. Humblet]

- Original Message - 
From: Mike Schmidt 
To: cygwin
Sent: Thursday, August 13, 2009 10:10 AM


|I am running cygwin 1.5.25-15 on a number of sites, most of the Windows
| XP. I have at least one occasion where I have two identical systems
| side-by-side, configured the same way (same logons, etc). Both systems
| run cron as a service installed via cygrunsrv, using the local system
| account.

1) did you use cron-config to start the cron daemon?
2) are there network drives involved and are they the same on the two systems?
3) do you see cron related files in /tmp?
4) run cronbug and send the file cronbug.txt as an attachment

Pierre

--
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: cron cannot change user

[Pierre A. Humblet]

- Original Message - 
From: Mike Schmidt 
To: cygwin
Sent: Thursday, August 13, 2009 2:09 PM


| On all the systems where cron works I did NOT run cron-config. I used
| the following line to install cron:
| cygrunsrv --install cron --path=/usr/sbin/cron --desc='Cygwin cron
| service' --type=auto --neverexits -a '-n'
| 
| It has always worked for me.
| 
| Nothing cron-related in /tmp
| 
| When it stopped working on 1 system, I ran cron-config on that system.
| Here is the result:
| snip 
| Running cron_diagnose ...
| It appears that you do not have an entry for:
|NT AUTHORITY\SYSTEM
| in /etc/passwd.

OK, that happens because your environment has
USERDOMAIN=NT AUTHORITY
USERNAME=SYSTEM
and that confuses cron-config (it's trying to check you have a passwd entry)
I suspect that you are logged in under ssh or some such.
It's a Cygwin issue with a long history, but it's not something to worry about 
for cron.
I will fix that test.
 
| 
| attached is the cronbug.txt
| 
| Note that if I run cron-config on any of the systems that work perfectly
| fine, I get the same warnings about the account and the environment, but
| when I restore the service with the cygrunserv command above, it works
| fine. Only this 1 system refuses. They use the same userids and
| configuration as far as I can tell.

What do you mean by refuses? 

As far as I can see from the log, cron does change to the impact user and the 
command runs.
What led you to the Subject: of your e-mail?
What's happening  to all the  echo `date`  /tmp/date you have been running 
recently ?
It's kind of weird they don't run every minute.

I also see some MAIL (mailed 56 bytes of output but got status 0x0001)
That would happen if /tmp is not writable. Any reason that would be the case ?
Just to be sure, please edit /bin/cronlog and change all exit 1 to exit 123.

Pierre

--
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: Intermittent Cron Errors

[Pierre A. Humblet]

- Original Message - 
From: Rajiv Garg
To: cygwin
Sent: Wednesday, July 08, 2009 1:14 PM


|
| Hi,
|
| We are seeing intermittent cron errors on some of our servers.  We run about
| a couple of hundred jobs on these servers, and about 5% of them fail with
| the error can't switch user context).  We enabled verbose logging, and in
| /var/log/cron.log see messages that say cannot set uid for user.  What
| is odd is that the same job, with the same user will run successfully 95% of
| the time.  So it doesn't seem to be a permission issue or configuration
| issue.
|
| Can anyone shed some light on where we should next for this?  Output from
| cronbug is attached.
|
| Thanks,
| Rajiv
|
|
| http://www.nabble.com/file/p24395640/cronbug.txt cronbug.txt
| -- 


Rajiv,


Looks like both the daemon and the job are running underder the same account 
(orderworker).
Is that your understanding? If so the setuid operation should be a noop and 
thus should never 
fail.

I don't know what happens. You are the first one to report this problem. 
Perhaps the PDC cannot 
be contacted for some reason, from time to time. Do you see that at your site?
At any rate it's a cygwin issue, not a cron issue.

Turning on verbose cron logging won't help, the failure is already visible in 
the regular log 
(included in cronbug.txt). Debugging this would require running under strace, 
but that's 
impractical given the huge amount of useless data that will be generated.

If you have the time, please compile and run the C program below, if possible 
on the machine 
where cron runs and under user orderworker.
It tries to duplicate what cron does. If the error shows up we can try to 
strace that program.

Else perhaps the most practical way out for you is to create a special version 
of cron where the 
call to setuid is bypassed when the job account is identical to the daemon 
account.
That would be a one liner in do_command.c . If you can't do that yourself I can 
provide you an 
updated cron in the coming days.

**
#include sys/types.h
#include grp.h
#include stdio.h
#include unistd.h

main()
{
   int uid, gid, i;
   char * name = getlogin();
   uid = getuid();
   gid = getgid();
   printf(name %s uid %d gid %d\n, name, uid, gid);

   for (i = 0; ; i++) {
if (initgroups(name, gid))
   printf(Initgroups failure at i = %d \n, i);

if (setuid(uid)) {
   printf(Setuid failure at i = %d \n, i);
   exit(1);
}
if (!(i  0XFF)) printf(%d\n, i);
   }
}


Pierre


--
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: Intermittent Cron Errors

[Pierre A. Humblet]

- Original Message - 
From: Rajiv Garg
To: Pierre A. Humblet
Sent: Wednesday, July 08, 2009 5:47 PM
Subject: Re: Intermittent Cron Errors


|
| Pierre,
|
| Thanks for your reply.
|
| Yes, both the job and service are running under the same account 
(orderworker).  I was looking 
into this a bit more, and found that we are getting the following event in our 
security event 
log at the exact time of the cron can't switch user context error.
|
| Event Type:   Failure Audit
| Event Source:Security
| Event Category: Privilege Use
| Event ID:   577
| Date:   7/8/2009
| Time:  4:30:17 PM
| User:  domain\orderworker
| Computer:  OMS1
| Description:
| Privileged Service Called:
| Server:   NT Local Security Authority / Authentication 
Service
| Service:  LsaRegisterLogonProcess()
| Primary User Name:OMS1$
| Primary Domain: domain
| Primary Logon ID:   (0x0,0x3E7)
| Client User Name:  orderworker
| Client Domain:
| Client Logon ID: (0x0,0xF1C649B8)
| Privileges: SeTcbPrivilege
|
| This seems to confirm that it's an sporadic authentication issue between our 
server and our 
domain controllers, not cron or cygwin-related.  I'm going to try to track this 
issue down and 
failing that, may try building a special version of cron to bypass setuid per 
your suggestion. 
I should be able to handle that, but if I have trouble, I may drop you a line.
***

Rajiv,

Good investigation but I am not sure how you arrive at the conclusion.

I can reproduce the same audit failure by attempting to setuid to another user 
without being 
privileged.
strace shows the following:
   50  336755 [main] a 536 set_privilege: -1 = set_privilege ((token 6F4) 
SeTcbPrivilege, 1)
  930  337685 [main] a 536 subauth: LsaRegisterLogonProcess: -1073741759
which matches what your security log shows.

So it looks like in your case cygwin does not recognize that the setuid should 
be a noop and 
tries to get a new security token. That behavior is flagged by the security 
audit.
The attempt to get a new token may be due to a problem obtaining the groups of 
the user from the 
PDC, in an earlier call to initgroups. Unfortunately cron does not check the 
return value of 
that call.
If you can do it easily, there is some value in running the test program I sent 
you.

Pierre



--
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: Intermittent Cron Errors

[Pierre A. Humblet]

At 07:17 PM 7/8/2009, Rajiv Garg wrote:

Compiled and ran -- here's the output:

$/tmp/testcron.exe
name orderworker uid 11130 gid 10513
0
256
512
768
1024
1280
1536
1792
2048
2304
2560

I killed it at this point.  No initgroups() or setuid() failures in 
2500 tries.  Let me know your thoughts.


I am baffled. The log starts on 3/18. There were no incidents until 
4/17, then 5/8 (3x) but since 5/11 they happen several times a day. 
On 6/22 at 05:05:01 and 06/23 at 23:03:11 two jobs were started at 
the same time and both failed.


So my hunch is still that it's a problem with a PDC connection, but I 
can't explain the exact sequence. After all if the call to initgroups 
fails, the groups of the daemon will be inherited by the job and that 
should not cause a setuid failure. On the other hand if setuid tries 
to create a token when the uid doesn't change, it must be a group issue.


If you end up bypassing the call to setuid when the uids match, 
please log the non-zero return value of initgroups (in the interest 
of science).

You can look at the cron events by typing cronevents in a shell.
Let me know if you need more help.

Pierre 



--
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: Cron jobs stopped working : can't lock cron.pid .. Resouce temporarily unavailable

[Pierre A. Humblet]

- Original Message - 
From: sam naqvi 
To: cygwin@cygwin.com
Sent: Tuesday, June 09, 2009 11:48 AM


|i had setup some cron jobs on cygwin last Friday. a few of them were test 
scripts to see if the
cron is firing smoothly on the right time without errors. And there were some 
actual scripts
too.
| It was working fine on Friday, giving output to all the test scripts at 
correct times.
|
| however, it did not work for the jobs that it had to run over the weekend. in 
fact, now, it
does not even run the test scripts.
|
| an error that i could locate in var/log/Cygwin\ cron.log  file is as follows:
| /usr/sbin/cron: can't lock /var/run/cron.pid, otherpid may be 9556: Resource 
temporarily
unavailable
| please see the attachment for details.
|
| i have gone through the cygwin mail archives and general google search on any 
similar reported
problem. this problem looks similar 
(http://www.cygwin.com/ml/cygwin/2008-05/msg00280.html) but
i could not understand what is causing a lock in my case and how to fix it. i 
am a beginner in
cygwin crons and could not find the problem or the cause of it. can someone 
please help here?


You are running the cron daemon as SYSTEM on a Windows 2003 Enterprise Server.
On such a system the demon cannot change user context (setuid), thus the jobs 
don't run.

According to the log, you started using SYSTEM on May 12 but on May 13 you were 
able to
successfully run the daemon under a user named EXSAN. However on Jun 5 at 
20:34:54
you reverted to using SYSTEM All of that is clearly visible in the 
cronbug.txt file you
sent us.

The message can't lock /var/run/cron.pid probably indicates that you are 
trying to start
a new cron while one is already running.

Looks like you are not using cron-config to configure and start the daemon.

Pierre


--
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/

Re: Similar Cron issue--Cron wont do anything

[Pierre A. Humblet]

- Original Message - 
From: LAU2 
To: cygwin@cygwin.com
Sent: Thursday, April 23, 2009 7:53 PM
Subject: Re: Similar Cron issue--Cron wont do anything
| 
| Pierre A. Humblet wrote:
|  
|  
|  - Original Message - 
|  From: LAU2 
|  To: cygwin@cygwin.com
|  Sent: Thursday, April 23, 2009 11:26 AM
|  

|  *
|  Thanks. 
|  What you did with /etc/group looks wrong. If  I understand it correctly
|  you now have two lines in /etc/group with the same GID. I also notice
|  from cronbug.txt that the Users group does not display properly.
|  You may want to regenerate /etc/group, but none of the above explains
|  what we see with cron.
|  
|  The cronbug file is now complete and your crontab exists.
|  Everything looks absolutely normal.
|  cron is running as yourself but can't setuid to yourself :(
|  
|  Can you try the following:
|  1) Stop the cron service (cygrunsrv -E cron)
|  2) cd /usr/sbin
|  3) Type ./cron -x sch,load (without )
|  4) You will see immediate output, then a pause after sec-to-wait=XXX
|  Let cron runs once after that, then kill it with ^C
|  Cut and paste the output and send it to us.
|  
|  Thanks
|  
|  Pierre
|**
| 
| Below is the output. I also attached the cronbug file produced AFTER
| producing the output. The windows event log doesn't show that anything
| happened though. Normal?
| 
| **OUTPUT**
| 
| $ ./cron -x sch,load
| debug flags enabled: sch load
| [2388] cron started
| log_it: (CRON 2388) STARTUP (V5.0)
| [2388] load_database()
|Landon: [done]
| unlinking old database:
| load_database is done
| [2388] GMToff=-10800
| [2388] Target time=1240519500, sec-to-wait=40
| [2388] tick(45,20,22,3,4)
| user [Landon:1002:513:...] cmd=sh create_dir_new.sh  /home/landon/logfile
| [2388] load_database()
| [2388] spool dir mtime unch, no load needed.
| [2388] Target time=1240519560, sec-to-wait=60
| log_it: (Landon 3544) CMD (sh create_dir_new.sh  /home/landon/logfile)
| 
| **END**

Thanks for trying.
The cronbug file is not attached :(
Looks like cron ran your command and didn't log anything special.
Did create_dir_new.sh do what you wanted?
Is /home/landon/logfile as you expect?

Pierre


--
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/

Re: Similar Cron issue--Cron wont do anything

[Pierre A. Humblet]

- Original Message - 
From: LAU2 
To: cygwin@cygwin.com
Sent: Wednesday, April 22, 2009 6:04 PM


| 
| Hi I have been having similar problems with running cron on through cygwin. 
| 
| Here is what I have done so far:
| 
| 1) created a simple shell file create_new_dir.sh
| 
snip| 
| 5) checked the /var/log/cron and here is what it said
| 
| unable to set groups for myusername
| 
| 
| Any thoughts?

1) was cron installed with cron-config ?
2) run cronbug and send us the output (attach)
3) the message indicates a failure in setgrp or initgroups. That's unusual.
Is your /etc/group up to date?

Pierre


--
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/

Re: Similar Cron issue--Cron wont do anything

[Pierre A. Humblet]

- Original Message - 
From: LAU2 
To: cygwin@cygwin.com
Sent: Thursday, April 23, 2009 10:39 AM
Subject: Re: Similar Cron issue--Cron wont do anything


| Pierre A. Humblet wrote:
|  - Original Message - 
|  From: LAU2 
|  To: cygwin@cygwin.com
|  Sent: Wednesday, April 22, 2009 6:04 PM
|  
|  | 
|  | Hi I have been having similar problems with running cron on through
|  cygwin. 
|  | 
|  | Here is what I have done so far:
|  | 
|  | 1) created a simple shell file create_new_dir.sh
|  | 
|  snip| 
|  | 5) checked the /var/log/cron and here is what it said
|  | 
|  | unable to set groups for myusername
|  | 
|  | 
|  | Any thoughts?
|  
|  1) was cron installed with cron-config ?
|  2) run cronbug and send us the output (attach)
|  3) the message indicates a failure in setgrp or initgroups. That's
|  unusual.
|  Is your /etc/group up to date?
|  
|| 
| Answers
| 
| 1) yes. No problems
| 
| 2) see attached http://www.nabble.com/file/p23197369/cronbug.txt cronbug.txt 
| 
| 3) This may be my problem. I can't find /etc/group in my directories. (I
| apologize I am new to cygwin)
| 
| I should have mentioned this earlier but I am using windows vista, which
| from the cronbug file i see it says not supported. 
|
***
- I am mystified by cygcheck saying  
 Windows Longhorn/Vista (not yet supported!) 
- The cronbug file looks truncated. The last line I see is 
   118k 2008/05/09 C:\cygwin\bin\cygexpat-1.dll - os=4.0 img=1.0 sys=4.0
   The current cygwin dll and the installed services do not appear.
   Did you interrupt cronbug?
- At the time you ran cronbug, you had no crontab file. 
   So we can't check that aspect.
- The cron log indicates failure due to can't switch user context
   Yet cron is running as yourself (Langdon, uid 1002), so that shouldn't be an 
issue :(
-  You should be able to ls -l /etc/group /etc/passwd
Make sure they are readable by all and that Landon appears only once in 
/etc/passwd 

Pierre

--
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/

Re: Similar Cron issue--Cron wont do anything

[Pierre A. Humblet]

- Original Message - 
From: LAU2 
To: cygwin@cygwin.com
Sent: Thursday, April 23, 2009 11:26 AM

| LAU2 wrote:
|  
|  
|  
|  Pierre A. Humblet wrote:
|  
|  
|  - Original Message - 
|  From: LAU2 
|  To: cygwin@cygwin.com
|  Sent: Wednesday, April 22, 2009 6:04 PM
|  
|  
|  | 
|  | Hi I have been having similar problems with running cron on through
|  cygwin. 
|  | 
|  | Here is what I have done so far:
|  | 
|  | 1) created a simple shell file create_new_dir.sh
|  | 
|  snip| 
|  | 5) checked the /var/log/cron and here is what it said
|  | 
|  | unable to set groups for myusername
|  | 
|  | 
|  | Any thoughts?
|  
|  1) was cron installed with cron-config ?
|  2) run cronbug and send us the output (attach)
|  3) the message indicates a failure in setgrp or initgroups. That's
|  unusual.
|  Is your /etc/group up to date?
|  
|  Pierre
|  
|  
|  Answers
|  
|  1) yes. No problems
|  
|  2) see attached http://www.nabble.com/file/p23197369/cronbug.txt
|  cronbug.txt 
|  
|  3) This may be my problem. I can't find /etc/group in my directories. (I
|  apologize I am new to cygwin)
|  
|  I should have mentioned this earlier but I am using windows vista, which
|  from the cronbug file i see it says not supported. 
|  
| Ignore comment number 3).
| 
| I followed the instructions below:
| 
| start
| cat /etc/passwd
| 
| Look for your current Windows login name
| Then look at the fourth field. [fields are separated by colons] Note the
| value.
| This value is called a GID (group ID)
| 
| cat /etc/group
| 
| Look for the line that begins with Users.
| Look at the third field, it should be the same as the GID above.
| If not, edit /etc/group so that it agrees.
| end
| 
| They did not agree so I changed them so that they do agree. But still not
| luck. I have uploaded the new cronbug file
| 
| http://www.nabble.com/file/p23197408/cronbug.txt cronbug.txt 
| 
*
Thanks. 
What you did with /etc/group looks wrong. If  I understand it correctly
you now have two lines in /etc/group with the same GID. I also notice
from cronbug.txt that the Users group does not display properly.
You may want to regenerate /etc/group, but none of the above explains
what we see with cron.

The cronbug file is now complete and your crontab exists.
Everything looks absolutely normal.
cron is running as yourself but can't setuid to yourself :(

Can you try the following:
1) Stop the cron service (cygrunsrv -E cron)
2) cd /usr/sbin
3) Type ./cron -x sch,load (without )
4) You will see immediate output, then a pause after sec-to-wait=XXX
Let cron runs once after that, then kill it with ^C
Cut and paste the output and send it to us.

Thanks

Pierre


  

--
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/

Re: cron does not do anything

[Pierre A. Humblet]

- Original Message - 
From: Ting Zhou 
Sent: Tuesday, April 21, 2009 6:20 PM


Right on, Pierre! Thanks a lot for the clue. Finally I figured it out. There 
were two problems.

The first problem, yes, I was a bit impatient and should've waited one more 
minute. It seems 
crontab change does take more than one minute to be effective. Once I changed 
it to * * * * *, 
I saw an error message in /var/log/messages saying (CRON) error (can't cd to 
HOME), which is 
the second problem. For the record, my cygwin auto-generated /etc/passwd shows 
my home dir to be 
/cygdrive/h, which is an NT mounted share - not sure why is it set to that 
and why cron 
couldn't cd to it. Anyway, I changed it to /home/tzhou and viola, the cron is 
working.

**
To be able to use /cygdrive/h try running cron as yourself.
That's an option in cron-config

Pierre 


--
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/