From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31806 invoked by alias); 7 May 2004 15:06:34 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 31797 invoked from network); 7 May 2004 15:06:33 -0000 Received: from unknown (HELO sosrv34.lax9.maint.ops.us.uu.net) (206.64.118.152) by sources.redhat.com with SMTP; 7 May 2004 15:06:33 -0000 Received: from ex02.idirect.net (ex02.dmz.idirect.net [208.226.76.48]) by sosrv34.lax9.maint.ops.us.uu.net (uu-smart-$Revision: 1.4 $) with ESMTP id i47F6VI1024785 for ; Fri, 7 May 2004 15:06:32 GMT content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: CRON problems Date: Fri, 07 May 2004 15:12:00 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Harig, Mark" To: X-IsSubscribed: yes X-SW-Source: 2004-05/txt/msg00276.txt.bz2 >=20 > Hmm, seems to me like checking ownership and permissions of cron.pid > would be something the cron_diagnose.sh should do. What happened was > that you ran it initially as your normal user account, and=20 > the pid file > was created. Then when you tried to start it as a service, it was > running as the SYSTEM account which didn't have permissions=20 > to overwrite > the file. The solution would be to either just remove it and let cron > recreate it, or "chown SYSTEM:SYSTEM /var/run/cron.pid".=20=20 > Then you could > give it more restrictive permissions than 777, perhaps 640 or 600. >=20 At present, the diagnostic script only checks for the existence of /var/run/cron.pid and, if found, suggests that the user delete it before reinstalling/restarting the cron service. I agree that the script should check for SYSTEM.SYSTEM ownership and 640 permissions, but I have not been able to find any documentation specifying this. Can anyone please point me to some that specifies what the ownership and permissions of cron.pid should be? Of course, if users simply do what cron_diagnose.sh suggests today, that should resolve this particular problem (i.e., not being able to write to the cron.pid file). --- -- 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/