On Fri, 10 Jul 2020 14:10:30 +0200, Richard Brown <rbrown@suse.de> wrote:
On Fri, 2020-07-10 at 14:08 +0200, H.Merijn Brand wrote:
On Fri, 10 Jul 2020 13:51:10 +0200, Michal Kubecek <mkubecek@suse.cz> wrote:
On Fri, Jul 10, 2020 at 11:49:45AM +0200, Richard Brown wrote:
Chiming in late, sorry
[...]
I would vehemently oppose, as we have 3rd-party applications that write to (NOT configurable) /tmp and expect it to last there for a certain time (even after a reboot).
To workaround of that, I have created several symbolic links on /tmp to /data/tmp (or /opt/app/tmp or whatever) and I would be very unpleased to see all those symlinks disappear on a reboot. That would mean I have to write service files that fire up immediately after /tmp comes up and recreates those symlinks before the application wants to start.
I really like to keep my /tmp's as clean as possible, but sometimes it is not under our control :(
FWIW I never had to do anything like that on /usr/tmp
Those applications are in serious breach of both the FHS recommendations and POSIX requirements.
I would imagine they have a vested interest in fixing that problem.
The example I can come up with is a production system where 4 parties are involved: end-user application, management-layer, database layer, database server. Of those the management layer has been declared out-of service (dead, no maint) but the whole of the suite still depends on that for at least two more years (some weird law that causes this requirement). The owner of that product is unwilling to make any change to the product. No CVE fixes, not bug fixes, no feature request or whatever, so the engineers responsible for the end-user application and the database layer both have to work around those issues. Working with old propriatary software sometimes really takes away the fun out of ICT :( -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.31 porting perl5 on HP-UX, AIX, and Linux https://useplaintext.email https://tux.nl http://www.test-smoke.org http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org