On Wed, Apr 10, 2019 at 10:46 PM wrote:
> Peter Holm wrote:
>
> > I see this even with a single truncate on HEAD.
> >
> > $ ./truncate10.sh
> > 96 -rw-r--r-- 1 root wheel 1073741824 11 apr. 06:33 test
> > ** /dev/md10a
> > ** Last Mounted on /mnt
> > ** Phase 1 - Check Blocks and Sizes
> > IN
Peter Holm wrote:
> I see this even with a single truncate on HEAD.
>
> $ ./truncate10.sh
> 96 -rw-r--r-- 1 root wheel 1073741824 11 apr. 06:33 test
> ** /dev/md10a
> ** Last Mounted on /mnt
> ** Phase 1 - Check Blocks and Sizes
> INODE 3: FILE SIZE 1073741824 BEYOND END OF ALLOCATED FILE, SIZ
On Thu, Apr 11, 2019 at 04:47:43AM +0100, Jamie Landeg-Jones wrote:
> I've noticed a replicable disk corruption by fsck_ufs/ffs on sparse files.
>
> This is on amd/64 12-stable-20190409, but I first noticed it on
> 12-stable-20190326.
>
> I didn't notice it on my previous build of 12-stable-20190
I've noticed a replicable disk corruption by fsck_ufs/ffs on sparse files.
This is on amd/64 12-stable-20190409, but I first noticed it on
12-stable-20190326.
I didn't notice it on my previous build of 12-stable-20190107, but I
may not have had any relevant sparse files at the time, so I don't kn
On Wed, Apr 10, 2019 at 04:34:49PM -0500, Software Info wrote:
> I see. I had however copied the output of env to the etc/crontab PATH line.
> Wouldn’t that care for an environment issue though?
>
>
> Regards
> SI
>
The execution search path has no (direct) bearing on the current working
d
No. Your CWD can't be copied to a PATH variable.
For cronjobs, assume nothing. Hard code all path names. Assume the
only things in the PATH are /bin:/usr/bin, otherwise give full path
names to the programs you want to run. Assume no environmental variables
are set, assume you are on the most basic
On Thu, 11 Apr 2019 at 09:34, Software Info wrote:
>
> I see. I had however copied the output of env to the etc/crontab PATH line.
> Wouldn’t that care for an environment issue though?
When I say "environment", I mean it in the generic sense; including
working-directory.
However, best practise
On Wed, 10 Apr 2019, Software Info wrote:
OK. So although the script is located in my home directory, it doesn???t
start there? Sorry but I don???t quite understand. Could you explain a
little further please?
Both 'cp' and 'ls' are located in /bin. But if I run the 'ls' command in
/root, '
I see. I had however copied the output of env to the etc/crontab PATH line.
Wouldn’t that care for an environment issue though?
Regards
SI
Sent from Mail for Windows 10
From: Jonathan Chen
Sent: Wednesday, April 10, 2019 4:23 PM
To: Software Info
Cc: freebsd-stable@freebsd.org
Subject: Re: Cro
On Thu, 11 Apr 2019 at 09:14, Software Info wrote:
>
> OK. So although the script is located in my home directory, it doesn’t start
> there?
Correct. You cannot make any assumptions about the environment.
--
Jonathan Chen
___
freebsd-stable@freebsd.o
OK. So although the script is located in my home directory, it doesn’t start
there? Sorry but I don’t quite understand. Could you explain a little further
please?
Regards
SI
Sent from Mail for Windows 10
From: Jonathan Chen
Sent: Wednesday, April 10, 2019 3:50 PM
To: Software Info
Cc: freebsd
On Thu, 11 Apr 2019 at 08:18, Software Info wrote:
>
> Hi All
> I am trying to schedule cron to run a script. The script is in my home
> directory and so I added my home directory to the path file in /etc/crontab
> below.
> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:~/bin:
Hi All
I am trying to schedule cron to run a script. The script is in my home
directory and so I added my home directory to the path file in /etc/crontab
below.
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:~/bin:/home:/home/me
This is the crontab entry for the scheduled tas
(bcc -current and -stable for more audience)
FreeBSD CI Weekly Report 2019-04-07
===
Here is a summary of the FreeBSD Continuous Integration results for
the period from 2019-04-01 to 2019-04-07.
During this period, we have:
* 1841 builds (96% passed, 4% failed) w
On 4/10/2019 08:45, Andriy Gapon wrote:
> On 10/04/2019 04:09, Karl Denninger wrote:
>> Specifically, I *explicitly* OFFLINE the disk in question, which is a
>> controlled operation and *should* result in a cache flush out of the ZFS
>> code into the drive before it is OFFLINE'd.
>>
>> This should
On 10/04/2019 04:09, Karl Denninger wrote:
> Specifically, I *explicitly* OFFLINE the disk in question, which is a
> controlled operation and *should* result in a cache flush out of the ZFS
> code into the drive before it is OFFLINE'd.
>
> This should result in the "last written" TXG that the rema
16 matches
Mail list logo
