hey..
I wonder about the last update of fcron.It is an update to 3.1.1, there
is a new /etc/crontab file, which is mixed
with /etc/fcronfcrontab, without update notice. The latest stable
version is 3.0.6 on the fcron homepage.
bye, jens.
On Mon, Jul 18, 2011 at 3:48 PM, Jarry wrote:
> On 18-Jul-11 21:24, Michael Mol wrote:
>>
>> On Mon, Jul 18, 2011 at 3:16 PM, Jarry wrote:
>>>
>>> On 18-Jul-11 21:07, Michael Mol wrote:
>
> -
> 2011-07-18T18:41:02+00:00 game fcron[30787]: pam_unix(fcron:session):
> session ope
On 18-Jul-11 21:24, Michael Mol wrote:
On Mon, Jul 18, 2011 at 3:16 PM, Jarry wrote:
On 18-Jul-11 21:07, Michael Mol wrote:
-
2011-07-18T18:41:02+00:00 game fcron[30787]: pam_unix(fcron:session):
session opened for user root by (uid=0)
2011-07-18T18:41:04+00:00 game fcron[30787]: pam_unix
On Mon, Jul 18, 2011 at 3:16 PM, Jarry wrote:
> On 18-Jul-11 21:07, Michael Mol wrote:
>>>
>>> -
>>> 2011-07-18T18:31:02+00:00 game fcron[30032]: pam_unix(fcron:session):
>>> session opened for user root by (uid=0)
>>> 2011-07-18T18:31:04+00:00 game fcron[30032]: pam_unix(fcron:session):
>>> s
On 18-Jul-11 21:07, Michael Mol wrote:
-
2011-07-18T18:31:02+00:00 game fcron[30032]: pam_unix(fcron:session):
session opened for user root by (uid=0)
2011-07-18T18:31:04+00:00 game fcron[30032]: pam_unix(fcron:session):
session closed for user root
2011-07-18T18:41:02+00:00 game fcron[30787]
On Mon, Jul 18, 2011 at 3:00 PM, Jarry wrote:
> Hi,
> I just checked my log-files and found these strange messages:
> -
> 2011-07-18T18:31:02+00:00 game fcron[30032]: pam_unix(fcron:session):
> session opened for user root by (uid=0)
> 2011-07-18T18:31:04+00:00 game fcron[30032]: pam_unix(fcro
Hi,
I just checked my log-files and found these strange messages:
-
2011-07-18T18:31:02+00:00 game fcron[30032]: pam_unix(fcron:session):
session opened for user root by (uid=0)
2011-07-18T18:31:04+00:00 game fcron[30032]: pam_unix(fcron:session):
session closed for user root
2011-07-18T18:4
Florian Philipp [10-10-17 13:52]:
> Am 17.10.2010 11:27, schrieb meino.cra...@gmx.de:
> > Hi,
> >
> > I want to start a script via fcron, which collects all EPG
> > informations into an xml- and into a text-file.
> > To do so, tzap needs to be run.
> > This implies, that noone is using the dvb-t
Am 17.10.2010 11:27, schrieb meino.cra...@gmx.de:
> Hi,
>
> I want to start a script via fcron, which collects all EPG
> informations into an xml- and into a text-file.
> To do so, tzap needs to be run.
> This implies, that noone is using the dvb-t interface under /dev.
>
> This cannot quaranteed
Hi,
I want to start a script via fcron, which collects all EPG
informations into an xml- and into a text-file.
To do so, tzap needs to be run.
This implies, that noone is using the dvb-t interface under /dev.
This cannot quaranteed for all cases in the future.
Can I instruct fcron to retry the e
On Tue, 22 Sep 2009 12:46:27 +0100, Stroller wrote:
> The notion of daemon mode bothers me, because it must be run by root
Users can run in daemon mode too, although that means you'll have one
daemon running for each user.
> (IIRC) and the various users all put their separate private email
>
On 21 Sep 2009, at 17:06, meino.cra...@gmx.de wrote:
...
To not to involve stdout was the hack!
Currently I am running fetchmail via fcron and does what it should
since fetchmail directly reports to /dev/null.
Sorry to seem like a numptie, but are you saying you fixed it?
The problem was sol
Stroller [09-09-21 17:13]:
>
> On 20 Sep 2009, at 16:34, meino.cra...@gmx.de wrote:
> >...
> >When using the line:
> >
> > @ 5 fetchmail -a
> >
> >nothing happens: The mail remains on the server and can be downloaded
> >with
> >
> > fetchmail -a
> >
> >from the commandline.
>
> Here my cront
On 20 Sep 2009, at 16:34, meino.cra...@gmx.de wrote:
...
When using the line:
@ 5 fetchmail -a
nothing happens: The mail remains on the server and can be downloaded
with
fetchmail -a
from the commandline.
Here my crontab says:
0-59/4 * * * */usr/bin/fetchmail > /d
On Sun, Sep 20, 2009 at 17:34, wrote:
>
> When using the line:
>
> @ 5 fetchmail -a
>
> nothing happens: The mail remains on the server and can be downloaded
> with
>
> fetchmail -a
>
> from the commandline.
>
> May be I am a little overhacked today...but what the hack I am doing
> wrong he
Hi,
I have used for testing the following combo:
Configured fetchmail for my user account and configured
procmail to deliver the mail.
I called fetchmail by hand:
It works.
In my fetchmailrc there is the line
mda "/usr/bin/procmail -d %T"
as said: When started by hand everything is fine.
- Hide quoted text -
On Wed, Oct 8, 2008 at 2:54 AM, Stroller <[EMAIL PROTECTED]> wrote:
>
> On 8 Oct 2008, at 04:10, [EMAIL PROTECTED] wrote:
>>
>> ...
>> every fcron is starting updatedb. I dont need this service on a
>> daily basis. I am starting updatedb by hand if I need a fresh db.
>> But I n
On 8 Oct 2008, at 04:10, [EMAIL PROTECTED] wrote:
...
every fcron is starting updatedb. I dont need this service on a
daily basis. I am starting updatedb by hand if I need a fresh db.
But I need a full fcron installed for other purposes, so I need
to find the script, which tells fcron to start u
Hi,
every fcron is starting updatedb. I dont need this service on a
daily basis. I am starting updatedb by hand if I need a fresh db.
But I need a full fcron installed for other purposes, so I need
to find the script, which tells fcron to start updatedb.
I have tried to disable all scripts, but i
On Tue, 2007-04-03 at 15:26 +0200, Dirk Heinrichs wrote:
> Am Montag, 2. April 2007 schrieb ext Alan McKinnon:
>
> > The OP has an interesting problem here, as root can cd into any
> > directory even if all permissions are removed.
>
> root can, but user "fcron" can't:
>
well spotted - I missed
On Tuesday 03 April 2007, Dirk Heinrichs wrote:
> # ll /usr/bin/fcrontab
> -rwsr-sr-x 1 fcron fcron 47612 19. Mär 14:15 /usr/bin/fcrontab*
Ah, there's the problem. I saw earlier that the fcron directory is suid
root, which is redundant as it has no effect. I didn't check the actual
binary though
Am Montag, 2. April 2007 schrieb ext Alan McKinnon:
> The OP has an interesting problem here, as root can cd into any
> directory even if all permissions are removed.
root can, but user "fcron" can't:
# ll /usr/bin/fcrontab
-rwsr-sr-x 1 fcron fcron 47612 19. Mär 14:15 /usr/bin/fcrontab*
> Bill,
On Tue, 2007-04-03 at 14:49 +0200, Alan McKinnon wrote:
> On Tuesday 03 April 2007, W.Kenworthy wrote:
> > Havnt rebooted though
>
> Most unlikely to make any difference whatsoever. You'll probably sit
> with exactly the same situation after the reboot as before, this ain't
> windows
>
> al
On Tuesday 03 April 2007, W.Kenworthy wrote:
> Havnt rebooted though
Most unlikely to make any difference whatsoever. You'll probably sit
with exactly the same situation after the reboot as before, this ain't
windows
alan
--
Optimists say the glass is half full,
Pessimists say the glass i
On Tue, 2007-04-03 at 10:06 +0200, Alan McKinnon wrote:
> On Tuesday 03 April 2007, Trevor Forbes wrote:
> > W.Kenworthy wrote:
...
> > [Bug 171998] sys-process/fcron-3.0.2-r1 - root can't list/edit
> > cronjobs.
>
> Getting a little OT here, but I find that a very interesting bug report.
> It se
Thanks - I searched before this was raised. At least I dont feel so
lonely now :)
BillK
On Tue, 2007-04-03 at 17:01 +0930, Trevor Forbes wrote:
> W.Kenworthy wrote:
> > Cant believe I am the only one who has this - 3 systems I have checked
> > so far are all the same - root cant access its cront
On Tuesday 03 April 2007, Trevor Forbes wrote:
> W.Kenworthy wrote:
> > Cant believe I am the only one who has this - 3 systems I have
> > checked so far are all the same - root cant access its crontab.
> > Ive tried rebuilding one without pam (fcron only), but no change.
>
> [Bug 171998] sys-proc
W.Kenworthy wrote:
> Cant believe I am the only one who has this - 3 systems I have checked
> so far are all the same - root cant access its crontab. Ive tried
> rebuilding one without pam (fcron only), but no change.
>
>
[Bug 171998] sys-process/fcron-3.0.2-r1 - root can't list/edit cronjobs.
Cant believe I am the only one who has this - 3 systems I have checked
so far are all the same - root cant access its crontab. Ive tried
rebuilding one without pam (fcron only), but no change.
bunyip ~ # esearch fcron
[ Results for search key : fcron ]
[ Applications found : 1 ]
* sys-process/f
On Monday 02 April 2007, Etaoin Shrdlu wrote:
> On Monday 2 April 2007 16:49, Alan McKinnon wrote:
> > > moriah ~ # crontab -e
> > > 22:05:13 Could not chdir to /var/spool/cron/fcrontabs: Permission
> > > denied moriah ~ #
> > >
> > > BillK
> >
> > You HAVE to do that as root
>
> The # character in
gpg: [stdin]: clearsign failed: Bad passphrase
--
gentoo-user@gentoo.org mailing list
On Monday 2 April 2007 16:49, Alan McKinnon wrote:
> > moriah ~ # crontab -e
> > 22:05:13 Could not chdir to /var/spool/cron/fcrontabs: Permission
> > denied moriah ~ #
> >
> > BillK
>
> You HAVE to do that as root
The # character in the prompt usually indicates a root shell...so I guess
the OP
On Monday 02 April 2007, W.Kenworthy wrote:
> Looks like fcron has changed its user group from cron to fcron. Once
> I realised this I have been able to add users to fcron and it works -
> for users.
>
> However I have quite a number of system level root jobs that I cant
> list or edit using cront
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
W.Kenworthy a écrit :
> Looks like fcron has changed its user group from cron to fcron. Once I
> realised this I have been able to add users to fcron and it works - for
> users.
>
> However I have quite a number of system level root jobs that I cant
Looks like fcron has changed its user group from cron to fcron. Once I
realised this I have been able to add users to fcron and it works - for
users.
However I have quite a number of system level root jobs that I cant list
or edit using crontab -e or -l on multiple systems
moriah ~ # crontab -e
35 matches
Mail list logo
