F18 - systemd question

Reindl Harald h.reindl at thelounge.net
Wed Mar 6 09:20:18 UTC 2013



Am 06.03.2013 10:03, schrieb Ed Greshko:
> On 03/06/13 16:52, Gabriel VLASIU wrote:
>> On Wed, 6 Mar 2013, Ed Greshko wrote:
>>
>>> So you feel the -u parameter (access time) isn't sufficient to keep from
>>> deleting directories in use?
>> If the service did not access the private tmp directory in X day, yes.
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=801943
>> 
> I see nothing in that bugzilla which states that a service has failed due to a directory in /var/tmp/systemd-private-* being deleted by the cron job while the file/directory was in use. 

and THAT it what happens!

if nothing is using the PrivateTmp which reflects /tmp
for the service all is fine and you would not need it
at all, if the service is using it you are f**ed

-------- Original-Nachricht --------
Betreff: [systemd-devel] PrivateTmp and "tmpwatch"
Datum: Sun, 03 Feb 2013 16:52:42 +0100
Von: Reindl Harald <h.reindl at thelounge.net>
Organisation: the lounge interactive design
An: Mailing-List systemd <systemd-devel at lists.freedesktop.org>

hi

may it be that PrivateTmp does not refresh the folders
/tmp/systemd-private* and if "tmpwatch" is deleting
them they are mnot re-created?

Can't create/write to file '/tmp/#sql_57d8_0.MYI' (Errcode: 2)

after restart mysqld.service which is here configured with
PrivateTmp all is fine again - recently i decided to dedicate
a special folder for mysqltmp and modified my daily logwatch
to ignore folders starting with "systemd-" but this is not
really perfect

i would suggest systemd to touch the folders regulary or watch if
they are removed by whatever foreign process and re-create them

[root at buildserver:~]$ rpm -q systemd
systemd-44-23.fc17.x86_64

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20130306/56383665/attachment.sig>


More information about the users mailing list