[opensuse] On cleaning /tmp/systemd-private-*
Hi all, in order to remove [/var]/tmp/systemd-private-* directories that for sure are no more used, I followed Andrey's suggestion [0] and I have created the file ori@orodruin:~> cat /etc/tmpfiles.d/remove-systemd-private.conf R /tmp/systemd-private-* - - - 3d R /var/tmp/systemd-private-* - - - 3d but as you can see, I would remove directories that are at least 3 days old. The problem is that all [/var]/tmp/systemd-private-* are removed except for the one created in the current boot. I have also tried R /tmp/systemd-private-* 3d R /var/tmp/systemd-private-* 3d but with the same result. So, the question is: how do I remove only directories older than 3 days? Or is this a bug? Best, Andrea [0] http://lists.opensuse.org/opensuse/2013-05/msg00125.html -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sunday 12 May 2013 09:17:09 Andrea Turrini wrote:
Hi all, in order to remove [/var]/tmp/systemd-private-* directories that for sure are no more used, I followed Andrey's suggestion [0] and I have created the file
ori@orodruin:~> cat /etc/tmpfiles.d/remove-systemd-private.conf R /tmp/systemd-private-* - - - 3d R /var/tmp/systemd-private-* - - - 3d
but as you can see, I would remove directories that are at least 3 days old.
The problem is that all [/var]/tmp/systemd-private-* are removed except for the one created in the current boot.
I have also tried
R /tmp/systemd-private-* 3d R /var/tmp/systemd-private-* 3d
but with the same result.
So, the question is: how do I remove only directories older than 3 days? Or is this a bug?
Best, Andrea
[0] http://lists.opensuse.org/opensuse/2013-05/msg00125.html
Hello Andrea, What you want to do doesn't work because the "Age" parameter is ignored with the "R" option. See "man tmpfiles.d" for details. Have a look at the file "/usr/lib/tmpfiles.d/tmp.conf". I think that you get what you want if you comment out the two lines starting with an "X". Regards, Erwin -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/12/2013 10:37 AM, ErwinL wrote:
What you want to do doesn't work because the "Age" parameter is ignored with the "R" option. See "man tmpfiles.d" for details.
Oops, I have not noted this case. I really would like to know the rational behind this choice, since I find it very weird.
Have a look at the file "/usr/lib/tmpfiles.d/tmp.conf". I think that you get what you want if you comment out the two lines starting with an "X".
But then I have to take care of it on each update of systemd. So, the question now is: how can I remove directories older than 3 days? Or, in general, how can I override an "X" in a system provided file? Best, Andrea -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sunday 12 May 2013 11:01:00 Andrea Turrini wrote:
On 05/12/2013 10:37 AM, ErwinL wrote:
What you want to do doesn't work because the "Age" parameter is ignored with the "R" option. See "man tmpfiles.d" for details.
Oops, I have not noted this case. I really would like to know the rational behind this choice, since I find it very weird.
Have a look at the file "/usr/lib/tmpfiles.d/tmp.conf". I think that you get what you want if you comment out the two lines starting with an "X". But then I have to take care of it on each update of systemd.
So, the question now is: how can I remove directories older than 3 days? Or, in general, how can I override an "X" in a system provided file?
Andrea, The man page of tmpfiles.d states that files in /etc/tmpfiles.d have precedence over files in /usr/lib/tmpfiles.d. So, it should be sufficient to copy file /usr/lib/tmpfiles.d/tmp.conf to /etc/tmpfiles.d/tmp.conf and edit the copy. Please, read that man page. Erwin -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Sun, 12 May 2013 11:01:00 +0200 Andrea Turrini <andrea.turrini@gmail.com> пишет:
On 05/12/2013 10:37 AM, ErwinL wrote:
What you want to do doesn't work because the "Age" parameter is ignored with the "R" option. See "man tmpfiles.d" for details.
Oops, I have not noted this case. I really would like to know the rational behind this choice, since I find it very weird.
Do you have use case for it? "Very weird" is very weak argument.
Or, in general, how can I override an "X" in a system provided file?
Copy file under /etc/tmpfiles.d and edit it. This is also documented in man tmpfiles.d -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/12/2013 11:28 AM, Andrey Borzenkov wrote:
В Sun, 12 May 2013 11:01:00 +0200 Andrea Turrini <andrea.turrini@gmail.com> пишет:
On 05/12/2013 10:37 AM, ErwinL wrote:
What you want to do doesn't work because the "Age" parameter is ignored with the "R" option. See "man tmpfiles.d" for details.
Oops, I have not noted this case. I really would like to know the rational behind this choice, since I find it very weird.
Do you have use case for it? "Very weird" is very weak argument.
This topic is the use case: how can I remove specific directories inside /tmp after 3 days while keeping the 10 days /tmp general cleaning? BTW, if I change date to test the effect of copying and adapting tmp.conf, I note the following: Via bios, I have advanced the hardware clock of 1 month, so I performed the test on Jun 12. After the boot, /tmp still contained files created on May. For instance: -rw------- 1 ori users 8350 May 12 12:01 clementine-art-Qq1103.jpg -rw------- 1 ori users 8350 May 10 23:15 clementine-art-Rd1185.jpg -rw------- 1 ori users 2897 May 11 23:52 clementine-art-rS1130.jpg -rw------- 1 ori users 2897 Jun 12 12:18 clementine-art-SO1125.jpg or srwxr-xr-x 1 ori users 0 Jun 12 12:09 qtsingleapp-homeor-67d0-3e8= -rw-r--r-- 1 ori users 0 May 2 12:31 qtsingleapp-homeor-67d0-3e8-lockfile -rw-r--r-- 1 ori users 0 May 2 20:50 qtsingleapp-smplay-ca73-3e8-lockfile How can this be possible? The only possibility is that the cleanup is not executed at boot, but eventually during the uptime (for sure not within 10 minutes from the boot, the time I waited before rebooting and changing bios time). But this leads to: is it safe to remove /tmp/systemd-private-* via R /tmp/systemd-private-* or may this lead to problems? Moreover, the current status is: ori@orodruin:~> cat /etc/tmpfiles.d/tmp.conf # Clear tmp directories separately, to make them easier to override d /tmp 1777 root root 2d d /var/tmp 1777 root root 30d so, how is it possible that /tmp still contains the empty directory: drwx------ 2 ori users 4096 Apr 28 08:47 gpg-sKcjuY/
Or, in general, how can I override an "X" in a system provided file?
Copy file under /etc/tmpfiles.d and edit it. This is also documented in man tmpfiles.d
But the manpage does not document my other question, that you have removed from your quote. Moreover, can someone explain me the rationale of the following construction: d /tmp 1777 root root 2d where, by the manpage, d: Create a directory if it doesn't exist yet D: Create or empty a directory So, by using d, one is allowed to expect that the directory is created if missing, and nothing is done if the directory is already there. Otherwise, what is the difference between d and D? Then there is the Age field: The date field, when set, is used to decide what files to delete when cleaning. If a file or directory is older than the current time minus the age field it is deleted. So, how can this be related to a d, that just creates a directory if not existing? Since the age has meaning, as written, for cleaning operation, I would expect this to be related to an r or R operation (and to some extend also D), not to a d. You may point to: "The age field only applies to lines starting with d, D and x. If omitted or set to - no automatic clean-up is done." but still how can you infer that files are removed when you use a d? If original file uses a D, I would agree that this makes sense, since D empties the directory, if existing, so an age may have the following meaning: Create a directory or empty it (limited to content older than age). Now I try to use the following orodruin:~ # cat /etc/tmpfiles.d/tmp.conf # Clear tmp directories separately, to make them easier to override d /tmp 1777 root root 10d d /var/tmp 1777 root root 30d x /tmp/systemd-private-* - - - 2d x /var/tmp/systemd-private-* - - - 2d and see whether I obtain the wanted behavior. Best, Andrea -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrea Turrini said the following on 05/12/2013 08:19 AM:
This topic is the use case: how can I remove specific directories inside /tmp after 3 days while keeping the 10 days /tmp general cleaning?
Stated like that it is inadequate. * Three days after what? * Why? Are they taking up needed space? * What if they are still in use or still needed by some active process or process that will become active periodically? -- The problem with comforting illusions is that someone else ends up footing the bill for your comfort. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/12/2013 03:06 PM, Anton Aylward wrote:
Andrea Turrini said the following on 05/12/2013 08:19 AM:
This topic is the use case: how can I remove specific directories inside /tmp after 3 days while keeping the 10 days /tmp general cleaning?
Stated like that it is inadequate.
* Three days after what?
After the creation time, or whatever is used for comparing with the age.
* Why? Are they taking up needed space?
They are filling /tmp thus making more difficult to visually look for files in /tmp. And I do not see why if they are not taking up needed space, then this should not be a problem. Are you saying that since they do not take up needed space, then it is OK to let them to fill [/var]/tmp without bounds?
* What if they are still in use or still needed by some active process or process that will become active periodically?
If I know this can not happen, then this is not a problem. If I am not sure, I can change the age or keep the dirs there. BTW, this argument affects also the current system provided files wrt content (if any) of such directories: since X /tmp/systemd-private-* and from the manpage: X: Ignore a path during cleanup. Use this type to prevent path removal as controlled with the Age parameter. Note that if path is a directory, content of a directory is not excluded from clean-up, only directory itself. Lines of this type accept shell-style globs in place of normal path names. Can you ensure that everything is OK if the content is still in use or still needed by some active process or process that will become active periodically? Best, Andrea -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrea Turrini said the following on 05/12/2013 09:42 AM:
On 05/12/2013 03:06 PM, Anton Aylward wrote:
Andrea Turrini said the following on 05/12/2013 08:19 AM:
This topic is the use case: how can I remove specific directories inside /tmp after 3 days while keeping the 10 days /tmp general cleaning?
Stated like that it is inadequate.
* Three days after what?
After the creation time, or whatever is used for comparing with the age.
DANGER WILL ROBINSON! DANGER! Go though the rest of the file system and look at directories that were CREATED many days ago that contain newly created files or at least files that were created long after the directories or the parent directory of those directories were.
* Why? Are they taking up needed space?
They are filling /tmp thus making more difficult to visually look for files in /tmp. And I do not see why if they are not taking up needed space, then this should not be a problem. Are you saying that since they do not take up needed space, then it is OK to let them to fill [/var]/tmp without bounds?
First, what's this 'without bounds'? Second, are they really taking up space? Try running 'df' and see if your /tmp is critical. it sounds like this is an aesthetic argument, which is really unanswerable. I see other 'junk' created in my /tmp from things like ssh, adobe, various caches, ssh and gpg, plugins to thunderbird, PPD files from CUPS (LOTS! of them!), email attachment files I've viewed, and more. All these are more significant than empty directories. As for the aesthetics - what are you looking for in /tmp? Because if that is the real issue then THAT is the core of the "use case", not deletion. Well, what about /var/spool/postfix? Under ./defer and ./deferred there are many directories and hopefully they are empty. Are you going to add those to your list of directories to delete? Why not? Oh, right, its not an aesthetic issue.
* What if they are still in use or still needed by some active process or process that will become active periodically?
If I know this can not happen, then this is not a problem. If I am not sure, I can change the age or keep the dirs there.
I wouldn't fiddle with the age of system created directories if I were you. There's an IF here that remains unfulfilled.
BTW, this argument affects also the current system provided files wrt content (if any) of such directories: since
X /tmp/systemd-private-*
and from the manpage: X: Ignore a path during cleanup. Use this type to prevent path removal as controlled with the Age parameter. Note that if path is a directory, content of a directory is not excluded from clean-up, only directory itself. Lines of this type accept shell-style globs in place of normal path names.
That seems good advice and translates, in my mind, to 'leave it alone. The 'contents' might take up space or belong to aged/dead processes and they will be cleaned up.
Can you ensure that everything is OK if the content is still in use or still needed by some active process or process that will become active periodically?
*I* can't guarantee anything about *YOUR* system. Personally I think you're making a big issue of something that is going to go away anyway. -- Quality is not an act - it is a habit. - Aristotle -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sunday 12 May 2013, Anton Aylward wrote:
Andrea Turrini said the following on 05/12/2013 09:42 AM:
On 05/12/2013 03:06 PM, Anton Aylward wrote:
Andrea Turrini said the following on 05/12/2013 08:19 AM:
This topic is the use case: how can I remove specific directories inside /tmp after 3 days while keeping the 10 days /tmp general cleaning?
Stated like that it is inadequate.
* Three days after what?
After the creation time, or whatever is used for comparing with the age.
DANGER WILL ROBINSON! DANGER!
Go though the rest of the file system and look at directories that were CREATED many days ago that contain newly created files or at least files that were created long after the directories or the parent directory of those directories were.
We were talking about empty directories, right? Empty directories do not contain newly created files. BTW I'm sure that even systemd is smart enogugh to delete old files first, And then directories only if they are too old AND EMPTY.
* Why? Are they taking up needed space?
They are filling /tmp thus making more difficult to visually look for files in /tmp. And I do not see why if they are not taking up needed space, then this should not be a problem. Are you saying that since they do not take up needed space, then it is OK to let them to fill [/var]/tmp without bounds?
First, what's this 'without bounds'?
Second, are they really taking up space? Try running 'df' and see if your /tmp is critical.
it sounds like this is an aesthetic argument, which is really unanswerable.
If space would be the ONLY reason to delete anything then we should clean up dependent on disk usage instead of times only. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/12/2013 04:34 PM, Anton Aylward wrote:
Go though the rest of the file system and look at directories that were CREATED many days ago that contain newly created files or at least files that were created long after the directories or the parent directory of those directories were.
Why should I check the content of directories that are not supposed to be in a directory that is cleaned automatically?
* Why? Are they taking up needed space?
They are filling /tmp thus making more difficult to visually look for files in /tmp. And I do not see why if they are not taking up needed space, then this should not be a problem. Are you saying that since they do not take up needed space, then it is OK to let them to fill [/var]/tmp without bounds?
First, what's this 'without bounds'?
Each boot/service start adds a new directory and currently there is no bound on the number of newly created directories, except for the number and size of files that the file system is able to contain.
Second, are they really taking up space? Try running 'df' and see if your /tmp is critical.
Each directory uses at least 4k, so they are taking space.
it sounds like this is an aesthetic argument, which is really unanswerable.
I see other 'junk' created in my /tmp from things like ssh, adobe, various caches, ssh and gpg, plugins to thunderbird, PPD files from CUPS (LOTS! of them!), email attachment files I've viewed, and more. All these are more significant than empty directories.
But they are removed automatically after 10 days.
Well, what about /var/spool/postfix? Under ./defer and ./deferred there are many directories and hopefully they are empty. Are you going to add those to your list of directories to delete? Why not? Oh, right, its not an aesthetic issue.
Is /var/spool/postfix expected to be cleaned automatically? No Are /tmp/systemd-private-* expected to be cleaned automatically? Yes, since /tmp was expected by upstream to be a tmpfs.
I wouldn't fiddle with the age of system created directories if I were you.
These directories are created by systemd when a service with PrivateTmp set to true is started. After a reboot, for sure a new one is created. Thus old directories are no more used by any process, hence it is safe to remove them.
Personally I think you're making a big issue of something that is going to go away anyway.
Ah, just wait and then no one is allowed to complain. Best, Andrea -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrea Turrini said the following on 05/12/2013 11:13 AM:
Second, are they really taking up space? Try running 'df' and see if your /tmp is critical.
Each directory uses at least 4k, so they are taking space.
Geez! The litter I have from printing a file is about 10 times that!
it sounds like this is an aesthetic argument, which is really unanswerable.
I see other 'junk' created in my /tmp from things like ssh, adobe, various caches, ssh and gpg, plugins to thunderbird, PPD files from CUPS (LOTS! of them!), email attachment files I've viewed, and more. All these are more significant than empty directories.
But they are removed automatically after 10 days.
And in about 10 days you're going to get an update to systemd. Hopefully. Depending on how conservative the packagers are. Lets see: we're on 195 now. That was ... [systemd-devel] [ANNOUNCE] systemd 195 Lennart Poettering lennart at poettering.net Mon Oct 22 17:56:14 PDT 2012 Oct Nov Dec Jan Feb Mar Apr so reckon on openSuse conservative stance introducing a lag of 4-6 months. Sorry, that make it more than 10 days ....
Well, what about /var/spool/postfix? Under ./defer and ./deferred there are many directories and hopefully they are empty. Are you going to add those to your list of directories to delete? Why not? Oh, right, its not an aesthetic issue.
Is /var/spool/postfix expected to be cleaned automatically? No
Yes, but you have 10 such empty directories (each taking up at least 4k, maybe more) in at least 2, maybe more, directories, on the same file system as /var/tmp! The issue isn't about whether its expected to be cleaned automatically or not. its that its there and that its taking up space. So we get back to the aesthetics issue ...
Are /tmp/systemd-private-* expected to be cleaned automatically? Yes, since /tmp was expected by upstream to be a tmpfs.
And you are quite capable of running systemctl mask to restore that. Once again openSuse is being conservative by having the default behave the old way, /tmp being on disk, rather than the 'new' way of making it a tmpfs. You want the latest, the most bleeding edge, then don't use openSuse. Either that or make use of the build service and build your own.
Personally I think you're making a big issue of something that is going to go away anyway.
Ah, just wait and then no one is allowed to complain.
Complain about a real issue then, like "opensuse is too conservative and isn't moving upstream changes into the updates fast enough for me". Because that's the real issue here. See http://lists.freedesktop.org/archives/systemd-devel/2013-March/009933.html Note the date on that - MARCH 26th. <quote> CHANGES WITH 199: * [...] * Behaviour of PrivateTmp=, ReadWriteDirectories=, ReadOnlyDirectories= and InaccessibleDirectories= has changed. The private /tmp and /var/tmp directories are now shared by all processes of a service (which means ExecStartPre= may now leave data in /tmp that ExecStart= of the same service can still access). When a service is stopped its temporary directories are immediately deleted (normal clean-up with tmpfiles is still done in addition to this though). </quote> Note that - "When a service is stopped its temporary directories are immediately deleted" So complain, yes, but complain about the right thing, which is that openSuse is too conservative for YOUR tastes. Oh, and BTW - there's the list to subscribe to :-) What puzzles me is this. All that 'research' took just a few tries at googling. The cut-and-paste took longer. How come no-one else looked that up? Its not as if there's any PhD level smarts involved in me doing a google search. Now let me ask another question. Has anyone used the build service to build a v199 of systemd? If the answer to that is "yes" then Andrea can add that repository and update systemd and LO! the problem is fixed. -- I suspect that, over time, all bureaucratic processes decay into cargo cults unless regularly challenged by a hostile reality. - Alan Rocker, 23-Nov-2011 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/12/2013 06:19 PM, Anton Aylward wrote:
Andrea Turrini said the following on 05/12/2013 11:13 AM:
Second, are they really taking up space? Try running 'df' and see if your /tmp is critical.
Each directory uses at least 4k, so they are taking space.
Geez! The litter I have from printing a file is about 10 times that!
You asked whether such directories are taking space. And they do. Few space, but they do. Period.
And in about 10 days you're going to get an update to systemd. Hopefully. Depending on how conservative the packagers are.
I do not think. Why do you still have systemd-44 in your oS 12.2? It should be 195, according to your approach.
Lets see: we're on 195 now. That was ... [systemd-devel] [ANNOUNCE] systemd 195 Lennart Poettering lennart at poettering.net Mon Oct 22 17:56:14 PDT 2012
Oct Nov Dec Jan Feb Mar Apr
so reckon on openSuse conservative stance introducing a lag of 4-6 months.
Sorry, that make it more than 10 days ....
Not related argument.
Is /var/spool/postfix expected to be cleaned automatically? No
Yes, but you have 10 such empty directories (each taking up at least 4k, maybe more) in at least 2, maybe more, directories, on the same file system as /var/tmp!
Not related argument.
The issue isn't about whether its expected to be cleaned automatically or not. its that its there and that its taking up space.
So we get back to the aesthetics issue ...
Wrong. The problem is about whether such directories are expected to be cleaned automatically. And they are, since the relative bug [0] has been fixed upstream by removing such directories when no more needed; it is your argument about taking up space.
And you are quite capable of running systemctl mask to restore that.
No, because it is a bug of systemd-195, only hidden by having /tmp mounted as tmpfs. It is just a workaround that may affect overall system behavior.
Once again openSuse is being conservative by having the default behave the old way, /tmp being on disk, rather than the 'new' way of making it a tmpfs. You want the latest, the most bleeding edge, then don't use openSuse. Either that or make use of the build service and build your own.
I wonder from where you derived that I want the latest, the most bleeding edge. For sure this is not my case. I do not want the latest, the most bleeding. Otherwise I would use factory or at least tumbleweed, but I am using an ordinary oS 12.3 as base system. I use non-official updates only for stuff that does not affect the core functionality of the system and that can be easily rolled back. JFYI, I installed oS 12.3 only Apr. 21, while it was released on Mar. 13, so more than 1 month after the release.
So complain, yes, but complain about the right thing, which is that openSuse is too conservative for YOUR tastes.
Again, I do not want bleeding edge things, so openSUSE is *NOT* too conservative for my tastes.
Has anyone used the build service to build a v199 of systemd? If the answer to that is "yes" then Andrea can add that repository and update systemd and LO! the problem is fixed.
No, I will not install a non-official update for a core element as systemd, with the risk of being forced to use a rescue system to fix it. Best, Andrea [0] https://bugzilla.redhat.com/show_bug.cgi?id=801943 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrea Turrini said the following on 05/12/2013 01:29 PM:
Depending on how conservative the packagers are. I do not think. Why do you still have systemd-44 in your oS 12.2? It should be 195, according to your approach.
I don't follow your logic; The 12.2 system updates from the 12.2 repositories and the 12.3 updates from the 12.3 repositories. Why should the 12.2 update from the 12.3 repository? Again ... # zypper info systemd Information for package systemd: Repository: openSUSE-12.2-Update Name: systemd Version: 44-10.8.1 Arch: i586 Vendor: openSUSE Installed: Yes Status: up-to-date See: a 12.2 repository and it is up to date. 12.2 is not 12.3 I can't see how it should be 195 - that the most recent in the 12.3 update. Update repositories of 12.2 doesn't mean "update to 12.3". -- "The man who does not read good books has no advantage over the man who can't read them." --Mark Twain -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrea Turrini wrote:
Again, I do not want bleeding edge things, so openSUSE is *NOT* too conservative for my tastes.
Doesn't your system still run cron? Something seems to be updating my /var/spool/cron/lastrun/FILES with correct timestamps. Seems like my tmp files are being removed in line with parameters set in /etc/sysconfig/cron... Is yours disabled? Maybe having cron do the task isn't the worst idea? You wouldn't have to load any untested SW... ;-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrea Turrini said the following on 05/12/2013 01:29 PM:
On 05/12/2013 06:19 PM, Anton Aylward wrote:
Andrea Turrini said the following on 05/12/2013 11:13 AM:
Second, are they really taking up space? Try running 'df' and see if your /tmp is critical.
Each directory uses at least 4k, so they are taking space.
Geez! The litter I have from printing a file is about 10 times that!
You asked whether such directories are taking space. And they do. Few space, but they do. Period.
Compared to the transient things in /tmp and /var/tmp and the empty directories elsewhere in /var these are insignificant. I think you have your priorities very, very confused.
Is /var/spool/postfix expected to be cleaned automatically? No
Yes, but you have 10 such empty directories (each taking up at least 4k, maybe more) in at least 2, maybe more, directories, on the same file system as /var/tmp!
Not related argument.
... because its not about space, is it, its about aesthetics.
The issue isn't about whether its expected to be cleaned automatically or not. its that its there and that its taking up space.
So we get back to the aesthetics issue ...
Wrong. The problem is about whether such directories are expected to be cleaned automatically. And they are, since the relative bug [0] has been fixed upstream by removing such directories when no more needed; it is your argument about taking up space.
You want to have it both ways then. So install the fix that Cristian pointed out to you.
And you are quite capable of running systemctl mask to restore that.
No, because it is a bug of systemd-195, only hidden by having /tmp mounted as tmpfs. It is just a workaround that may affect overall system behavior.
You really really really do want it both ways.
Once again openSuse is being conservative by having the default behave the old way, /tmp being on disk, rather than the 'new' way of making it a tmpfs. You want the latest, the most bleeding edge, then don't use openSuse. Either that or make use of the build service and build your own.
I wonder from where you derived that I want the latest, the most bleeding edge. For sure this is not my case.
Let me get this right: you're saying you want it fixed but you don't actually want to make the changes that will fix it. OBTW: since that capability wasn't in the v44 on my 12.2 system I don't have that aesthetic problem with them littering /tmp on 12.2 box. So if you don't want the latest - which is 12.3, then there's a solution for you. Or do you want it both ways still?
I do not want the latest, the most bleeding. Otherwise I would use factory or at least tumbleweed, but I am using an ordinary oS 12.3 as base system. I use non-official updates only for stuff that does not affect the core functionality of the system and that can be easily rolled back.
Which is the case for both the solutions that Cristian has proposed.
JFYI, I installed oS 12.3 only Apr. 21, while it was released on Mar. 13, so more than 1 month after the release.
Your point being? If you are doing the updates with zypper or yast, to keep up to date then it doesn't matter if you installed it on March 15 or May 10th. A "zypper up" updates to whatever is in the current update repository. For 12.3 that is Repository: openSUSE-12.3-Update Name: systemd Version: 195-13.25.1 Arch: i586 Vendor: openSUSE Installed: Yes Status: up-to-date Or are you telling us that you don't do an update with zypper or yast?
So complain, yes, but complain about the right thing, which is that openSuse is too conservative for YOUR tastes.
Again, I do not want bleeding edge things, so openSUSE is *NOT* too conservative for my tastes.
You really really really really do want it both ways. You want it fixed but aren't willing to update to the 'edge' where it *IS* fixed.
Has anyone used the build service to build a v199 of systemd? If the answer to that is "yes" then Andrea can add that repository and update systemd and LO! the problem is fixed.
No, I will not install a non-official update for a core element as systemd, with the risk of being forced to use a rescue system to fix it.
Oh right; and all of openSuse is not SLED so its not official, its all done by volunteers ... -- "Amberley excelled at chess -- one mark, Watson, of a scheming mind." -- Sherlock Holmes, in "The Adventure of the Retired Colourman" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/12/2013 08:01 PM, Anton Aylward wrote:
Compared to the transient things in /tmp and /var/tmp and the empty directories elsewhere in /var these are insignificant.
I think you have your priorities very, very confused.
They may be confused, but they are not the topic of this discussion where still I have not seen an answer to my initial question: How do I remove only directories older than 3 days (while keeping the usual 10 days /tmp cleaning)? I will no more follow you in discussions not related to this question. Best, Andrea -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrea Turrini said the following on 05/12/2013 02:37 PM:
How do I remove only directories older than 3 days (while keeping the usual 10 days /tmp cleaning)?
Easy. Forget all that fiddling with the config you have been doing and implement either one of the changes Cristian has suggested. -- For the time will come when men will not put up with sound doctrine. Instead, to suit their own desires, they will gather around them a great number of teachers to say what their itching ears want to hear. - II Timothy 4:3 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Sun, 12 May 2013 17:13:48 +0200 Andrea Turrini <andrea.turrini@gmail.com> пишет:
Each boot/service start adds a new directory
That simply not true. You are making storm in a teacup. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 12/05/13 14:01, Andrey Borzenkov escribió:
В Sun, 12 May 2013 17:13:48 +0200 Andrea Turrini <andrea.turrini@gmail.com> пишет:
Each boot/service start adds a new directory
That simply not true.
You are making storm in a teacup.
In my machine TWO of the default services use PrivateTmp, so indeed, it is not that each boot/service adds a new directory. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2013-05-12 at 17:13 +0200, Andrea Turrini wrote:
These directories are created by systemd when a service with PrivateTmp set to true is started. After a reboot, for sure a new one is created. Thus old directories are no more used by any process, hence it is safe to remove them.
You can delete them on boot automatically on boot. This works in 12.3, I'm using it on my test system: eleanor3:~ # cat /etc/tmpfiles.d/remove-systemd-private.conf R /tmp/systemd-private-* R /var/tmp/systemd-private-* eleanor3:~ # - -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlGQSYUACgkQtTMYHG2NR9XOAgCfUSvPuuDP76nMExbBEMJNO6TL xz4AnjdMCyXfoj3KntV39XOvwmOjo361 =z6gx -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2013-05-12 at 09:06 -0400, Anton Aylward wrote:
* What if they are still in use or still needed by some active process or process that will become active periodically?
Well, as it is systemd who creates and deletes those directories, it also knows if they are in use and can be deleted or not :-) - -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlGQQ7EACgkQtTMYHG2NR9WrJgCeJl01Sj2i6W6HPRudRlnKBEPD XTYAnjwlGAPJ6KRhmq9g+Uzn/MpuHxwV =0rBm -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. said the following on 05/12/2013 09:36 PM:
On Sunday, 2013-05-12 at 09:06 -0400, Anton Aylward wrote:
* What if they are still in use or still needed by some active process or process that will become active periodically?
Well, as it is systemd who creates and deletes those directories, it also knows if they are in use and can be deleted or not :-)
Indeed. And that's what it says in the release notes that I refereed to in other email. -- People who love sausages, respect the law, and work with IT standards shouldn't watch any of them being made. -- Peter Gutmann -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Sun, 12 May 2013 09:17:09 +0200 Andrea Turrini <andrea.turrini@gmail.com> пишет:
Hi all, in order to remove [/var]/tmp/systemd-private-* directories that for sure are no more used, I followed Andrey's suggestion [0] and I have created the file
ori@orodruin:~> cat /etc/tmpfiles.d/remove-systemd-private.conf R /tmp/systemd-private-* - - - 3d R /var/tmp/systemd-private-* - - - 3d
but as you can see, I would remove directories that are at least 3 days old.
The problem is that all [/var]/tmp/systemd-private-* are removed except for the one created in the current boot.
That's correct. R causes file (directory) to be removed on boot.
I have also tried
R /tmp/systemd-private-* 3d R /var/tmp/systemd-private-* 3d
This is invalid syntax in the first place. I'd expect systemd-tmpfiles to ignore it, but OK, it is cosmetic bug.
but with the same result.
So, the question is: how do I remove only directories older than 3 days?
Copy /usr/lib/tmpfiles.d/tmp.conf into /etc/tmpfiles.d under the same name, remove (comment out) lines starting with X, and adjust cleanup period for /tmp (/var/tmp). But that's IMHO bad idea. The content of those directories is cleaned up following normal rules for /tmp. And directories themselves should remain as long as service is active. I do not think you restart services that define private tmp dirs so often that it becomes a problem.
Or is this a bug?
Behavior that you describe is not a bug. What is not possible indeed, is to set "inactivity period" for individual files or directories, so that file /tmp/foo is removed after a week and /tmp/bar - after a month. You have per-directory (e.g. /tmp) setting. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrea Turrini said the following on 05/12/2013 03:17 AM:
So, the question is: how do I remove only directories older than 3 days? Or is this a bug?
I'm not sure this is a good idea. First, the "R" for remove on boot is as Andrey points out a better idea since a machine might be up for 3 days or more (even if your normal strategy is daily boot). Second, this is really all a non issue. As Cristian points out, systemd is a work in progress and this is an artefact of one revision and will go away with the next release from upstream. One reason I also run Fedora is "to see what's coming..." If this is the only Linux list you subscribe to then you're going to have a very limited view of what's going on. -- “In politics as in religion, my tenets are few and simple. The leading one of which, and indeed that which embraces most others, is to be honest and just ourselves and to exact it from others, meddling as little as possible in their affairs where our own are not involved. If this maxim was generally adopted, wars would cease and our swords would soon be converted into reap hooks and our harvests be more peaceful, abundant, and happy.” ― George Washington -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/12/2013 01:31 PM, Anton Aylward wrote:
Andrea Turrini said the following on 05/12/2013 03:17 AM:
So, the question is: how do I remove only directories older than 3 days? Or is this a bug?
I'm not sure this is a good idea.
First, the "R" for remove on boot is as Andrey points out a better idea since a machine might be up for 3 days or more (even if your normal strategy is daily boot).
See my other email: can you ensure that the cleaning is performed at boot? There are behaviors that seem to show that this is not the case.
Second, this is really all a non issue. As Cristian points out, systemd is a work in progress and this is an artefact of one revision and will go away with the next release from upstream.
And will this next release land in oS 12.3 as official update? Can you ensure this?
One reason I also run Fedora is "to see what's coming..."
If this is the only Linux list you subscribe to then you're going to have a very limited view of what's going on.
I have a view of what is going on relative to what I use, openSUSE, not Fedora. Or should one be subscribed to every distribution/upstream project to see what is going on? Best, Andrea -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrea Turrini said the following on 05/12/2013 08:25 AM:
On 05/12/2013 01:31 PM, Anton Aylward wrote:
Andrea Turrini said the following on 05/12/2013 03:17 AM:
So, the question is: how do I remove only directories older than 3 days? Or is this a bug?
I'm not sure this is a good idea.
Second, this is really all a non issue. As Cristian points out, systemd is a work in progress and this is an artefact of one revision and will go away with the next release from upstream.
And will this next release land in oS 12.3 as official update? Can you ensure this?
I'm unclear what you're asking. I'm running 13.2 and 12.3; my Fedora disks aren't plugged in right this moment so I can't give you the lowdown there. One 12.2 I have (according to zypper info) Repository: openSUSE-12.2-Update Name: systemd Version: 44-10.8.1 Arch: i586 Vendor: openSUSE Installed: Yes Status: up-to-date and on 12.3 Repository: openSUSE-12.3-Update Name: systemd Version: 195-13.25.1 Arch: i586 Vendor: openSUSE Installed: Yes Status: up-to-date WOW! What a difference! And please note that I ma using the update repositories. Perhaps Cristian can tell up more about what's going on 'upstream',
One reason I also run Fedora is "to see what's coming..."
If this is the only Linux list you subscribe to then you're going to have a very limited view of what's going on.
I have a view of what is going on relative to what I use, openSUSE, not Fedora. Or should one be subscribed to every distribution/upstream project to see what is going on?
You can if you want; some people do. There are projects such as systemd which are moving along rapidly, and it was clear from the outset that these directories in /tmp came from systemd. I'm not saying monitor everything everywhere, but its pretty normal for people to take an interest in the areas of their hobbies or things that impact them, be it cameras, dog/cat breeding, cars, RC model planes. This is a very general list for Suse; there are specific ones for things like the kernel and other areas of development; specific ones like factory, kde, gnome ... See https://en.opensuse.org/openSUSE:Mailing_lists There are also specific thread out there about systemd - go google. -- Skill without imagination is craftsmanship and gives us many useful objects such as wickerwork picnic baskets. Imagination without skill gives us modern art. -- Tom Stoppard -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/12/2013 03:02 PM, Anton Aylward wrote:
Andrea Turrini said the following on 05/12/2013 08:25 AM:
And will this next release land in oS 12.3 as official update? Can you ensure this?
I'm unclear what you're asking.
It is simple: will there be an official update (i.e., a package in openSUSE-12.3-Update repository) for systemd that prevents/solves the current status, i.e., the creation without removal of these [/var]/tmp/systemd-private-* directories? Or in other words, if this problem has been solved by systemd-N with N strictly greater than 195, will systemd-195 be replaced by systemd-N via an official update or will changes in systemd-N be backported to systemd-195 via an official update? My impression is that the current status will stand until oS 12.3 goes out of support, and then no one will care about the problem.
One 12.2 I have (according to zypper info)
Repository: openSUSE-12.2-Update Name: systemd Version: 44-10.8.1 Arch: i586 Vendor: openSUSE Installed: Yes Status: up-to-date
and on 12.3
Repository: openSUSE-12.3-Update Name: systemd Version: 195-13.25.1 Arch: i586 Vendor: openSUSE Installed: Yes Status: up-to-date
WOW! What a difference!
So? they are just numbers; nothing prevents the version to be increased by 1 just for fixing a typo.
And please note that I ma using the update repositories.
Me too, but I just see: ori@orodruin:~> zypper se -s --match-exact systemd Verbosity: 2 Non-option program arguments: 'systemd' Initializing Target Loading repository data... Reading installed packages... Force resolution: No S | Name | Type | Version | Arch | Repository --+---------+------------+-------------+--------+--------------------- i | systemd | package | 195-13.25.1 | x86_64 | openSUSE-12.3-Update v | systemd | package | 195-13.18.1 | x86_64 | openSUSE-12.3-Update v | systemd | package | 195-13.14.1 | x86_64 | openSUSE-12.3-Update v | systemd | package | 195-13.11.1 | x86_64 | openSUSE-12.3-Oss v | systemd | package | 195-13.25.1 | i586 | openSUSE-12.3-Update v | systemd | package | 195-13.18.1 | i586 | openSUSE-12.3-Update v | systemd | package | 195-13.14.1 | i586 | openSUSE-12.3-Update v | systemd | package | 195-13.11.1 | i586 | openSUSE-12.3-Oss | systemd | srcpackage | 195-13.25.1 | noarch | openSUSE-12.3-Update | systemd | srcpackage | 195-13.18.1 | noarch | openSUSE-12.3-Update | systemd | srcpackage | 195-13.14.1 | noarch | openSUSE-12.3-Update
Perhaps Cristian can tell up more about what's going on 'upstream',
Why should I care about upstream if problems are downstream? If I would report this problem upstream, probably it will be closed as INVALID since it seems that they have already fixed it in a later version, or because downstream is using a different setup not supported by upstream ([/var]/tmp on disk instead of on RAM), but such version will not be made available officially for oS 12.3.
This is a very general list for Suse; there are specific ones for things like the kernel and other areas of development; specific ones like factory, kde, gnome ... See https://en.opensuse.org/openSUSE:Mailing_lists
Currently I am subscribed to this, factory, translation, kde, project, and possibly some other. Since I do not see an opensuse-systemd list, and we are talking about oS 12.3 and not factory, opensuse is the only list that is OK for this discussion (except for opensuse-offtopic, but this is not an offtopic). Or am I missing the correct list? Best, Andrea -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrea Turrini said the following on 05/12/2013 10:20 AM:
Since I do not see an opensuse-systemd list, and we are talking about oS 12.3 and not factory, opensuse is the only list that is OK for this discussion (except for opensuse-offtopic, but this is not an offtopic). Or am I missing the correct list?
Dunno. I just googled for "systemd mailing list" but then I'm one of those people whose first recourse to almost eveything is to google for it. -- I'm always interested when [cold callers] try to flog conservatories. Anyone who can actually attach a conservatory to a fourth floor flat stands a marginally better than average chance of winning my custom. (Seen on Usenet) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/12/2013 04:58 PM, Anton Aylward wrote:
Andrea Turrini said the following on 05/12/2013 10:20 AM:
Since I do not see an opensuse-systemd list, and we are talking about oS 12.3 and not factory, opensuse is the only list that is OK for this discussion (except for opensuse-offtopic, but this is not an offtopic). Or am I missing the correct list?
Dunno.
I just googled for "systemd mailing list" but then I'm one of those people whose first recourse to almost eveything is to google for it.
And? If I open a topic similar to this one in one of these ml, I already know the answer I receive: This is not a list for openSUSE problems, ask in openSUSE lists; or Upgrade to 199 or later [0]. Best, Andrea [0] http://lists.opensuse.org/opensuse/2013-05/msg00145.html -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrea Turrini said the following on 05/12/2013 10:20 AM:
On 05/12/2013 03:02 PM, Anton Aylward wrote:
Andrea Turrini said the following on 05/12/2013 08:25 AM:
And will this next release land in oS 12.3 as official update? Can you ensure this?
I'm unclear what you're asking. It is simple: will there be an official update (i.e., a package in openSUSE-12.3-Update repository) for systemd that prevents/solves the current status, i.e., the creation without removal of these [/var]/tmp/systemd-private-* directories?
Or in other words, if this problem has been solved by systemd-N with N strictly greater than 195, will systemd-195 be replaced by systemd-N via an official update or will changes in systemd-N be backported to systemd-195 via an official update?
My impression is that the current status will stand until oS 12.3 goes out of support, and then no one will care about the problem.
This isn't a 12.x issue, its a systemd issue. You're not waiting for 13.x, you're waiting for an update to systemd. I've deleted Cristian's post about the upstream fix to this issue, but its there in the archives: http://lists.opensuse.org/opensuse/2013-05/msg00140.html and http://lists.opensuse.org/opensuse/2013-05/msg00145.html So wait for v 199. You're only at 195 it seems. (Or pressure the developers to get a move on)
Why should I care about upstream if problems are downstream?
Because openSuse is a 'conservative' distribution. The developers/packages don't release to the updates as soon as a change occurs. They value stability. If you don't like this, they either you can use the build service to make your own (b)leeding edge versions (or simple customizations), but then you get into the Red Queens Race of having to keep doing that. Or you can use a more aggressive distribution such as Fedora and take the risk of instability. YMMV. Some of us have a number of boxes (or at least as many as I'm willing to pull out of the Closet of Anxieties and make work) so can run more that one distribution. Right now I have more drives than working boxes and the fedora drives are off-line. Oh and I think http://lists.opensuse.org/opensuse/2013-05/msg00300.html sounds like a better fix than fiddling with selective deletion.
but such version will not be made available officially for oS 12.3.
See msg00300 above. It strikes me that changing your system with a mask is simpler than all the special case fiddling with the other files that you've been discussion. -- withdrawl (n): The feeling you get when removed from people who speak your native language and placed in the Deep South. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 12/05/13 10:20, Andrea Turrini escribió:
It is simple: will there be an official update (i.e., a package in openSUSE-12.3-Update repository) for systemd that prevents/solves the current status, i.e., the creation without removal of these [/var]/tmp/systemd-private-* directories?
If you can make your case, in bugzilla on why we should fix a cosmetic problem (the directories take next to nothing of resources on the system)
Or in other words, if this problem has been solved by systemd-N with N strictly greater than 195, will systemd-195 be replaced by systemd-N via an official update or will changes in systemd-N be backported to systemd-195 via an official update?
My impression is that the current status will stand until oS 12.3 goes out of support, and then no one will care about the problem.
One 12.2 I have (according to zypper info)
Repository: openSUSE-12.2-Update Name: systemd Version: 44-10.8.1 Arch: i586 Vendor: openSUSE Installed: Yes Status: up-to-date
and on 12.3
Repository: openSUSE-12.3-Update Name: systemd Version: 195-13.25.1 Arch: i586 Vendor: openSUSE Installed: Yes Status: up-to-date
WOW! What a difference!
So? they are just numbers; nothing prevents the version to be increased by 1 just for fixing a typo.
THe version number increased after udev was merged into systemd, the udev version number took over the systemd one. The versions shipped are not randomly choosen, the are "distribution release points" (to give it a name) , where distributions can settle in. The next "distribution point" is systemd 204/205 (or whatever version is pre-kdbus [1]) after that a new bulk of invasive changes will take place, on which systemd will require new kernel releases/features. [1] https://github.com/gregkh/kdbus/blob/master/kdbus.txt -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 12/05/13 08:25, Andrea Turrini escribió:
On 05/12/2013 01:31 PM, Anton Aylward wrote:
Andrea Turrini said the following on 05/12/2013 03:17 AM:
So, the question is: how do I remove only directories older than 3 days? Or is this a bug?
I'm not sure this is a good idea.
First, the "R" for remove on boot is as Andrey points out a better idea since a machine might be up for 3 days or more (even if your normal strategy is daily boot).
See my other email: can you ensure that the cleaning is performed at boot? There are behaviors that seem to show that this is not the case.
Second, this is really all a non issue. As Cristian points out, systemd is a work in progress and this is an artefact of one revision and will go away with the next release from upstream.
And will this next release land in oS 12.3 as official update? Can you ensure this?
No, the next release will not land in as an openSUSE 12.3 update, however if you are *that* concerned about this really minor cosmetic problem, try: a) mounting tmp has tmpfs : mkdir -p /etc/systemd/system/local-fs.target.wants ln -s /usr/lib/systemd/system/tmp.mount /etc/systemd/system/local-fs.target.wants/tmp.mount OR b) zypper ar -f -r http://download.opensuse.org/repositories/home:/elvigia:/systemd/openSUSE_12... zypper dup --from home_elvigia_systemd WARNING, WARNING **MEGA EPIC WARNING** works for me in two different machines, however it is possible that it will not work for you, -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (8)
-
Andrea Turrini -
Andrey Borzenkov -
Anton Aylward -
Carlos E. R. -
Cristian Rodríguez -
ErwinL -
Linda Walsh -
Ruediger Meier