Just looking in var/tmp while reading the "Startup error" thread, I see
there are 730 folders of the name flatpak-cache-XXXXX, where XXXXXX are
alphanumeric characters. Dates are from 2018 to 2023. Most have a single
file named repo-Xxxxxx-lock (Xxxxxx are different alphanumeric
characters from the folder name), while a few have several files using
the same naming scheme. All the files are text files containing 0 bytes.

I don't use flatpak, and see from
<https://forums.linuxmint.com/viewtopic.php?t=303943> that it is
possible to clean out these files. They don't take up much space (just a
few MB), but it appears that Timeshift keeps them. Anyone here run a
cleanup utility as mentioned late in that thread to remove these
flatpak-cache files?

--

Jeff

Jeff Layman <Jeff@invalid.invalid>:
> Just looking in var/tmp while reading the "Startup error" thread, I see
> there are 730 folders of the name flatpak-cache-XXXXX, where XXXXXX are
> alphanumeric characters. (...)
> the same naming scheme. All the files are text files containing 0 bytes.

I have only 22 of them.

> I don't use flatpak,

Same here.

> and see from
> <https://forums.linuxmint.com/viewtopic.php?t=303943> that it is
> possible to clean out these files. They don't take up much space (just a
> few MB), but it appears that Timeshift keeps them. Anyone here run a
> cleanup utility as mentioned late in that thread to remove these
> flatpak-cache files?

sudo rm -rf /var/tmp/flatpak-cache-* got rid of them.

Yrrah

On Tue, 18 Apr 2023 08:35:39 +0100, Jeff Layman wrote:

> Just looking in var/tmp while reading the "Startup error" thread, I see
> there are 730 folders of the name flatpak-cache-XXXXX, where XXXXXX are
> alphanumeric characters. Dates are from 2018 to 2023. Most have a single
> file named repo-Xxxxxx-lock (Xxxxxx are different alphanumeric
> characters from the folder name), while a few have several files using
> the same naming scheme. All the files are text files containing 0 bytes.
>
> I don't use flatpak, and see from
> <https://forums.linuxmint.com/viewtopic.php?t=303943> that it is
> possible to clean out these files. They don't take up much space (just a
> few MB), but it appears that Timeshift keeps them. Anyone here run a
> cleanup utility as mentioned late in that thread to remove these
> flatpak-cache files?

I have my var/tmp in a tmpfs....
tmpfs /var/tmp tmpfs defaults,noatime,mode=1777,nofail

no worries

On 18/04/2023 13:40, Bubba the Corn Dog wrote:
> On Tue, 18 Apr 2023 08:35:39 +0100, Jeff Layman wrote:
>
>> Just looking in var/tmp while reading the "Startup error" thread, I see
>> there are 730 folders of the name flatpak-cache-XXXXX, where XXXXXX are
>> alphanumeric characters. Dates are from 2018 to 2023. Most have a single
>> file named repo-Xxxxxx-lock (Xxxxxx are different alphanumeric
>> characters from the folder name), while a few have several files using
>> the same naming scheme. All the files are text files containing 0 bytes.
>>
>> I don't use flatpak, and see from
>> <https://forums.linuxmint.com/viewtopic.php?t=303943> that it is
>> possible to clean out these files. They don't take up much space (just a
>> few MB), but it appears that Timeshift keeps them. Anyone here run a
>> cleanup utility as mentioned late in that thread to remove these
>> flatpak-cache files?
>
> I have my var/tmp in a tmpfs....
> tmpfs /var/tmp tmpfs defaults,noatime,mode=1777,nofail
>
> no worries
>

But contents of /var/tmp/ should not be ephemeral, contents of /tmp/ may
or may not be.

--
Chris Elvidge
England

Bubba the Corn Dog wrote:
> I have my var/tmp in a tmpfs....
> tmpfs /var/tmp tmpfs defaults,noatime,mode=1777,nofail
>
> no worries
>
Using /tmp/ and /var/tmp/ Safely

https://systemd.io/TEMPORARY_DIRECTORIES/

On Tue, 18 Apr 2023 16:02:33 +0300, Andrei Z. wrote:

> Bubba the Corn Dog wrote:
>> I have my var/tmp in a tmpfs....
>> tmpfs /var/tmp tmpfs
defaults,noatime,mode=1777,nofail
>>
>> no worries
>>
> Using /tmp/ and /var/tmp/ Safely
>
> https://systemd.io/TEMPORARY_DIRECTORIES/

to each his own

Le 18/04/2023 à 14:17, Yrrah a écrit :
> Jeff Layman <Jeff@invalid.invalid>:
>
>> and see from
>> <https://forums.linuxmint.com/viewtopic.php?t=303943> that it is
>> possible to clean out these files. They don't take up much space (just a
>> few MB), but it appears that Timeshift keeps them. Anyone here run a
>> cleanup utility as mentioned late in that thread to remove these
>> flatpak-cache files?
>
> sudo rm -rf /var/tmp/flatpak-cache-* got rid of them.
>
I had the same problem than Jeff Layman in my /var/tmp in my Linux Mint
(Mint 18.3 X86 i686 (32 bits) / Linux 4.15.0-142-generic) and the I
launch that command rm -rf /var/tmp/flatpak-cache-* in a terminal. It
does the job well.

But I have actually another question about files in /var/tmp : there is
also many files with a name of
"systemd-private-XXXXX-rtkit-daemon.service-YYYYY" where XXXXX and YYYYY
are different alphanumeric characters and the files date are fromm 2019
to 2023.
I think that files are generated by chkrootkit (but I'm not sure)

can you help me with that files ? Can I launch the command rm -rf
/var/tmp/systemd-private-*-rtkit-daemon.service-* ?
Thank you for your help

On 21/04/2023 07:57, Thebest Teddy wrote:
> Le 18/04/2023 à 14:17, Yrrah a écrit :
>> Jeff Layman <Jeff@invalid.invalid>:
>>
>>> and see from
>>> <https://forums.linuxmint.com/viewtopic.php?t=303943> that it is
>>> possible to clean out these files. They don't take up much space (just a
>>> few MB), but it appears that Timeshift keeps them. Anyone here run a
>>> cleanup utility as mentioned late in that thread to remove these
>>> flatpak-cache files?
>>
>> sudo rm -rf /var/tmp/flatpak-cache-* got rid of them.
>>
> I had the same problem than Jeff Layman in my /var/tmp in my Linux Mint
> (Mint 18.3 X86 i686 (32 bits) / Linux 4.15.0-142-generic) and the I
> launch that command rm -rf /var/tmp/flatpak-cache-* in a terminal. It
> does the job well.
>
> But I have actually another question about files in /var/tmp : there is
> also many files with a name of
> "systemd-private-XXXXX-rtkit-daemon.service-YYYYY" where XXXXX and YYYYY
> are different alphanumeric characters and the files date are fromm 2019
> to 2023.

I have only seven files with names such as:
systemd-private-df38df52718f4a1b879476dd02bdf02e-colord.service-uhSsIA

They are all dated today. If you do a search on "systemd-private" it
will tell you what they are and why they are there. And why you should
leave them alone if they have today's date on them! It's not exactly a
new issue:
<https://askubuntu.com/questions/627594/can-i-delete-older-systemd-private-md32-files-in-var-tmp>

> I think that files are generated by chkrootkit (but I'm not sure)
>
> can you help me with that files ? Can I launch the command rm -rf
> /var/tmp/systemd-private-*-rtkit-daemon.service-* ?
> Thank you for your help

It's probably safer to list the files by date, and delete those which
don't have any date since the last boot on them. Perhaps someone else
here can confirm that.

--

Jeff

Le 21/04/2023 à 09:19, Jeff Layman a écrit :
> On 21/04/2023 07:57, Thebest Teddy wrote:
>> Le 18/04/2023 à 14:17, Yrrah a écrit :
>>> Jeff Layman <Jeff@invalid.invalid>:
>
> I have only seven files with names such as:
> systemd-private-df38df52718f4a1b879476dd02bdf02e-colord.service-uhSsIA
>
> They are all dated today. If you do a search on "systemd-private" it
> will tell you what they are and why they are there. And why you should
> leave them alone if they have today's date on them! It's not exactly a
> new issue:
> <https://askubuntu.com/questions/627594/can-i-delete-older-systemd-private-md32-files-in-var-tmp>
>
Well, I have launched some commands, these are their results :

$ sudo ll /var/tmp/systemd* | wc -l
2747

$ sudo find /var/tmp/systemd*/ -maxdepth 1 -type d -printf "%T@ %Tc
%p\n" | sort -n | head -n10
1560291163.0317761500 mer. 12 juin 2019 00:12:43 CEST
/var/tmp/systemd-private-013071dcef6546c09746a8a94f6b6670-rtkit-daemon.service-1K4KMO/
1560291163.0317761500 mer. 12 juin 2019 00:12:43 CEST
/var/tmp/systemd-private-013071dcef6546c09746a8a94f6b6670-rtkit-daemon.service-1K4KMO/tmp
1560291164.1793309600 mer. 12 juin 2019 00:12:44 CEST
/var/tmp/systemd-private-013071dcef6546c09746a8a94f6b6670-colord.service-zAxjcn/
1560291164.1793309600 mer. 12 juin 2019 00:12:44 CEST
/var/tmp/systemd-private-013071dcef6546c09746a8a94f6b6670-colord.service-zAxjcn/tmp
1560363472.3195488820 mer. 12 juin 2019 20:17:52 CEST
/var/tmp/systemd-private-dfb5a46968d9460cb2ce66c841cb20e9-rtkit-daemon.service-AoUNJ4/
1560363472.3195488820 mer. 12 juin 2019 20:17:52 CEST
/var/tmp/systemd-private-dfb5a46968d9460cb2ce66c841cb20e9-rtkit-daemon.service-AoUNJ4/tmp
1560363473.2112057320 mer. 12 juin 2019 20:17:53 CEST
/var/tmp/systemd-private-dfb5a46968d9460cb2ce66c841cb20e9-colord.service-OBdfqI/
1560363473.2112057320 mer. 12 juin 2019 20:17:53 CEST
/var/tmp/systemd-private-dfb5a46968d9460cb2ce66c841cb20e9-colord.service-OBdfqI/tmp
1560547536.5199825750 ven. 14 juin 2019 23:25:36 CEST
/var/tmp/systemd-private-9f5816aa002548deb8cb84c9b42bb4ae-rtkit-daemon.service-YblXda/
1560547536.5199825750 ven. 14 juin 2019 23:25:36 CEST
/var/tmp/systemd-private-9f5816aa002548deb8cb84c9b42bb4ae-rtkit-daemon.service-YblXda/tmp

>> can you help me with that files ? Can I launch the command rm -rf
>> /var/tmp/systemd-private-*-rtkit-daemon.service-*  ?
>> Thank you for your help
>
> It's probably safer to list the files by date, and delete those which
> don't have any date since the last boot on them. Perhaps someone else
> here can confirm that.
>
So I don't want to take the risk without an answer from other people...

Jeff Layman <Jeff@invalid.invalid>:
> > But I have actually another question about files in /var/tmp : there is
> > also many files with a name of
> > "systemd-private-XXXXX-rtkit-daemon.service-YYYYY" where XXXXX and YYYYY
> > are different alphanumeric characters and the files date are fromm 2019
> > to 2023.

> I have only seven files with names such as:
> systemd-private-df38df52718f4a1b879476dd02bdf02e-colord.service-uhSsIA

Same here, all containing an empty tmp folder. BleachBit (launched as
root) doesn't delete them. That must mean something...

Yrrah

On 21/04/2023 11:07, Thebest Teddy wrote:
> Le 21/04/2023 à 09:19, Jeff Layman a écrit :
>> On 21/04/2023 07:57, Thebest Teddy wrote:
>>> Le 18/04/2023 à 14:17, Yrrah a écrit :
>>>> Jeff Layman <Jeff@invalid.invalid>:
>>
>> I have only seven files with names such as:
>> systemd-private-df38df52718f4a1b879476dd02bdf02e-colord.service-uhSsIA
>>
>> They are all dated today. If you do a search on "systemd-private" it
>> will tell you what they are and why they are there. And why you should
>> leave them alone if they have today's date on them! It's not exactly a
>> new issue:
>> <https://askubuntu.com/questions/627594/can-i-delete-older-systemd-private-md32-files-in-var-tmp>
>>
> Well, I have launched some commands, these are their results :
>
> $ sudo ll /var/tmp/systemd* | wc -l
> 2747
>
> $ sudo find /var/tmp/systemd*/ -maxdepth 1 -type d -printf "%T@ %Tc
> %p\n" | sort -n | head -n10
> 1560291163.0317761500 mer. 12 juin 2019 00:12:43 CEST
> /var/tmp/systemd-private-013071dcef6546c09746a8a94f6b6670-rtkit-daemon.service-1K4KMO/
> 1560291163.0317761500 mer. 12 juin 2019 00:12:43 CEST
> /var/tmp/systemd-private-013071dcef6546c09746a8a94f6b6670-rtkit-daemon.service-1K4KMO/tmp
> 1560291164.1793309600 mer. 12 juin 2019 00:12:44 CEST
> /var/tmp/systemd-private-013071dcef6546c09746a8a94f6b6670-colord.service-zAxjcn/
> 1560291164.1793309600 mer. 12 juin 2019 00:12:44 CEST
> /var/tmp/systemd-private-013071dcef6546c09746a8a94f6b6670-colord.service-zAxjcn/tmp
> 1560363472.3195488820 mer. 12 juin 2019 20:17:52 CEST
> /var/tmp/systemd-private-dfb5a46968d9460cb2ce66c841cb20e9-rtkit-daemon.service-AoUNJ4/
> 1560363472.3195488820 mer. 12 juin 2019 20:17:52 CEST
> /var/tmp/systemd-private-dfb5a46968d9460cb2ce66c841cb20e9-rtkit-daemon.service-AoUNJ4/tmp
> 1560363473.2112057320 mer. 12 juin 2019 20:17:53 CEST
> /var/tmp/systemd-private-dfb5a46968d9460cb2ce66c841cb20e9-colord.service-OBdfqI/
> 1560363473.2112057320 mer. 12 juin 2019 20:17:53 CEST
> /var/tmp/systemd-private-dfb5a46968d9460cb2ce66c841cb20e9-colord.service-OBdfqI/tmp
> 1560547536.5199825750 ven. 14 juin 2019 23:25:36 CEST
> /var/tmp/systemd-private-9f5816aa002548deb8cb84c9b42bb4ae-rtkit-daemon.service-YblXda/
> 1560547536.5199825750 ven. 14 juin 2019 23:25:36 CEST
> /var/tmp/systemd-private-9f5816aa002548deb8cb84c9b42bb4ae-rtkit-daemon.service-YblXda/tmp
>
>>> can you help me with that files ? Can I launch the command rm -rf
>>> /var/tmp/systemd-private-*-rtkit-daemon.service-*  ?
>>> Thank you for your help
>>
>> It's probably safer to list the files by date, and delete those which
>> don't have any date since the last boot on them. Perhaps someone else
>> here can confirm that.
>>
> So I don't want to take the risk without an answer from other people...

Following yrraH's advice, I just ran sudo rm -rf /var/tmp/flatpak-cach
and the 730 flatpak-cache folders have gone.

I've just checked the seven systemd-private...folders I have and they
are for:
bluetooth, colord, modemmanager, login, resolved, timesyncd, and upower.
All are dated today with the time of booting earlier this morning.

--

Jeff

On 21/04/2023 13:26, Yrrah wrote:
> Jeff Layman <Jeff@invalid.invalid>:
>
>>> But I have actually another question about files in /var/tmp : there is
>>> also many files with a name of
>>> "systemd-private-XXXXX-rtkit-daemon.service-YYYYY" where XXXXX and YYYYY
>>> are different alphanumeric characters and the files date are fromm 2019
>>> to 2023.
>
>> I have only seven files with names such as:
>> systemd-private-df38df52718f4a1b879476dd02bdf02e-colord.service-uhSsIA
>
> Same here, all containing an empty tmp folder. BleachBit (launched as
> root) doesn't delete them. That must mean something...

Perhaps it's somehow linked to the size being "? items". That question
mark seems very strange. I have another folder named "lost+found" in the
file system. That also has "? items" as the size, but this time it's
something dated 13/09/2018, not today. The owner is root, but that's the
same as those systemd-private-... files. Oddly, though, if in Nemo I
right-click on lost+found and select "Open as root", it does so -
another Nemo window opens showing "Elevated privileges". But the strange
thing is that the "lost+found" folder does not appear in that elevated
privileges folder list! Perhaps even more strange is that the
systemd-private-... ones do appear in the /tmp folder. If I right click
on one of them, "delete" is in the options and not greyed out - but I'm
not going to try it to see what it does!

--

Jeff

Jeff Layman wrote:

> Perhaps it's somehow linked to the size being "? items". That question
> mark seems very strange. I have another folder named "lost+found" in the
> file system. That also has "? items" as the size, but this time it's
> something dated 13/09/2018, not today. The owner is root, but that's the
> same as those systemd-private-... files. Oddly, though, if in Nemo I
> right-click on lost+found and select "Open as root", it does so -
> another Nemo window opens showing "Elevated privileges". But the strange
> thing is that the "lost+found" folder does not appear in that elevated
> privileges folder list! Perhaps even more strange is that the
> systemd-private-... ones do appear in the /tmp folder. If I right click
> on one of them, "delete" is in the options and not greyed out -  but I'm
> not going to try it to see what it does!
>

The lost+found folder is present on every disk or partition that's
formatted with the ext file system. Its purpose is to (try to) recover
files that are placed there by the system in case of a system crash.
What's in there is not human readable, so it's best to leave it as it
is. I wouldn't delete it.

On 21/04/2023 15:20, Monsieur wrote:
> Jeff Layman wrote:
>
>> Perhaps it's somehow linked to the size being "? items". That question
>> mark seems very strange. I have another folder named "lost+found" in the
>> file system. That also has "? items" as the size, but this time it's
>> something dated 13/09/2018, not today. The owner is root, but that's the
>> same as those systemd-private-... files. Oddly, though, if in Nemo I
>> right-click on lost+found and select "Open as root", it does so -
>> another Nemo window opens showing "Elevated privileges". But the strange
>> thing is that the "lost+found" folder does not appear in that elevated
>> privileges folder list! Perhaps even more strange is that the
>> systemd-private-... ones do appear in the /tmp folder. If I right click
>> on one of them, "delete" is in the options and not greyed out -  but I'm
>> not going to try it to see what it does!
>>
>
> The lost+found folder is present on every disk or partition that's
> formatted with the ext file system. Its purpose is to (try to) recover
> files that are placed there by the system in case of a system crash.
> What's in there is not human readable, so it's best to leave it as it
> is. I wouldn't delete it.

Thanks for the explanation. My file system is Ext4. Actually, I was
wrong in that the lost+found folder does appear to show in "root" Nemo.
It does, but there is no information on it. I think one issue is not
knowing how many files, or bits of them, are in that folder. Are they
taking up a few bytes, or megabytes? I just ran Catfish, asking it to
find lost+found. I didn't expect it to work but it tells me that it is
in /, and what's more is 16Kb in size.

I've never run fsck. Would running that make any changes to lost+found?

--

Jeff

Jeff Layman wrote:
> On 21/04/2023 15:20, Monsieur wrote:

>> The lost+found folder is present on every disk or partition that's
>> formatted with the ext file system. Its purpose is to (try to) recover
>> files that are placed there by the system in case of a system crash.
>> What's in there is not human readable, so it's best to leave it as it
>> is. I wouldn't delete it.
>
> Thanks for the explanation. My file system is Ext4. Actually, I was
> wrong in that the lost+found folder does appear to show in "root" Nemo.
> It does, but there is no information on it. I think one issue is not
> knowing how many files, or bits of them, are in that folder. Are they
> taking up a few bytes, or megabytes? I just ran Catfish, asking it to
> find lost+found. I didn't expect it to work but it tells me that it is
> in /, and what's more is 16Kb in size.

Same here, although Catfish does indeed say that it's 16Kb, but that's
probably the space the folder takes up on disk, even if it's empty.

>
> I've never run fsck.

No, but the installer ran it when you first installed Mint. It's part of
the installation process.

> Would running that make any changes to lost+found?

I don't think so, because it's fsck that creates and manages the
lost+found folder in the first place.

Jeff Layman wrote:
>
> I've never run fsck. Would running that make any changes to lost+found?
>
$ cat /var/log/syslog | grep fsck

> Perhaps it's somehow linked to the size being "? items". That question
> mark seems very strange. I have another folder named "lost+found" in the
> file system. That also has "? items" as the size, but this time it's
> something dated 13/09/2018, not today. The owner is root, but that's the
> same as those systemd-private-... files.

That's probably because you don't have read access to the directory, so
the file manager can't see what's in it to count the number of items.

> Oddly, though, if in Nemo I
> right-click on lost+found and select "Open as root", it does so -
> another Nemo window opens showing "Elevated privileges". But the strange
> thing is that the "lost+found" folder does not appear in that elevated
> privileges folder list!

I see you posted a later correction to this, saying that the lost+found
folders do show up when opening as root, but with no information. I use
Mint MATE, where the file manager is Caja. Here, the Caja shows that
the lost+found folders contain "0 items" when opened as "Administrator"
(i.e. root). Maybe Nemo just doesn't rescan the folders, and continues
to show the information from before it was elevated.

> Perhaps even more strange is that the
> systemd-private-... ones do appear in the /tmp folder. If I right click
> on one of them, "delete" is in the options and not greyed out -  but I'm
> not going to try it to see what it does!

systemd-private- folders show up in both /var/tmp/ and /tmp/ without
running as root here, both in Caja and `ls` output. They don't seem to
be the same folders though - a file created in the directory under /tmp/
doesn't appear when listing the contents of the corresponding directory
under /var/tmp/.

--
Mark.

On 21/04/2023 19:28, Andrei Z. wrote:
> Jeff Layman wrote:
>>
>> I've never run fsck. Would running that make any changes to lost+found?
>>
> $ cat /var/log/syslog | grep fsck

jeff@jeff-P15xEMx:~$ cat /var/log/syslog | grep fsck
Apr 16 14:38:04 jeff-P15xEMx kernel: [ 18.020733] systemd[1]:
Listening on fsck to fsckd communication Socket.
Apr 16 14:38:26 jeff-P15xEMx casper-md5check[1010]: Checking integrity,
this may take some time (or try: fsck.mode=skip)
(then repeated for each day until 22 April)

Do you know where "Logs"in Mint's menu gets its information from? I
looked at "System" and it showed events only from 18 April, not 16 April
as the above grep did. The entry is just "Listening on fsck to fsckd
communication Socket". Right-clicking on that shows the time of the log.
That is always 30 seconds before the time given in the grep!

--

Jeff

Jeff Layman wrote:
> On 21/04/2023 19:28, Andrei Z. wrote:
>> Jeff Layman wrote:
>>>
>>> I've never run fsck. Would running that make any changes to lost+found?
>>>
>> $ cat /var/log/syslog | grep fsck
>
> jeff@jeff-P15xEMx:~$ cat /var/log/syslog | grep fsck
> Apr 16 14:38:04 jeff-P15xEMx kernel: [   18.020733] systemd[1]:
> Listening on fsck to fsckd communication Socket.
> Apr 16 14:38:26 jeff-P15xEMx casper-md5check[1010]: Checking integrity,
> this may take some time (or try: fsck.mode=skip)
> (then repeated for each day until 22 April)
>
> Do you know where "Logs"in Mint's menu gets its information from? I
> looked at "System" and it showed events only from 18 April, not 16 April
> as the above grep did. The entry is just "Listening on fsck to fsckd
> communication Socket". Right-clicking on that shows the time of the log.
> That is always 30 seconds before the time given in the grep!
>
Logs is a viewer for the systemd journal.
https://wiki.gnome.org/Apps/Logs

$ journalctl | grep fsck

Journald in conjunction with syslog - systemd/Journal - ArchWiki
https://wiki.archlinux.org/title/Systemd/Journal#Journald_in_conjunction_with_syslog