Re: Undeletable files after kyua test runs
On Mon, Jun 29, 2020 at 01:18:12PM -0600, Ian Lepore wrote:
> On Mon, 2020-06-29 at 21:08 +0200, Gordon Bergling wrote:
> > On Mon, Jun 29, 2020 at 11:58:47AM -0700, Rodney W. Grimes wrote:
> > > > On Mon, Jun 29, 2020 at 10:32:38AM -0700, Kevin Oberman wrote:
> > > > > On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling <
> > > > > g...@freebsd.org> wrote:
> > > > > > I recently stumbled across undeletable files that are
> > > > > > generated by kyua
> > > > > > test runs,
> > > > > > for example
> > > > > >
> > > > > > -rwxr-xr-x 1 root wheel 0 May 9 13:10
> > > > > > /tmp/kyua.aB4q62/8676/work/fileforaudit
> > > > > >
> > > > > > I haven't yet identified the test that generate those files,
> > > > > > but it is
> > > > > > impossible
> > > > > > to delete them. I have clear_tmp_enable="YES" set in the
> > > > > > /etc/rc.conf, but
> > > > > > on every boot the system argues that these file aren't
> > > > > > deletable.
> > > > > > I tried to 'rm -rf' them by hand but, even this wasn't
> > > > > > possible. I have
> > > > > > looked for
> > > > > > any extend attributes, but I didn't find any.
> > > > > >
> > > > > > Has anyone an idea how this is possible and may how these
> > > > > > files can be
> > > > > > deleted?
> > > > >
> > > > > Have you done 'ls -o' to check for flags like schg?
> > > > > --
> > > > > Kevin Oberman, Part time kid herder and retired Network
> > > > > Engineer
> > > > > E-mail: rkober...@gmail.com
> > > > > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> > > >
> > > > Argh, I haven't thought about chflags for quite some time. The
> > > > chflags
> > > > bit was set and after an
> > > >
> > > > # find /tmp/ -type f -exec chflags -R 0 {} \;
> > >
> > >^^Only files ^^ meaningless when chflags is
> > > given ONLY files
> > >
> > > You probably could of done:
> > > chflags -R 0 /tmp/
> >
> > Okay, I am currently working on an update for clear_tmp_enable="YES"
> > to include
> > a check like this. I would think that an rc option like this should
> > delete
> > everything in /tmp.
> >
>
> I disagree. One of the few things those immutable flags are good for
> is protecting files from things like an rc script or other automation
> that deletes files. Those flags are typically set and maintained by
> users and admins, and automation should not change them in order to
> delete files.
>
> The real fix we need is for the kyua tests to properly clean up after
> themselves, including fixing the flags on temporary files created or
> used by the tests, and then deleting them.
>
> -- Ian
A fix for the causing RC script was my first idea, but I had of course
the same idea that a kyua test could be fixed to not end in a state that
leads to file that has chflags set to a value that couldn't be deleted
by a job that is proposed to so.
I take this as a homework and look at the kyua scripts that created
those files.
--Gordon
signature.asc
Description: PGP signature
Re: Undeletable files after kyua test runs
> On 29. Jun 2020, at 21:18, Ian Lepore wrote:
>
> On Mon, 2020-06-29 at 21:08 +0200, Gordon Bergling wrote:
>> On Mon, Jun 29, 2020 at 11:58:47AM -0700, Rodney W. Grimes wrote:
On Mon, Jun 29, 2020 at 10:32:38AM -0700, Kevin Oberman wrote:
> On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling <
> g...@freebsd.org> wrote:
>> I recently stumbled across undeletable files that are
>> generated by kyua
>> test runs,
>> for example
>>
>> -rwxr-xr-x 1 root wheel 0 May 9 13:10
>> /tmp/kyua.aB4q62/8676/work/fileforaudit
>>
>> I haven't yet identified the test that generate those files,
>> but it is
>> impossible
>> to delete them. I have clear_tmp_enable="YES" set in the
>> /etc/rc.conf, but
>> on every boot the system argues that these file aren't
>> deletable.
>> I tried to 'rm -rf' them by hand but, even this wasn't
>> possible. I have
>> looked for
>> any extend attributes, but I didn't find any.
>>
>> Has anyone an idea how this is possible and may how these
>> files can be
>> deleted?
>
> Have you done 'ls -o' to check for flags like schg?
> --
> Kevin Oberman, Part time kid herder and retired Network
> Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Argh, I haven't thought about chflags for quite some time. The
chflags
bit was set and after an
# find /tmp/ -type f -exec chflags -R 0 {} \;
>>>
>>> ^^Only files ^^ meaningless when chflags is
>>> given ONLY files
>>>
>>> You probably could of done:
>>> chflags -R 0 /tmp/
>>
>> Okay, I am currently working on an update for clear_tmp_enable="YES"
>> to include
>> a check like this. I would think that an rc option like this should
>> delete
>> everything in /tmp.
>>
>
> I disagree. One of the few things those immutable flags are good for
> is protecting files from things like an rc script or other automation
> that deletes files. Those flags are typically set and maintained by
> users and admins, and automation should not change them in order to
> delete files.
>
> The real fix we need is for the kyua tests to properly clean up after
> themselves, including fixing the flags on temporary files created or
> used by the tests, and then deleting them.
>
+1, having a routine script remove schg automatically IMHO defeats the purpose
of setting this flag.
Cheers,
Michael
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Undeletable files after kyua test runs
On Mon, 2020-06-29 at 21:08 +0200, Gordon Bergling wrote:
> On Mon, Jun 29, 2020 at 11:58:47AM -0700, Rodney W. Grimes wrote:
> > > On Mon, Jun 29, 2020 at 10:32:38AM -0700, Kevin Oberman wrote:
> > > > On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling <
> > > > g...@freebsd.org> wrote:
> > > > > I recently stumbled across undeletable files that are
> > > > > generated by kyua
> > > > > test runs,
> > > > > for example
> > > > >
> > > > > -rwxr-xr-x 1 root wheel 0 May 9 13:10
> > > > > /tmp/kyua.aB4q62/8676/work/fileforaudit
> > > > >
> > > > > I haven't yet identified the test that generate those files,
> > > > > but it is
> > > > > impossible
> > > > > to delete them. I have clear_tmp_enable="YES" set in the
> > > > > /etc/rc.conf, but
> > > > > on every boot the system argues that these file aren't
> > > > > deletable.
> > > > > I tried to 'rm -rf' them by hand but, even this wasn't
> > > > > possible. I have
> > > > > looked for
> > > > > any extend attributes, but I didn't find any.
> > > > >
> > > > > Has anyone an idea how this is possible and may how these
> > > > > files can be
> > > > > deleted?
> > > >
> > > > Have you done 'ls -o' to check for flags like schg?
> > > > --
> > > > Kevin Oberman, Part time kid herder and retired Network
> > > > Engineer
> > > > E-mail: rkober...@gmail.com
> > > > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> > >
> > > Argh, I haven't thought about chflags for quite some time. The
> > > chflags
> > > bit was set and after an
> > >
> > > # find /tmp/ -type f -exec chflags -R 0 {} \;
> >
> >^^Only files ^^ meaningless when chflags is
> > given ONLY files
> >
> > You probably could of done:
> > chflags -R 0 /tmp/
>
> Okay, I am currently working on an update for clear_tmp_enable="YES"
> to include
> a check like this. I would think that an rc option like this should
> delete
> everything in /tmp.
>
I disagree. One of the few things those immutable flags are good for
is protecting files from things like an rc script or other automation
that deletes files. Those flags are typically set and maintained by
users and admins, and automation should not change them in order to
delete files.
The real fix we need is for the kyua tests to properly clean up after
themselves, including fixing the flags on temporary files created or
used by the tests, and then deleting them.
-- Ian
>
> > > I was able to finally delete them.
> > >
> > > Thanks for the fast respone,
> > >
> > > Gordon
>
> --Gordon
> ___
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Undeletable files after kyua test runs
On Mon, Jun 29, 2020 at 11:58:47AM -0700, Rodney W. Grimes wrote:
> > On Mon, Jun 29, 2020 at 10:32:38AM -0700, Kevin Oberman wrote:
> > > On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling wrote:
> > > > I recently stumbled across undeletable files that are generated by kyua
> > > > test runs,
> > > > for example
> > > >
> > > > -rwxr-xr-x 1 root wheel 0 May 9 13:10
> > > > /tmp/kyua.aB4q62/8676/work/fileforaudit
> > > >
> > > > I haven't yet identified the test that generate those files, but it is
> > > > impossible
> > > > to delete them. I have clear_tmp_enable="YES" set in the /etc/rc.conf,
> > > > but
> > > > on every boot the system argues that these file aren't deletable.
> > > > I tried to 'rm -rf' them by hand but, even this wasn't possible. I have
> > > > looked for
> > > > any extend attributes, but I didn't find any.
> > > >
> > > > Has anyone an idea how this is possible and may how these files can be
> > > > deleted?
> > >
> > > Have you done 'ls -o' to check for flags like schg?
> > > --
> > > Kevin Oberman, Part time kid herder and retired Network Engineer
> > > E-mail: rkober...@gmail.com
> > > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> >
> > Argh, I haven't thought about chflags for quite some time. The chflags
> > bit was set and after an
> >
> > # find /tmp/ -type f -exec chflags -R 0 {} \;
>^^Only files ^^ meaningless when chflags is given
> ONLY files
>
> You probably could of done:
> chflags -R 0 /tmp/
Okay, I am currently working on an update for clear_tmp_enable="YES" to include
a check like this. I would think that an rc option like this should delete
everything in /tmp.
> > I was able to finally delete them.
> >
> > Thanks for the fast respone,
> >
> > Gordon
--Gordon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Undeletable files after kyua test runs
> Hi Kevin,
> Hi David,
>
> On Mon, Jun 29, 2020 at 10:32:38AM -0700, Kevin Oberman wrote:
> > On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling wrote:
> > > I recently stumbled across undeletable files that are generated by kyua
> > > test runs,
> > > for example
> > >
> > > -rwxr-xr-x 1 root wheel 0 May 9 13:10
> > > /tmp/kyua.aB4q62/8676/work/fileforaudit
> > >
> > > I haven't yet identified the test that generate those files, but it is
> > > impossible
> > > to delete them. I have clear_tmp_enable="YES" set in the /etc/rc.conf, but
> > > on every boot the system argues that these file aren't deletable.
> > > I tried to 'rm -rf' them by hand but, even this wasn't possible. I have
> > > looked for
> > > any extend attributes, but I didn't find any.
> > >
> > > Has anyone an idea how this is possible and may how these files can be
> > > deleted?
> >
> > Have you done 'ls -o' to check for flags like schg?
> > --
> > Kevin Oberman, Part time kid herder and retired Network Engineer
> > E-mail: rkober...@gmail.com
> > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>
> Argh, I haven't thought about chflags for quite some time. The chflags
> bit was set and after an
>
> # find /tmp/ -type f -exec chflags -R 0 {} \;
^^Only files ^^ meaningless when chflags is given ONLY
files
You probably could of done:
chflags -R 0 /tmp/
>
> I was able to finally delete them.
>
> Thanks for the fast respone,
>
> Gordon
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
--
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Undeletable files after kyua test runs
Hi Kevin,
Hi David,
On Mon, Jun 29, 2020 at 10:32:38AM -0700, Kevin Oberman wrote:
> On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling wrote:
> > I recently stumbled across undeletable files that are generated by kyua
> > test runs,
> > for example
> >
> > -rwxr-xr-x 1 root wheel 0 May 9 13:10
> > /tmp/kyua.aB4q62/8676/work/fileforaudit
> >
> > I haven't yet identified the test that generate those files, but it is
> > impossible
> > to delete them. I have clear_tmp_enable="YES" set in the /etc/rc.conf, but
> > on every boot the system argues that these file aren't deletable.
> > I tried to 'rm -rf' them by hand but, even this wasn't possible. I have
> > looked for
> > any extend attributes, but I didn't find any.
> >
> > Has anyone an idea how this is possible and may how these files can be
> > deleted?
>
> Have you done 'ls -o' to check for flags like schg?
> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Argh, I haven't thought about chflags for quite some time. The chflags
bit was set and after an
# find /tmp/ -type f -exec chflags -R 0 {} \;
I was able to finally delete them.
Thanks for the fast respone,
Gordon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Undeletable files after kyua test runs
On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling wrote: > Hi, > > I recently stumbled across undeletable files that are generated by kyua > test runs, > for example > > -rwxr-xr-x 1 root wheel 0 May 9 13:10 > /tmp/kyua.aB4q62/8676/work/fileforaudit > > I haven't yet identified the test that generate those files, but it is > impossible > to delete them. I have clear_tmp_enable="YES" set in the /etc/rc.conf, but > on every boot the system argues that these file aren't deletable. > I tried to 'rm -rf' them by hand but, even this wasn't possible. I have > looked for > any extend attributes, but I didn't find any. > > Has anyone an idea how this is possible and may how these files can be > deleted? > > --Gordon Have you done 'ls -o' to check for flags like schg? -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Undeletable files after kyua test runs
Hi, I recently stumbled across undeletable files that are generated by kyua test runs, for example -rwxr-xr-x 1 root wheel 0 May 9 13:10 /tmp/kyua.aB4q62/8676/work/fileforaudit I haven't yet identified the test that generate those files, but it is impossible to delete them. I have clear_tmp_enable="YES" set in the /etc/rc.conf, but on every boot the system argues that these file aren't deletable. I tried to 'rm -rf' them by hand but, even this wasn't possible. I have looked for any extend attributes, but I didn't find any. Has anyone an idea how this is possible and may how these files can be deleted? --Gordon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT: swap issues and dying jails
On Mon, 29 Jun 2020 09:03:32 +0200 O. Hartmann ohartm...@walstatt.org said Due to the circumstance I have no access anymore to the host in question, I'll report a problem occured out of the blue around last week's update of CURRENT with poudriere and swapspace. Problem: under heavy load, the host dies - no ssh connection possible anymore, all jails are in the state "dead". The box in question is running CURRENT, most recent, last update yesterday morning (28th of June, around 1400 UTC). Revision numbers are added as soon I have access to the box again. The host has 16 GB phsyical RAM and 64 GB configured swap - which the kernel complains about to increase swapzone or something similar. The host runs poudriere with both CURRENT and 12-STABLE jails (both recent versions). In the past 18 months we pushed the box to the limits with poudriere allwoing 4 poudriere jobs with each 4 threads - never had any problem except slowing down the system, but always responsive anyhow and never crashing or loosing network connection. The first time the box died this way was 28th, after the last update of both host and jails has been performed 26th June, ~ 1400 UTC. Jails running 12-stable are the first poudriere jobs running and that is the state were the first crash/hung occured yesterday. Is this a known problem? There was a situation very similar to yours mentioned over the last week on freebsd-stable@. By Donald Wilde, under the title: swap space issues I believe he also used 12. There was a great deal of technical advice that appeared to improve his situation. Interestingly; he was also experiencing this on his "builder" altho he was using synth as opposed to poudriere. Maybe it'll help your situation? --Chris Kind regards, oliver ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
CURRENT: swap issues and dying jails
Due to the circumstance I have no access anymore to the host in question, I'll report a problem occured out of the blue around last week's update of CURRENT with poudriere and swapspace. Problem: under heavy load, the host dies - no ssh connection possible anymore, all jails are in the state "dead". The box in question is running CURRENT, most recent, last update yesterday morning (28th of June, around 1400 UTC). Revision numbers are added as soon I have access to the box again. The host has 16 GB phsyical RAM and 64 GB configured swap - which the kernel complains about to increase swapzone or something similar. The host runs poudriere with both CURRENT and 12-STABLE jails (both recent versions). In the past 18 months we pushed the box to the limits with poudriere allwoing 4 poudriere jobs with each 4 threads - never had any problem except slowing down the system, but always responsive anyhow and never crashing or loosing network connection. The first time the box died this way was 28th, after the last update of both host and jails has been performed 26th June, ~ 1400 UTC. Jails running 12-stable are the first poudriere jobs running and that is the state were the first crash/hung occured yesterday. Is this a known problem? Kind regards, oliver ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
