Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.misc > #56622 > unrolled thread
| Started by | Robert Riches <spamtrap42@jacob21819.net> |
|---|---|
| First post | 2024-07-02 04:19 +0000 |
| Last post | 2024-07-06 07:19 +0000 |
| Articles | 20 on this page of 81 — 21 participants |
Back to article view | Back to comp.os.linux.misc
any way to completely disable Emacs eln-cache Robert Riches <spamtrap42@jacob21819.net> - 2024-07-02 04:19 +0000
Re: any way to completely disable Emacs eln-cache "Carlos E.R." <robin_listas@es.invalid> - 2024-07-02 23:31 +0200
Re: any way to completely disable Emacs eln-cache Robert Riches <spamtrap42@jacob21819.net> - 2024-07-03 03:42 +0000
Re: any way to completely disable Emacs eln-cache The Natural Philosopher <tnp@invalid.invalid> - 2024-07-03 10:35 +0100
Re: any way to completely disable Emacs eln-cache "Carlos E.R." <robin_listas@es.invalid> - 2024-07-03 12:42 +0200
Re: any way to completely disable Emacs eln-cache Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-03 23:43 +0000
Re: any way to completely disable Emacs eln-cache Robert Riches <spamtrap42@jacob21819.net> - 2024-07-04 03:29 +0000
Re: any way to completely disable Emacs eln-cache Bobbie Sellers <blissInSanFrancisco@mouse-potato.com> - 2024-07-03 22:20 -0700
Re: any way to completely disable Emacs eln-cache Robert Riches <spamtrap42@jacob21819.net> - 2024-07-05 03:36 +0000
Re: any way to completely disable Emacs eln-cache Bobbie Sellers <blissInSanFrancisco@mouse-potato.com> - 2024-07-05 09:33 -0700
Re: any way to completely disable Emacs eln-cache Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-04 06:52 +0000
Re: any way to completely disable Emacs eln-cache Richard Kettlewell <invalid@invalid.invalid> - 2024-07-04 08:36 +0100
Re: any way to completely disable Emacs eln-cache Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-04 23:46 +0000
Re: any way to completely disable Emacs eln-cache Robert Riches <spamtrap42@jacob21819.net> - 2024-07-05 03:37 +0000
Re: any way to completely disable Emacs eln-cache Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-07-03 13:33 +0000
Re: any way to completely disable Emacs eln-cache candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2024-07-03 14:30 +0000
Re: any way to completely disable Emacs eln-cache "Carlos E. R." <robin_listas@es.invalid> - 2024-07-04 02:46 +0200
Re: any way to completely disable Emacs eln-cache Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-07-05 19:52 +0000
Re: any way to completely disable Emacs eln-cache Jack Strangio <jackstrangio@yahoo.com> - 2024-07-06 05:22 +0000
Re: any way to completely disable Emacs eln-cache Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-06 07:20 +0000
There he goes again (was: Re: any way to completely disable Emacs eln-cache) vallor <vallor@cultnix.org> - 2024-07-06 22:58 +0000
Re: There he goes again (was: Re: any way to completely disable Emacs eln-cache) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-07 01:31 +0000
Re: There he goes again (was: Re: any way to completely disable Emacs eln-cache) vallor <vallor@cultnix.org> - 2024-07-07 03:25 +0000
Re: There he goes again (was: Re: any way to completely disable Emacs eln-cache) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-07 03:59 +0000
Re: There he goes again (was: Re: any way to completely disable Emacs eln-cache) vallor <vallor@cultnix.org> - 2024-07-07 04:03 +0000
Re: There he goes again Nuno Silva <nunojsilva@invalid.invalid> - 2024-07-07 09:16 +0100
Re: There he goes again (was: Re: any way to completely disable Emacs eln-cache) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-07 22:00 +0000
Re: There he goes again "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2024-07-08 14:46 -0400
Re: There he goes again Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-08 23:33 +0000
Re: There he goes again vallor <vallor@cultnix.org> - 2024-07-08 02:10 +0000
Re: There he goes again "Carlos E. R." <robin_listas@es.invalid> - 2024-07-08 02:54 +0200
Re: There he goes again Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-08 23:35 +0000
Re: There he goes again candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2024-07-09 02:10 +0000
Re: There he goes again rbowman <bowman@montana.com> - 2024-07-09 03:27 +0000
Re: There he goes again candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2024-07-10 13:40 +0000
Re: There he goes again rbowman <bowman@montana.com> - 2024-07-10 18:57 +0000
Re: There he goes again "Carlos E. R." <robin_listas@es.invalid> - 2024-07-10 23:44 +0200
Re: There he goes again candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2024-07-13 16:00 +0000
Re: There he goes again rbowman <bowman@montana.com> - 2024-07-13 18:36 +0000
Re: There he goes again "Carlos E.R." <robin_listas@es.invalid> - 2024-07-13 22:34 +0200
Re: There he goes again Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-14 01:39 +0000
Re: There he goes again rbowman <bowman@montana.com> - 2024-07-14 04:28 +0000
Re: There he goes again Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-14 05:40 +0000
Re: There he goes again rbowman <bowman@montana.com> - 2024-07-14 07:30 +0000
Re: There he goes again Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2024-07-14 16:46 +0000
Re: There he goes again rbowman <bowman@montana.com> - 2024-07-14 20:23 +0000
Re: There he goes again Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-15 01:22 +0000
Re: There he goes again Bobbie Sellers <blissInSanFrancisco@mouse-potato.com> - 2024-07-14 16:30 -0700
Re: There he goes again rbowman <bowman@montana.com> - 2024-07-15 05:19 +0000
Re: There he goes again "26yh.0712" <26yh.0713@e6t5y.net> - 2024-07-15 21:10 -0400
Re: There he goes again D <nospam@example.net> - 2024-07-16 11:18 +0200
Re: There he goes again not@telling.you.invalid (Computer Nerd Kev) - 2024-07-17 08:40 +1000
Re: There he goes again "26yh.0712" <26yh.0713@e6t5y.net> - 2024-07-17 02:08 -0400
Re: There he goes again Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2024-07-15 16:43 +0000
Re: There he goes again candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2024-07-14 16:20 +0000
Re: There he goes again rbowman <bowman@montana.com> - 2024-07-14 20:22 +0000
Re: There he goes again Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-15 01:21 +0000
Re: There he goes again candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2024-07-15 16:30 +0000
Re: There he goes again Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-15 22:05 +0000
Re: There he goes again The Natural Philosopher <tnp@invalid.invalid> - 2024-07-14 08:49 +0100
Re: There he goes again candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2024-07-14 16:20 +0000
Re: There he goes again "Carlos E. R." <robin_listas@es.invalid> - 2024-07-09 12:57 +0200
Re: There he goes again "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2024-07-09 11:12 -0400
Re: There he goes again "Carlos E.R." <robin_listas@es.invalid> - 2024-07-12 21:09 +0200
Re: any way to completely disable Emacs eln-cache "Carlos E. R." <robin_listas@es.invalid> - 2024-07-06 12:56 +0200
Re: any way to completely disable Emacs eln-cache Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-07 01:33 +0000
Re: any way to completely disable Emacs eln-cache "Carlos E. R." <robin_listas@es.invalid> - 2024-07-07 04:10 +0200
Re: any way to completely disable Emacs eln-cache Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-07-07 02:43 +0000
Re: any way to completely disable Emacs eln-cache Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-07 03:43 +0000
Re: any way to completely disable Emacs eln-cache marrgol <marrgol@address.invalid> - 2024-07-07 12:17 +0200
Re: any way to completely disable Emacs eln-cache Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-07 22:09 +0000
Re: any way to completely disable Emacs eln-cache marrgol <marrgol@address.invalid> - 2024-07-08 01:59 +0200
Re: any way to completely disable Emacs eln-cache "Carlos E.R." <robin_listas@es.invalid> - 2024-07-12 21:12 +0200
Re: any way to completely disable Emacs eln-cache Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-07-12 19:26 +0000
Re: any way to completely disable Emacs eln-cache "Carlos E.R." <robin_listas@es.invalid> - 2024-07-12 23:10 +0200
Re: any way to completely disable Emacs eln-cache Popping Mad <rainbow@colition.gov> - 2024-07-13 19:14 -0400
Re: any way to completely disable Emacs eln-cache Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-14 02:21 +0000
Re: any way to completely disable Emacs eln-cache jgd@cix.co.uk (John Dallman) - 2024-07-06 14:10 +0100
Re: any way to completely disable Emacs eln-cache "Carlos E. R." <robin_listas@es.invalid> - 2024-07-06 16:34 +0200
Re: any way to completely disable Emacs eln-cache jgd@cix.co.uk (John Dallman) - 2024-07-06 16:20 +0100
Re: any way to completely disable Emacs eln-cache Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-06 07:19 +0000
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> |
|---|---|
| Date | 2024-07-14 16:20 +0000 |
| Subject | Re: There he goes again |
| Message-ID | <slrnv97ugl.497.candycanearter07@candydeb.host.invalid> |
| In reply to | #56924 |
rbowman <bowman@montana.com> wrote at 18:36 this Saturday (GMT): > On Sat, 13 Jul 2024 16:00:03 -0000 (UTC), candycanearter07 wrote: > >>> In some cities you can find usb sticks inserted in the mortar of a >>> wall. >>> Kind of similar to books hidden in a tree hole. >>> >>> I once found a stick in a rental flat. I did loo inside, to phone the >>> people who had just left the flat if it was important. Turned out it >>> was simply a damaged stick, worked for a while. >> >> >> I've never seen one of those in person but I have seen a couple pictures >> of those online. > > A USB flash drive, aka memory stick, aka thumb drive? I meant a usb inserted in the wall. -- user <candycane> is generated from /dev/urandom
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E. R." <robin_listas@es.invalid> |
|---|---|
| Date | 2024-07-09 12:57 +0200 |
| Subject | Re: There he goes again |
| Message-ID | <lf4jceFgleeU1@mid.individual.net> |
| In reply to | #56832 |
On 2024-07-09 01:35, Lawrence D'Oliveiro wrote:
> On Mon, 8 Jul 2024 02:54:52 +0200, Carlos E. R. wrote:
>
>> On 2024-07-07 05:59, Lawrence D'Oliveiro wrote:
>>
>>> On 7 Jul 2024 03:25:47 GMT, vallor wrote:
>>>
>>>> On Sun, 7 Jul 2024 01:31:41 -0000 (UTC), Lawrence D'Oliveiro
>>>> <ldo@nz.invalid> wrote in <v6cr5s$1kfb$1@dont-email.me>:
>>>>
>>>>> That’s not running as root now, is it?
>>>>
>>>> Yes, and that's the problem.
>>>
>>> Maybe think of GParted as Nature’s way of telling you not to run GUI
>>> tools as root.
>>
>> gparted is a GUI tool intended to be run as root.
>
> And we have seen what happens when it is.
That it works perfectly, as designed.
--
Cheers,
Carlos E.R.
[toc] | [prev] | [next] | [standalone]
| From | "David W. Hodgins" <dwhodgins@nomail.afraid.org> |
|---|---|
| Date | 2024-07-09 11:12 -0400 |
| Subject | Re: There he goes again |
| Message-ID | <op.2qndugqla3w0dxdave@hodgins.homeip.net> |
| In reply to | #56858 |
On Tue, 09 Jul 2024 06:57:18 -0400, Carlos E. R. <robin_listas@es.invalid> wrote: > On 2024-07-09 01:35, Lawrence D'Oliveiro wrote: >> On Mon, 8 Jul 2024 02:54:52 +0200, Carlos E. R. wrote: <snip> >>> gparted is a GUI tool intended to be run as root. >> And we have seen what happens when it is. > That it works perfectly, as designed. It increses the risk of things leaking to other user's on the system, if not done properly. As to running gparted as a regular user ... $ ls -l /dev/sd? brw-rw---- 1 root disk 8, 0 Jul 8 20:54 /dev/sda brw-rw---- 1 root disk 8, 16 Jul 8 20:54 /dev/sdb brw-rw---- 1 root disk 8, 32 Jul 8 20:54 /dev/sdc brw-rw---- 1 root disk 8, 48 Jul 8 20:54 /dev/sdd brw-rw---- 1 root disk 8, 64 Jul 8 20:54 /dev/sde brw-rw---- 1 root disk 8, 80 Jul 8 20:54 /dev/sdf I think member's of the disk group can do it as a regular user, but I have not tested it to see if there are other issues. Regards, Dave Hodgins
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2024-07-12 21:09 +0200 |
| Subject | Re: There he goes again |
| Message-ID | <gkb8mkxn8s.ln2@Telcontar.valinor> |
| In reply to | #56869 |
On 2024-07-09 17:12, David W. Hodgins wrote: > On Tue, 09 Jul 2024 06:57:18 -0400, Carlos E. R. > <robin_listas@es.invalid> wrote: >> On 2024-07-09 01:35, Lawrence D'Oliveiro wrote: >>> On Mon, 8 Jul 2024 02:54:52 +0200, Carlos E. R. wrote: > <snip> >>>> gparted is a GUI tool intended to be run as root. >>> And we have seen what happens when it is. >> That it works perfectly, as designed. > > It increses the risk of things leaking to other user's on the system, if > not done > properly. !! > > As to running gparted as a regular user ... > $ ls -l /dev/sd? > brw-rw---- 1 root disk 8, 0 Jul 8 20:54 /dev/sda > brw-rw---- 1 root disk 8, 16 Jul 8 20:54 /dev/sdb > brw-rw---- 1 root disk 8, 32 Jul 8 20:54 /dev/sdc > brw-rw---- 1 root disk 8, 48 Jul 8 20:54 /dev/sdd > brw-rw---- 1 root disk 8, 64 Jul 8 20:54 /dev/sde > brw-rw---- 1 root disk 8, 80 Jul 8 20:54 /dev/sdf > > I think member's of the disk group can do it as a regular user, but I > have not > tested it to see if there are other issues. Having my user belong to group "disk" increases the danger of the user doing something it shouldn't. -- Cheers, Carlos.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E. R." <robin_listas@es.invalid> |
|---|---|
| Date | 2024-07-06 12:56 +0200 |
| Message-ID | <lesm6bFasrbU1@mid.individual.net> |
| In reply to | #56679 |
On 2024-07-06 07:22, Jack Strangio wrote:
> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>>
>> The /tmp directory must be made available for programs that require
>> temporary files.
>>
>> Programs must not assume that any files or directories in /tmp are
>> preserved between invocations of the program.
>
> Exactly. **temporary** files are just that: temporary.
>
> You don't expect them to be there after a reboot, or the next time your
> program runs, or whatever.
Not fully correct :-)
The interpretation of the "rules" is that the files can be deleted, or
maybe not. You can not expect assurance that they will be there, but
neither there is assurance that they will be deleted.
The application can not be sure that the file will be there on next
boot. But it may be.
--
Cheers,
Carlos E.R.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-07-07 01:33 +0000 |
| Message-ID | <v6cr8d$1kfb$2@dont-email.me> |
| In reply to | #56691 |
On Sat, 6 Jul 2024 12:56:11 +0200, Carlos E. R. wrote: > The interpretation of the "rules" is that the files can be deleted, or > maybe not. Given that many Linux systems are using tmpfs, which is entirely RAM- based, for /tmp and other similar filesystems, that’s a guarantee that the files in there will *not* survive a reboot.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E. R." <robin_listas@es.invalid> |
|---|---|
| Date | 2024-07-07 04:10 +0200 |
| Message-ID | <leubpdFasrbU7@mid.individual.net> |
| In reply to | #56711 |
On 2024-07-07 03:33, Lawrence D'Oliveiro wrote:
> On Sat, 6 Jul 2024 12:56:11 +0200, Carlos E. R. wrote:
>
>> The interpretation of the "rules" is that the files can be deleted, or
>> maybe not.
>
> Given that many Linux systems are using tmpfs, which is entirely RAM-
> based, for /tmp and other similar filesystems, that’s a guarantee that the
> files in there will *not* survive a reboot.
openSUSE is using hard disk for /tmp, and has currently no working
periodical job to clean it.
--
Cheers,
Carlos E.R.
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2024-07-07 02:43 +0000 |
| Message-ID | <v6cvcg$5u9i$1@dont-email.me> |
| In reply to | #56713 |
On Sun, 07 Jul 2024 04:10:53 +0200, Carlos E. R. wrote: > On 2024-07-07 03:33, Lawrence D'Oliveiro wrote: >> On Sat, 6 Jul 2024 12:56:11 +0200, Carlos E. R. wrote: >> >>> The interpretation of the "rules" is that the files can be deleted, or >>> maybe not. >> >> Given that many Linux systems are using tmpfs, which is entirely RAM- >> based, for /tmp and other similar filesystems, that’s a guarantee that the >> files in there will *not* survive a reboot. Ah, but that is only /one/ of the conditions for keeping a clean /tmp directory. If you maintain a large uptime (say, even more than a few hours), you really should, periodically, clean up the contents of /tmp > openSUSE is using hard disk for /tmp, and has currently no working > periodical job to clean it. So, a (wise) openSUSE sysadmin should either look for and install the tmpwatch utility (https://github.com/pete4abw/tmpwatch) or craft their own cleanup script. Mine, btw, I called cleantmp.sh, and is little more than a sequence of find(1) commands, scheduled to run once per hour. -- Lew Pitcher "In Skills We Trust"
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-07-07 03:43 +0000 |
| Message-ID | <v6d2th$6dlv$2@dont-email.me> |
| In reply to | #56714 |
On Sun, 7 Jul 2024 02:43:28 -0000 (UTC), Lew Pitcher wrote:
> If you maintain a large uptime (say, even more than a few
> hours), you really should, periodically, clean up the contents of /tmp
On this machine:
root@theon:~ # du -ks /tmp
350812 /tmp
root@theon:~ # uptime
15:43:05 up 12 days, 1:38, 7 users, load average: 0.41, 0.43, 0.45
Never really been a problem.
[toc] | [prev] | [next] | [standalone]
| From | marrgol <marrgol@address.invalid> |
|---|---|
| Date | 2024-07-07 12:17 +0200 |
| Message-ID | <v6dpv0$9e4h$1@dont-email.me> |
| In reply to | #56713 |
On 2024-07-07 at 04:10 Carlos E. R. wrote: > openSUSE is using hard disk for /tmp, and has currently no working > periodical job to clean it. Yes it does, and it's even enabled by default, it just has to be tuned up to your/sysadmin's liking. On my system (v15.4): # systemctl list-timers | grep tmp Mon 2024-07-08 05:38:18 CEST 17h left Fri 2024-07-05 12:10:56 CEST 1 day 23h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service see man systemd-tmpfiles, tmpfiles.d for details.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-07-07 22:09 +0000 |
| Message-ID | <v6f3nm$gmj7$6@dont-email.me> |
| In reply to | #56734 |
On Sun, 7 Jul 2024 12:17:04 +0200, marrgol wrote:
> # systemctl list-timers | grep tmp
I wonder if there is a “UUOG” to go with “UUOC”:
systemctl list-timers '*tmp*'
[toc] | [prev] | [next] | [standalone]
| From | marrgol <marrgol@address.invalid> |
|---|---|
| Date | 2024-07-08 01:59 +0200 |
| Message-ID | <v6fa4r$h1fg$1@dont-email.me> |
| In reply to | #56777 |
On 2024-07-08 at 00:09 Lawrence D'Oliveiro wrote:
>> # systemctl list-timers | grep tmp
>
> I wonder if there is a “UUOG” to go with “UUOC”:
>
> systemctl list-timers '*tmp*'
This produces more output than I was after.
systemctl list-timers --quiet '*tmp*'
would do, but since I can type "| grep tmp" faster than
"--quiet '*tmp*'", I'll probably stick to the former. ;-)
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2024-07-12 21:12 +0200 |
| Message-ID | <6pb8mkx3bs.ln2@Telcontar.valinor> |
| In reply to | #56734 |
On 2024-07-07 12:17, marrgol wrote: > On 2024-07-07 at 04:10 Carlos E. R. wrote: >> openSUSE is using hard disk for /tmp, and has currently no working >> periodical job to clean it. > > Yes it does, and it's even enabled by default, it just has to be tuned up > to your/sysadmin's liking. On my system (v15.4): > > # systemctl list-timers | grep tmp > Mon 2024-07-08 05:38:18 CEST 17h left Fri 2024-07-05 12:10:56 CEST 1 > day 23h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service > > see man systemd-tmpfiles, tmpfiles.d for details. > > Doesn't work. -- Cheers, Carlos.
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2024-07-12 19:26 +0000 |
| Message-ID | <v6s018$33kn6$1@dont-email.me> |
| In reply to | #56910 |
On Fri, 12 Jul 2024 21:12:05 +0200, Carlos E.R. wrote: > On 2024-07-07 12:17, marrgol wrote: >> On 2024-07-07 at 04:10 Carlos E. R. wrote: >>> openSUSE is using hard disk for /tmp, and has currently no working >>> periodical job to clean it. >> >> Yes it does, and it's even enabled by default, it just has to be tuned up >> to your/sysadmin's liking. On my system (v15.4): >> >> # systemctl list-timers | grep tmp >> Mon 2024-07-08 05:38:18 CEST 17h left Fri 2024-07-05 12:10:56 CEST 1 >> day 23h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service >> >> see man systemd-tmpfiles, tmpfiles.d for details. >> >> > > Doesn't work. Be careful; systemd-tmpfiles has been in the news recently, (see https://www.theregister.com/2024/06/20/systemd_2561_data_wipe_fix/ ) because it can delete your home directory. Specifically, with respect to systemd v256, The Register warns: "If you invoke the systemd-tmpfiles --purge command without specifying that very important config file which tells it which files to handle, version 256 will merrily purge your entire home directory." Apparently, systemd v256.1 makes some acknowledgement of this behaviour by documenting it in the systemd help files. Stay safe out there. HTH -- Lew Pitcher "In Skills We Trust"
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2024-07-12 23:10 +0200 |
| Message-ID | <vni8mkxee.ln2@Telcontar.valinor> |
| In reply to | #56912 |
On 2024-07-12 21:26, Lew Pitcher wrote: > On Fri, 12 Jul 2024 21:12:05 +0200, Carlos E.R. wrote: > >> On 2024-07-07 12:17, marrgol wrote: >>> On 2024-07-07 at 04:10 Carlos E. R. wrote: >>>> openSUSE is using hard disk for /tmp, and has currently no working >>>> periodical job to clean it. >>> >>> Yes it does, and it's even enabled by default, it just has to be tuned up >>> to your/sysadmin's liking. On my system (v15.4): >>> >>> # systemctl list-timers | grep tmp >>> Mon 2024-07-08 05:38:18 CEST 17h left Fri 2024-07-05 12:10:56 CEST 1 >>> day 23h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service >>> >>> see man systemd-tmpfiles, tmpfiles.d for details. >>> >>> >> >> Doesn't work. > > Be careful; systemd-tmpfiles has been in the news recently, > (see https://www.theregister.com/2024/06/20/systemd_2561_data_wipe_fix/ ) > because it can delete your home directory. > > Specifically, with respect to systemd v256, The Register warns: > "If you invoke the systemd-tmpfiles --purge command without specifying > that very important config file which tells it which files to handle, > version 256 will merrily purge your entire home directory." > > Apparently, systemd v256.1 makes some acknowledgement of this behaviour by > documenting it in the systemd help files. > > Stay safe out there. Ouch. Thanks for the warning. I played with it years ago, and decided it did not work. I haven't touched it again. -- Cheers, Carlos.
[toc] | [prev] | [next] | [standalone]
| From | Popping Mad <rainbow@colition.gov> |
|---|---|
| Date | 2024-07-13 19:14 -0400 |
| Message-ID | <v6v1p6$384$1@reader1.panix.com> |
| In reply to | #56912 |
On 7/12/24 3:26 PM, Lew Pitcher wrote: > Be careful; systemd-tmpfiles has been in the news recently, > (see https://www.theregister.com/2024/06/20/systemd_2561_data_wipe_fix/ ) > because it can delete your home directory. lovely...
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-07-14 02:21 +0000 |
| Message-ID | <v6vcnq$3v8ki$1@dont-email.me> |
| In reply to | #56912 |
On Fri, 12 Jul 2024 19:26:33 -0000 (UTC), Lew Pitcher wrote:
> Be careful; systemd-tmpfiles has been in the news recently,
> (see https://www.theregister.com/2024/06/20/systemd_2561_data_wipe_fix/
> ) because it can delete your home directory.
Here’s the current man page
<https://www.freedesktop.org/software/systemd/man/latest/systemd-tmpfiles.html>:
If this option is passed, all files and directories marked for
creation by the tmpfiles.d/ files specified on the command line
will be deleted. Specifically, this acts on all files and
directories marked with f, F, d, D, v, q, Q, p, L, c, b, C, w, e.
If this switch is used at least one tmpfiles.d/ file (or - for
standard input) must be specified on the command line or the
invocation will be refused, for safety reasons (as otherwise much
of the installed system files might be removed).
Hard to see how that can delete anything you haven’t asked for.
[toc] | [prev] | [next] | [standalone]
| From | jgd@cix.co.uk (John Dallman) |
|---|---|
| Date | 2024-07-06 14:10 +0100 |
| Message-ID | <memo.20240706141039.9260A@jgd.cix.co.uk> |
| In reply to | #56679 |
In article <sG6s8v.B6nB@yahoo.com>, jackstrangio@yahoo.com (Jack Strangio) wrote: > Exactly. **temporary** files are just that: temporary. A record for Unix ignorance I encountered, 20-odd years ago. A chap at work turned in his Solaris workstation to be sorted out after it began misbehaving. When he got it back, he complained that important files he'd been keeping in /tmp were gone. The sysadmins were sarcastic, as was his boss, and everyone else. John
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E. R." <robin_listas@es.invalid> |
|---|---|
| Date | 2024-07-06 16:34 +0200 |
| Message-ID | <let304FasraU1@mid.individual.net> |
| In reply to | #56692 |
On 2024-07-06 15:10, John Dallman wrote:
> In article <sG6s8v.B6nB@yahoo.com>, jackstrangio@yahoo.com (Jack Strangio)
> wrote:
>
>> Exactly. **temporary** files are just that: temporary.
>
> A record for Unix ignorance I encountered, 20-odd years ago. A chap at
> work turned in his Solaris workstation to be sorted out after it began
> misbehaving. When he got it back, he complained that important files he'd
> been keeping in /tmp were gone. The sysadmins were sarcastic, as was his
> boss, and everyone else.
Well, it was his boss fault, for not making sure he was properly
trained. I don¡t understand why he laughed.
--
Cheers,
Carlos E.R.
[toc] | [prev] | [next] | [standalone]
| From | jgd@cix.co.uk (John Dallman) |
|---|---|
| Date | 2024-07-06 16:20 +0100 |
| Message-ID | <memo.20240706162019.9260B@jgd.cix.co.uk> |
| In reply to | #56696 |
In article <let304FasraU1@mid.individual.net>, robin_listas@es.invalid (Carlos E. R.) wrote: > > When he got it back, he complained that important files he'd > > been keeping in /tmp were gone. > Well, it was his boss fault, for not making sure he was properly > trained. I don't understand why he laughed. The chap had been told. He didn't think it applied to him. John
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.os.linux.misc
csiph-web