-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2013-05-05 at 08:42 -0400, Anton Aylward wrote:

Andrea Turrini said the following on 05/05/2013 08:06 AM:

...

Hi all,

after having installed oS 12.3 from scratch two weeks ago, I have found that /tmp contains a lot of systemd-private-* directories. Currently there are 85 of such directories but hopefully they are all empty, so they do not waste too much space.

Is it correct that such directories remain in /tmp? Why are they not removed by systemd on shutdown?

I can't imagine why they are there in the first place.

I have them too, I just looked. It is a fresh 12.3 system installed under vmware player.

Its not the job of systemd to purge /tmp. That's done by a cron job. We've discussed that issue here recently.

Of course it is the job of systemd! Any program creating temporary files should destroy them when they finish. Having a cronjob deleting them is a hack for careless programming.

Take a look at /etc/cron.daily/suse.de-clean-tmp and at /etc/sysconfig/cron

That is deprecated and does not work. It doesn't, because those files are owned by root. And it doesn't because if systemd is running the cron job does not work. See release notes: +++··································· 5.2. systemd: Cleaning Directories (/tmp and /var/tmp) By default, systemd cleans tmp directories daily as configured in /usr/lib/tmpfiles.d/tmp.conf. Users can change it by copying /usr/lib/tmpfiles.d/tmp.conf to /etc/tmpfiles.d/tmp.conf and modifying the copied file. It will override /usr/lib/tmpfiles.d/tmp.conf. Note: systemd does not honor obsolete sysconfig variables in /etc/sysconfig/cron such as TMP_DIRS_TO_CLEAR. ···································++- - -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlGGWKIACgkQtTMYHG2NR9WqTQCfYnvafSJmAfdcZG56IQrQ9WpY v/UAmwQDOpd6haPrdE36D9SQ8vbxB0pO =4Uv9 -----END PGP SIGNATURE-----

Carlos E. R. said the following on 05/05/2013 09:03 AM:

...

...

Take a look at /etc/cron.daily/suse.de-clean-tmp and at /etc/sysconfig/cron

That is deprecated and does not work. It doesn't, because those files are owned by root. And it doesn't because if systemd is running the cron job does not work. See release notes:

My Bad. Thank you for the correction. I looked on my 12.2 system rather than 12.3. I see that /etc/cron.daily/suse.de-clean-tmp isn't there on my 12.3 system. Sadly /etc/sysconfig/cron is. Hmm, that was a clean install on the 12.3 machine I'm looking at so I can't blame it on being a residue of an update. That still doesn't answer why they got created and left behind in the first place. You point out that programs _should_ clean up after themselves, but I've never relied on that. "Evidence". Systemd is "ongoing" and there still a lot to learn. -- Doubt is not a pleasant condition, but certainty is absurd. -- Voltaire -- 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-05 at 15:39 +0200, Marcus Meissner wrote:

No idea about how the clean up works there, if it does not, report a bug I would say :/

It will probably be ignored, or wontfixed, or invalid, or whatever, as those files are intentionally not erased: # Exclude namespace mountpoints created with PrivateTmp=yes X /tmp/systemd-private-* X /var/tmp/systemd-private-* - -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlGGZUsACgkQtTMYHG2NR9UIdgCglOzEjV8xd6JS1I6ujhqPzqw9 zA8An1suTE+frR5+iCedqXcxg/nJj5ND =IGnV -----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-05 at 16:11 +0200, Ruediger Meier wrote:

On Sunday 05 May 2013, Carlos E. R. wrote:

I assume they shall not be removed during uptime but at least on reboot. The fact that they are "still" there after reboot could be because they are simply re-created.

Nope, the dates do not match: eleanor3:~ # uptime 16:12 up 21:25, 6 users, load average: 0,00, 0,01, 0,05 eleanor3:~ # l /tmp/systemd-private-* /tmp/systemd-private-FawLUZ: total 8 drwxrwxrwt 2 root root 4096 May 1 04:32 ./ drwxrwxrwt 17 root root 4096 May 5 16:00 ../ /tmp/systemd-private-GLcQqj: total 8 drwxrwxrwt 2 root root 4096 May 1 03:30 ./ drwxrwxrwt 17 root root 4096 May 5 16:00 ../ /tmp/systemd-private-Wpa6pD: total 8 drwxrwxrwt 2 root root 4096 May 2 05:07 ./ drwxrwxrwt 17 root root 4096 May 5 16:00 ../ /tmp/systemd-private-h6yFZV: total 8 drwxrwxrwt 2 root root 4096 May 1 02:54 ./ drwxrwxrwt 17 root root 4096 May 5 16:00 ../ /tmp/systemd-private-jQoKLO: total 8 drwxrwxrwt 2 root root 4096 May 2 11:14 ./ drwxrwxrwt 17 root root 4096 May 5 16:00 ../ eleanor3:~ # They are directories older than my reboot, and they are random names. If they are recreated, they should get a new name and a different, current, date - which is what happens, and the old one remains. eleanor3:~ # lsof | grep systemd-private lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /var/run/user/1000/gvfs Output information may be incomplete. eleanor3:~ # - -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlGGalAACgkQtTMYHG2NR9VTsACdETv6tAPy+PB0P0ve4R6Mz4Ss f0EAoIiiqWyj+m473tqaRA4RMBU28fKM =19KQ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrea Turrini wrote:

As far I can say, they are not removed but still created on boot, but only a couple of directory for each boot. For example:

I just checked my computer and here's what I found: drwxrwxrwt 2 root root 4096 Apr 24 12:09 systemd-private-2gKZyv drwxrwxrwt 2 root root 4096 Apr 24 21:25 systemd-private-6MFjVn drwxrwxrwt 2 root root 4096 May 4 17:24 systemd-private-8zo3Eo drwxrwxrwt 2 root root 4096 Mar 17 14:59 systemd-private-bVGstg drwxrwxrwt 2 root root 4096 Apr 24 21:24 systemd-private-BXDnMv drwxrwxrwt 2 root root 4096 Mar 17 16:00 systemd-private-C237qO drwxrwxrwt 2 root root 4096 Mar 17 12:01 systemd-private-cEyZ05 drwxrwxrwt 2 root root 4096 Apr 24 11:01 systemd-private-dmmo9K drwxrwxrwt 2 root root 4096 Apr 24 21:27 systemd-private-EEnv1Z drwxrwxrwt 2 root root 4096 Apr 24 09:59 systemd-private-Ek4LCl drwxrwxrwt 2 root root 4096 Mar 17 15:09 systemd-private-Fc4HJs drwxrwxrwt 2 root root 4096 Apr 24 12:11 systemd-private-FtjArW drwxrwxrwt 2 root root 4096 Apr 23 22:14 systemd-private-HCIkny drwxrwxrwt 2 root root 4096 Apr 25 19:06 systemd-private-hosYEx drwxrwxrwt 2 root root 4096 Apr 24 10:00 systemd-private-JOJgHa drwxrwxrwt 2 root root 4096 Apr 24 12:09 systemd-private-jRJ340 drwxrwxrwt 2 root root 4096 Mar 17 22:17 systemd-private-JUoAXO drwxrwxrwt 2 root root 4096 Apr 17 22:16 systemd-private-mJKLM7 drwxrwxrwt 2 root root 4096 Apr 17 22:17 systemd-private-Myq6HP drwxrwxrwt 2 root root 4096 Mar 17 11:56 systemd-private-niTHSX drwxrwxrwt 2 root root 4096 Apr 24 11:00 systemd-private-Nw85Ea drwxrwxrwt 2 root root 4096 Apr 23 22:15 systemd-private-OQy485 drwxrwxrwt 2 root root 4096 May 4 17:41 systemd-private-OUeOXm drwxrwxrwt 2 root root 4096 Mar 17 22:16 systemd-private-OwbrW2 drwxrwxrwt 2 root root 4096 Apr 25 19:07 systemd-private-TOV1Bc drwxrwxrwt 2 root root 4096 Apr 24 21:28 systemd-private-UaKbSo drwxrwxrwt 2 root root 4096 Mar 17 15:00 systemd-private-wD9amr drwxrwxrwt 2 root root 4096 Mar 17 15:59 systemd-private-xepYuw drwxrwxrwt 2 root root 4096 Mar 17 15:10 systemd-private-zOqpA9 I normally do not reboot this computer, but did so yesterday after a kernel update. -- 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-05 at 16:51 +0200, David Haller wrote:

Hello,

I think it is a reaally bad idea to let systemd handle ANYTHING more than the _ONE_ task of basic startup and starting services. And it's already far beyond that "one task" (gobbling up udev??? WTF?).

Absolutely. It breaks the Unix principle of using small programs to do small tasks with perfection Instead, we have this behemoth, handling system and services starting, and taking over cron, at, syslog... :-/

-dnh, thinking about using OpenRC, oh, feel free to mail me if you'd also be interested in using that for oS ... I guess I'd manage for myself, but for the distro, a team is needed.

I guess I'm lazy. I want my comfort zone, to keep using openSUSE as much as I can... till it is too late, I guess. - -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlGGd6EACgkQtTMYHG2NR9UJwACeL5vXHXKWY9R/jxGxRn1+sG+r m/sAn3MO1Dz799DXvHqREpHVNIB2pKHM =zQpn -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

El 05/05/13 11:24, Ruediger Meier escribió:

None of the systemd developers like the UNIX idea at all.

That's not true, what is not liked is the retarded elevation of this ideas to a dogma, the one-true-god on which systems must be designed otherwise they are heretical. -- 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/05/2013 11:15 AM:

On Sunday, 2013-05-05 at 16:51 +0200, David Haller wrote:

...

Hello,

...

I think it is a reaally bad idea to let systemd handle ANYTHING more than the _ONE_ task of basic startup and starting services. And it's already far beyond that "one task" (gobbling up udev??? WTF?).

Absolutely.

It breaks the Unix principle of using small programs to do small tasks with perfection Instead, we have this behemoth, handling system and services starting, and taking over cron, at, syslog... :-/

I'm not sure that's a fair criticism. If we're talking monolithic programs that do a lot of stuff then look to things like the Mail Transfer Agents, Postfix and Sendmail before it. No, systemd is more like inetd or xinetd. Before we had inetd we had lots of individuals long lived servers that did all their own multiplexing (monolithic on a PDP-11). After inetd we had a table driven dispatcher which set up the environment for individual services. Yes, you now have lots of telnet daemons, one for each client, rather than one big one with its own internal multiplexing. Oh, wait! On some mainframes they do that for every IP service, one big, humongous server for *ALL* IP services, TCP and UDP, that is incredibly multi-threaded and complex and difficult to understand. Systemd is a dispatcher. It is a table driven dispatcher so you could call it an interpreter. That is has 'taken over' so much is more a reflection of how Linux has grown, the facilities that it has which the old K&R UNIX of the 1970s, heck even the Vaxen BSD of the early to mid 80s with VM and networking, never had. Virtual computing has demanded better resource management and allocation, so we get cgroup mechanisms. You aren't using those? Well don't bitch that that systemd lets people who manage them. Systemd is a dispatcher; it still uses other programs to do things. Are those programs small? Perhaps, like Postfix, they are not, but that's the nature of what they are doing, not the fault of systemd. Postfix was there before systemd. If anything, by breaking up the mailing process into subtasks, smaller programs, and being table driven, Postfix is an improvement, more "UNIX like" than sendmail. If you ignore all the stuff about cgroups, about sockets, then the mapping from sysvinit where there was a lot of code and all the function was in to code, we can look at systemd as abstracting all the commonality and embedding the intelligence in tables (.service files). It is an interpreter for those tables In that, it holds with a good and long standing UNIX tradition, making things table driven. Perhaps you have a problem with a 'table' being a collection of files or lines in files; perhaps you have a problem with a flat file like /etc/passwd being a 'database". But those are all good UNIX traditions. A lot of what you are complaining about is how systemd sets up 'context'. Again, I'd point you to the way xinetd sets up context for, as an example, the telnetd server. q.v. the xinetd has to set up a lot of context. -- May the itch of a thousand crabs affect the one who ruins your day and may their arms be too short to scratch. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Linda Walsh said the following on 05/09/2013 10:02 AM:

Anton Aylward wrote:

...

In that, it holds with a good and long standing UNIX tradition, making things table driven.

---- Where do you get that? Table driven is for machines.

Unix gave us bash, perl, python ruby, et all... all different tools that are script driven. Oracle gives you table driven. Windows with it's many tables and registries is table driven.

SystemD is a large-corporation set on total control tool, unix is a division of power with multiple ways to do one thing.

Systemd is not unix or linux.

UNIX has a long tradition of tables-as-text-files They usually come in two forms. The first is files the the password file. Each record is one line and the fields are delimited by, for example in the case of the password file, colons. you can find examples of this going back in UNIX to the early 70s. By the time of V7 it was well established and has continued. The second involves more complex records. These are either one-record-per file or delimited 'stanzas'. A good illustration of this is the shift from the one-record-per-line format of INETD to the one-record-per-file format of XINETD. In some cases the same kind of record that XINETD uses has been condensed to a single file. IBM did a lot of that with early AIX. Perhaps the classic example of this is the xorg.conf files, the all-in-one and now the one-file-per-item in org.conf.d/ The simplistic key-value style of 'database' we can see in various dedicated config files, most notably do do with the X project. There have been many variations on how the 'stanzas' are delimited. XINETD and xorg.conf use curly brackets in the C tradition. SSH uses a similar label/indent form but without the brackets. The current direction is to use XML style labelling and delimiting with the idea that this carries additional semantics. Yes, systemd is not UNIX. The developers made that quite clear; it is clearly stated that it is to address the needs of the Linux architecture, not the AIX or Solaris architecture. This is not odd. Solaris and AIX, as well as HPUX and who knows what else, have very specific 'value added' features some of which relate back to the hardware. I'm surprised that you assert that the interpreters are not table driven. All of then convert source to a byte steam and use that byte stream to look yp in the interpreters dispatch tables what to do. That the table might be folded into the code in various ways rather than an explicit SQL database doens't make them any the less tables. That the tables might, as in the style of FORTH, be dynamic or contain code or pointers to code is also beside the point. Some interpreters that don't need huge key-word lists and the kitchen sink of built-ins (Perl and PHP and to a large degree Ruby are examples of the 'kitchen sink') are very lean and fast. The original shell from the 'original' UNIX V7, courtesy of Stephen Bourne, was tiny. It was a very straight forward stack oriented parser and dispatcher. Systemd is like that too; it is small and is essentially a dispatcher. Just as the shell, in V7 days, was encompassing because, due to space limitations, scripts were preferred over compiled code. There were a LOT of scripts and the functionality of V7 UNIX was easy to learn from reading them. Systemd has a huge amount of internal table space, nearly twice as much as bash. $ size /bin/systemd text data bss dec hex filename 818235 34736 2320 855291 d0cfb /bin/systemd That's in addition to the external tables. Even when we subtract the tables for error dispatching we still have a huge amount of stuff for dynamically generating tables - that is the tables are internal. You don't need to access the source: running 'strings' on the binary will not only show you the error and dispatch and function name=>dispatch tables but will also show you the tables that are expressed as XML. All in all systemd ends up being about the same size as current bash. By comparison with perl and ruby: -rwxr-xr-x 1 root root 607484 Mar 25 08:10 /bin/bash -rwxr-xr-x 1 root root 860092 Jan 4 06:52 /bin/systemd -rwxr-xr-x 2 root root 1493388 Mar 11 07:06 /usr/bin/perl -rwxr-xr-x 1 root root 2109312 Mar 26 07:06 /usr/lib/libruby1.9.so.1.9.1 text data bss dec hex filename 596709 8256 26096 631061 9a115 /bin/bash 818235 34736 2320 855291 d0cfb /bin/systemd 1479378 9452 252 1489082 16b8ba /usr/bin/perl 2090923 15456 64644 2171023 21208f /usr/lib/libruby1.9.so.1.9.1 If your argument is that systemd is taking much under its wing, then I agree and I think that is a good thing because its simplifying and rationalizing (as in decreasing the entropy) for the many different and ad-hoc ways of doing things. The utilities are still out there; systemd is just managing them in a more regular fashion. And that's the point. What really makes the difference between *NIX and Windows is that *NIX has a few basic patterns that are used over and over. The various control tables and config files I mentioned above are examples of that. They are all plain text, easy to comment (unlike the Windows registry), follow the 'each thing does one thing' principle of Pike: the interpreter just interprets them and each one takes case of just one thing. Clean, simple and regular. Much more so than an ad-hoc collection of scripts that are written in different ways. I can give more examples of *NIX rationalising ad-hoc code to a table driven format if you like; its a long standing tradition that has always led to more power and more functionality and encouraged developers to new things. Take for example the kernel's vfs mechanism. Instead of drivers being hard coded one at a time into the kernel there is now a dispatch table that the drivers plug into. It has led to the development of many new file systems. -- 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 5/9/2013 10:02 AM, Linda Walsh wrote:

Anton Aylward wrote:

...

In that, it holds with a good and long standing UNIX tradition, making things table driven.

---- Where do you get that? Table driven is for machines.

Unix gave us bash, perl, python ruby, et all... all different tools that are script driven. Oracle gives you table driven. Windows with it's many tables and registries is table driven.

SystemD is a large-corporation set on total control tool, unix is a division of power with multiple ways to do one thing.

Systemd is not unix or linux.

I would say init scripts are about total control, for *me*. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

El 05/05/13 11:15, Carlos E. R. escribió:

It breaks the Unix principle of using small programs to do small tasks with perfection

ALl hail the unix dogma! seriously, the temporary file creation/deletion is done by an small specific binary called systemd-tmpfiles. Instead, we have this behemoth, handling system and

services starting, and taking over cron, at, syslog... :-/

It does not take over cron, it supports timer units as an integral part of the service management and a separate process systemd-journald takes care of logging. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

David Haller <dnh@opensuse.org> wrote: <snip>

So, anyway, if you are interested (any "you") in a old-style scripted sysvinit/old-gentoo/OpenRC (new-gentoo) style init) boot for openSUSE, we should get together. For now, just mail me, later on we can set up what we need. Oh, and we should set up a repo for init-scripts for reference, as I have few "servers" installed, please archive the sysv init-scripts of those packages you have installed (and later mail/upload them to me / that project? I still have to think about that).

You should ask on the factory list. There are a couple people at least there that have seriously discussed sysVinit support efforts. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

В Sun, 5 May 2013 15:39:59 +0200 Marcus Meissner <meissner@suse.de> пишет:

On Sun, May 05, 2013 at 09:28:41AM -0400, Anton Aylward wrote:

...

Carlos E. R. said the following on 05/05/2013 09:03 AM:

...

...

...

Take a look at /etc/cron.daily/suse.de-clean-tmp and at /etc/sysconfig/cron

That is deprecated and does not work. It doesn't, because those files are owned by root. And it doesn't because if systemd is running the cron job does not work. See release notes:

My Bad. Thank you for the correction. I looked on my 12.2 system rather than 12.3. I see that /etc/cron.daily/suse.de-clean-tmp isn't there on my 12.3 system.

Sadly /etc/sysconfig/cron is. Hmm, that was a clean install on the 12.3 machine I'm looking at so I can't blame it on being a residue of an update.

That still doesn't answer why they got created and left behind in the first place. You point out that programs _should_ clean up after themselves, but I've never relied on that. "Evidence".

I suspect this is the "PrivateTmp=true" feature of systemd, where systemservices get their own /tmp to avoid generic tmp race attacks.

So basically a security feature.

No idea about how the clean up works there, if it does not, report a bug I would say :/

Unfortunately in version we have these directories were created far too late to remove them in place (they were created in child right before exec so there was no code to remove them) and removing them during periodic cleanup is probably wrong as well (they may belong to long running service processes). In current upstream they are created differently and cleaned up when service stops. There is still corner case when system crashes and leaves those directories behind. So I think we still need to at least clean them up on reboot. bor@opensuse:~> cat /etc/tmpfiles.d/remove-systemd-private.conf R /tmp/systemd-private-* R /var/tmp/systemd-private-* -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Yes, on reboot. /tmp is already cleaned up periodically, but these directories are explicitly excluded. Отправлено с iPhone 05.05.2013, в 18:56, "Carlos E. R." <robin.listas@telefonica.net> написал(а):

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Sunday, 2013-05-05 at 18:25 +0400, Andrey Borzenkov wrote:

...

There is still corner case when system crashes and leaves those directories behind. So I think we still need to at least clean them up on reboot.

bor@opensuse:~> cat /etc/tmpfiles.d/remove-systemd-private.conf R /tmp/systemd-private-* R /var/tmp/systemd-private-*

Creating that file would delete them? When, at boot?

- -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar)

-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAlGGcxYACgkQtTMYHG2NR9WmYwCeLompAY8oAwrUeoOgnDt+RRVf sZsAn2hAQzYWkvJTxwUPGNz85Jo0jYSw =Ky+U -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

El 05/05/13 09:55, Carlos E. R. escribió:

# See tmpfiles.d(5) for details

# Clear tmp directories separately, to make them easier to override d /tmp 1777 root root 10d d /var/tmp 1777 root root 30d

# Exclude namespace mountpoints created with PrivateTmp=yes X /tmp/systemd-private-* X /var/tmp/systemd-private-*

So those files are intentionally not erased.

Correct, current versions of systemd create and manipulate this namespaces in a different fashion so you will not see this issue. Now, why you see in 12.3 ? because systemd expects /tmp to live in tmpfs but there is a SUSE-specific modification that disables this behavior by default. -- 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/05/2013 09:29 AM:

Now, I have checked the content of /usr/lib/tmpfiles.d/tmp.conf and I am quite surprise that these systemd-private-* directories are kept by choice, and they are also replicated in /var/tmp (with different suffixes):

# Exclude namespace mountpoints created with PrivateTmp=yes X /tmp/systemd-private-* X /var/tmp/systemd-private-*

So, does this mean that these directories will eventually saturate my / partition? And is it safe to manually remove them?

Good heavens! I just looked at my 12.3 box and they are there, just as you say. The note about "namespace mountpoints created with PrivateTmp=yes" temms me a lot. Now I egrep for "PrivateTmp=yes" # grep -R "PrivateTmp=yes" /etc /lib /usr/lib /etc/systemd/system/multi-user.target.wants/haveged.service:PrivateTmp=yes /usr/lib/systemd/system/haveged.service:PrivateTmp=yes Hmm. Hardly seems enough to create all those tmpfiles. Oh, right, one e set each time I book and them again later in the day for some reason. But why aren't they being cleared away? -- Psst! Viral marketing works! Tell everyone you know! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

В Sun, 05 May 2013 13:03:03 -0400 Cristian Rodríguez <crrodriguez@opensuse.org> пишет:

Because there was a long-standing problem, but the issue was moot because /tmp is supposed to be mounted as tmpfs (but it is not the case in openSUSE who carries a custom patch to disable that)

There is no "one size fits all" answer to whether /tmp should be RAM or disk based. And it is none of systemd business to tell administrator what to do here. systemd should support both.

However the underlying problem was fixed systemd 199.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Am 05.05.2013 19:03, schrieb Cristian Rodríguez:

because /tmp is supposed to be mounted as tmpfs

Says who? Since when do systemd developers dictate what should be mounted in a certain way? It has to be the other way 'round i.e., systemd has to cope with the way /tmp is mounted. Anything else would be the typical hubris of systemd's developers. Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

El mié 08 may 2013 19:39:19 CLT, Cristian Rodríguez escribió:

El 08/05/13 19:25, Philipp Thomas escribió:

...

Am 05.05.2013 19:03, schrieb Cristian Rodríguez:

...

because /tmp is supposed to be mounted as tmpfs

Says who? Since when do systemd developers dictate what should be mounted in a certain way? It has to be the other way 'round i.e., systemd has to cope with the way /tmp is mounted.

That's exactly how it works, by default (and without openSUSE's patch to disable that function) it is mounted as tmpfs, however the admin can overrride the defaults by simply systemctl mask tmp.mount or with an entry in /etc/fstab which has precedence.

Also note that this is not systemd specific debian, ubuntu and solaris also have this default and they do not use systemd (for now) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sunday, May 05, 2013 03:29:29 PM Andrea Turrini wrote:

On 05/05/2013 03:03 PM, Carlos E. R. wrote:

...

On Sunday, 2013-05-05 at 08:42 -0400, Anton Aylward wrote:

...

...

Is it correct that such directories remain in /tmp? Why are they not removed by systemd on shutdown?

I can't imagine why they are there in the first place.

I have no idea, that's why I asked.

...

...

Its not the job of systemd to purge /tmp. That's done by a cron job. We've discussed that issue here recently.

Of course it is the job of systemd! Any program creating temporary files should destroy them when they finish. Having a cronjob deleting them is a hack for careless programming.

This is what I have understood from such discussion, but probably I am wrong.

...

...

Take a look at /etc/cron.daily/suse.de-clean-tmp

I would like, but

ls: cannot access /etc/cron.daily/suse.de-clean-tmp: No such file or directory

In oS 12.2 such file was provided by aaa_base, but in oS 12.3 this file is missing (also yast2 sw_single does not show any package when searching for suse.de-clean-tmp).

...

...

and at /etc/sysconfig/cron

That is deprecated and does not work. It doesn't, because those files are owned by root. And it doesn't because if systemd is running the cron job does not work. See release notes:

+++··································· 5.2. systemd: Cleaning Directories (/tmp and /var/tmp)

By default, systemd cleans tmp directories daily as configured in /usr/lib/tmpfiles.d/tmp.conf. Users can change it by copying /usr/lib/tmpfiles.d/tmp.conf to /etc/tmpfiles.d/tmp.conf and modifying the copied file. It will override /usr/lib/tmpfiles.d/tmp.conf.

Note: systemd does not honor obsolete sysconfig variables in /etc/sysconfig/cron such as TMP_DIRS_TO_CLEAR. ···································++-

BTW, my non-comment part of /etc/sysconfig/cron as from installation is:

MAX_DAYS_IN_TMP="0" MAX_DAYS_IN_LONG_TMP="0" TMP_DIRS_TO_CLEAR="" LONG_TMP_DIRS_TO_CLEAR="" OWNER_TO_KEEP_IN_TMP="root" CLEAR_TMP_DIRS_AT_BOOTUP="" DAILY_TIME="" MAX_NOT_RUN="5" SEND_MAIL_ON_NO_ERROR="no" SEND_OUTPUT_ON_NO_ERROR="no" SYSLOG_ON_NO_ERROR="no" REINIT_MANDB=yes DELETE_OLD_CATMAN=yes CATMAN_ATIME=7

Now, I have checked the content of /usr/lib/tmpfiles.d/tmp.conf and I am quite surprise that these systemd-private-* directories are kept by choice, and they are also replicated in /var/tmp (with different suffixes):

# Exclude namespace mountpoints created with PrivateTmp=yes X /tmp/systemd-private-* X /var/tmp/systemd-private-*

So, does this mean that these directories will eventually saturate my / partition? And is it safe to manually remove them?

Best, Andrea -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org I also have these files since 3-7-13. They are all empty. Why can't they be manualled deleted if there empty and just leave the latest one. Your last concern about the partition is valid especically if they contain data. Everyone I checked was 0 bytes.

Mine are not cleared by a reboot or a shutdown. My system hasn't shutdown normally since 12.2. Nothing in the logs and I've tried everything recommended. I did report a bug but cannot find it. -- openSUSE 12.3(Linux 3.7.10-1.1-desktop x86_64)|KDE 4.10.2 "release 556"|Intel core2duo 2.5 MHZ,|8GB DDR3|GeForce 8400GS(NVIDIA-Linux-x86_64-310.32) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Linda Walsh said the following on 05/09/2013 12:04 AM:

Neutering is a very attractive idea when I think of systemd... and some of it's proponents...*sigh*...way too much testosterone in the design decisions around here: total domination: my way and no other. (am I wrong?)

There are a couple of things I don't understand. Compared to Windows, Linux is a liberal democracy. Microsoft seems quite content to issue releases that have wholesale changes that are dramatic and require an industry dedicated to retraining. They pay little attention to what users ask for. It really seems they decide what the market will be. Vendors do what they say. Our democracies may be imperfect (See Churchill on that) but if you don't like it you can join or set up a political part and get your own platform. At various stages in the process you can submit proposals and issues to be voted on, pressure your politicians. Yes they have authority, but this is because they have put themselves forward. A lot of what they do is what might be termed 'emergent necessity'; if the people want a <something> it has to be aid for, somehow, and that means taxes. You may say you don't like your president or prime minister, but at least we have a democracy and process. If you're unwilling to be part of the process then go elsewhere. I came to Canada when Maggie thatcher was in power in England. If you don't like openSuse with systemd ... The either submit something that makes up for all the deficiencies in sysvinit of your own, show it works, or go to something that doesn't use it. Like Windows. Oh, right. Back when I was at university one of the professors had a textbook that was required reading; it described a methodology for analysing a an engineering problem. At the front of the book was a quotation from the Roman poet Horace, which I think is appropriate here: If a better system is thine, impart it freely; If not, make use of mine. I think that sums up the whole FOSS movement very well. As I say, that was engineering. There are a lot of things in engineering that work and work well even though the theoreticians before hand said they wouldn't, that it was impossible or something. many such even said it in the face of demonstrations that it could be done. Some resist change for little to no rational reason. There are still men who have 'fly buttons' rather than zippers on such grounds. Linda you have many objections and I for one feel that you are inventing problems for yourself, creating a conservative stance just to be a conservative and rationalizing that stance rather than treating it rationally. Your obsession with a obsolete RFC is one example. I've tried to politely show your inconsistencies, like your objections to a file /+/usr which barely adds up to 10G when you're going on about having 1TB /tmp. Like your going on about dangling symlinks that are only symlinks for broken programs that need backward computability. And more. You claim to be a 'computer scientist' but I would have thought that such a role wound involve investigating 'the future ' and 'future directions' - whereas all we see is arch conservatism and rampant defence of recidivism. Its becoming clearer that you aren't actually a openSuse user, that you are really a Windows user. You are keeping Linux at arms length. I'm coming to believe that you're not ding enough with Linux to make the assertions you are making for the simple reason that I have proof that its not as you say, that the things you say can't work about openSuse and systemd and other 'work in progress' - which all of Linux is - are working. I'm doing better than you are on much more humble equipment. Why? because I get on with it and accept the way its going and don't construct reasons why it shouldn't work or shouldn't be allowed to work, or simply demonstrate by it working that what you say doesn't work does in fact work. But I'm just an engineer - or that's what it says in my passport. -- Victorious warriors win first and then go to war, while defeated warriors go to war first and then seek to win. Sun-tzu, The Art of War. Strategic Assessments -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Linda Walsh said the following on 05/09/2013 01:43 AM:

Anton Aylward wrote:

...

The either submit something that makes up for all the deficiencies in sysvinit of your own, show it works, or go to something that doesn't use it.

---

SysVinit was perfect for my needs -- it had no deficiencies that caused me any difficulties. So the argument is starting from a flawed premise. The whole problem here is taking something that worked for alot of people and throwing it out because some people couldn't figure out how to make it work. Brilliant!

You're being ridiculous again. It may have been perfect for your needs (though judging by some of what you say abut, for example, your problems with X, I do wonder) but you are not the entire universe of Linux never mind openSuse users. Systemd wasn't the only proposed or demonstrated solution to the growth problems of Linux, the issued that people running big systems or supporting virtual images or needing better resource management than the old, old and inadequately designed and managed 'quota' system could give. It wasn't simply that people couldn't figure out how to make sysvinit work; its that it was incapable of doing and managing many things that needed to be done. That you seem unaware of this tells me a lot. But to the point: systemd can run just fine on small single user systems like mine too.

...

If a better system is thine, impart it freely; If not, make use of mine.

---- Like you say everything is context! In my context, sysVinit was far better than the pain that systemd is causing (which I ALSO say isn't inherent to systemd, but to how the it is being crammed down user's throats.

Wriggle time, eh? The 'being jammed down our throats' - the best I can figure is that you're complaining about the that bits that are incomplete, that, like everything else about Linux, its a 'work in progress. However, unlike many other subsystems the updated and progress is being done to a much faster cycle than say, LibreOffice or KDE4. Ah, it sounds like someone is doing the 'Agile' approach! q.v.

...

Linda you have many objections and I for one feel that you are inventing problems for yourself, creating a conservative stance just to be a conservative and rationalizing that stance rather than treating it rationally. Your obsession with a obsolete RFC is one example.

---

It was the first one that popped up on google. I read the other ones you mentioned last time I suggested munging the reply-to field -- and found that was out of vogue...

And what does 'out of vogue mean? If you'd read it then you'd have seen that it obsoleted RFC822. I'd say "obsolete' trumps 'out of vogue' any day. So why quote something that is obsolete?

...

I've tried to politely show your inconsistencies, like your objections to a file /+/usr which barely adds up to 10G when you're going on about having 1TB /tmp. Like your going on about dangling symlinks that are only symlinks for broken programs that need backward computability.

---

Um...*Most* of the core utils have been in /bin since forever.

Actually that's not true if you go back far enough. If you go back far enough there was no /home and no /usr. UNIX and Linux have been subject to change and change and change. A lot of what you and I mean YOU LINDA - seem to consider in the "since forever" actually came into vogue after Bell's UNIX System Group (USG) tried to do a unification of the fork-split-fork & fork-merge-fork that was SYSTEM III and SYSTEM V shortly before it all was 'sold' to SCO. If you want examples of bad design and abysmal code just go back to that era! Part of my job then was at a distributor evaluating the impact of the change from the V7 code base to the SYSTEM III code base. Almost every one of the 'core utils' had been changed and the resulting code was terrible compared to the neat K&R of V7.

Moving them for no reason is bad design.

Ah, clearly you haven't read up on this to discover the reasons, the quite good and justifiable reasons. Just like you didn't read up on other RFCs that obsoleted 822.

Saying you want to have all of them accessible in /usr/bin means you could leave the originals in /bin for several releases, and put symlinks in /usr/bin to the originals.

At the present. But you don't seem to have read on the long terms plans.

After plenty of time -- and maybe not all at once, you let people get used to them in /usr/bin -- not cut off life support before their programs are ported (let alone their habits).

That's just what's going on. They are in /usr/bin but the symlinks are for the broken programs. Nothing is 'cut off'. Oh, unless you break other things like not reading the docco properly and try to have a /usr that isn't loaded at boot.

...

You claim to be a 'computer scientist' but I would have thought that such a role wound involve investigating 'the future ' and 'future directions' - whereas all we see is arch conservatism and rampant defence of recidivism.

---

Nope...computers revolved around being useful tools for people -- not instruments to terrorize and oppress them.

that's off topic. Of course government databases, are there to terrorise and oppress and manipulate, but those databases ("list of names") were around long before computers. Computers like Stonehenge let the government oppress the farmers by telling them when they *HAD* to plant their crops. We've seen similar all the way though history.

Their role has changed over the years. It used to be companies did usability studies and hired users to come in use the product to see how they could improve usability and make the interfaces easier and more natural to use.

Now? Those who write programs tell users they have to adapt to the computer -- immediately. no choice. Change is great done right... but hit the earth with a meteor the size of the moon and change would be hurting alot of people.

Eh? Talk about "off topic". Could you point out some, no, I'll settle for just one, meteor the size of the moon in an earth-grazing solar orbit.

...

Its becoming clearer that you aren't actually a openSuse user, that you are really a Windows user. You are keeping Linux at arms length. I'm coming to believe that you're not ding enough with Linux to make the assertions

---

Context, dear boy, context... it is everything (or so you say) Why would you think that because I don't do the same things you do I don't do enough with it? How many services do you run on your linux boxes that *serve* other computers?

It says that its running 27. That's another 800MHz/1G system. But how about you clarify what your WORKSTATION is.

This has been about changes antithetical to good server hygiene but useful for a locked-down walled-garden app-player appliance.

I disagree with that; I think others do too.

linux has been about *open*ness as was OpenSuse... closing it up so it only works one way, isn't open.

That's an assertion that runs in the face of evidence. One of Suse's great boast is the build service. That's about as open as you can get!

Out of the over 30 some odd services, over 20 of those services are services other computers rely on to function.

Yes, that's how I've been running Linux for years and many flavours of UNIX before that. many of us here are in the same situation.

My linux computer is the backbone of my home network -- providing proxy/network routing, disk space, backup/domain server, mail server imap server, named/bind name resolution, time keeping, data sharing amongst several more.

Yes; and I've done that with, at various times, all the RPM-based Linux distributions :-) As wall as HP/UX DG/UX. many versions of AIX as that evolved; SUNOS, Solaris; SCO UNIX, Convergent UNIX, many of the now defunct UNIX-on-16-bit-micros that sprung up in the late 70s and early 80s after the first round of it of being pried away from Bell and them being forced to licence the code. Many of us are running what you describe and more (various web servers, various database servers) as well as RAID arrays, PBX and telecoms management; brokerage and arbitrage systems...

When I wasn't running 12.X or factory my system's uptime was measured in months... I don't use it for a desktop because -- it isn't as user friendly to people with RSI --

Ah NOW you mention RSI. So you use MS-Windows because that *IS* friendly to people with RSI. What is that, 'workrave'? It runs on Linux as well.

that and it's not as compatible with the applications I have used... though I constantly try to get linux-remote desktop working so I could use it more often... but so far, xrdp doesn't want to show me any desktops...though at least it answers the 'line' now when my remote desktop client knocks... I'd love to get remote sound working as well..but most of all, I'd like to get the GLX stuff working remotely...

What's 'xdrp'? VNC works just fine here; server (and or client) on all my Linux boxes Plenty of VNC viewers for Windows. By what you say you have plenty of LAN bandwidth and local processing on your Windows graphics.

As far as having my system partitions be LVM, that would be *convenient*, but many times, (like tonight), some issue comes up where non of the lvm disks mount.

I've been using LVM since it came out for Linux having used a similar system with AIX for years. I've never had problems with it unless and until the disk hardware give up, and even then I can often localise the problem enough to recover. if you screw your kernel, for example your initrm/boot doesn't have the module config into it, they obviously you'll have problems; that goes for any driver.

With non-lvm system disks I have a way to repair the damage quickly...

And I have the knowledge to repair lvm systems.....

(or used to when things were more reliable...now it takes a bit longer sometimes)... It doesn't sounds like you are a computer scientist. If you were, you'd know that having a computer that is reliable in spite of what you've done to it is a huge bonus.

No, I'm not a doctor, I'm an engineer. I recall Kipling: http://www.poetryloverspage.com/poets/kipling/hymn_of_breaking_strain.html and http://www.poetryloverspage.com/poets/kipling/sons_of_martha.html I *EXPECT* thing to break and fail and wear out.

Fragility sucks.

Yes, so? Any engineer knows how to design indefinitely reliable system s out of unreliable compensates ... given enough time, money and manpower :-) -- Computers are good at following instructions, but not at reading your mind. -- Knuth, _The TeXbook_ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward <opensuse@antonaylward.com> wrote:

Linda Walsh said the following on 05/09/2013 12:04 AM: Compared to Windows, Linux is a liberal democracy. Our democracies may be imperfect (See Churchill on that) but if you don't like it you can join or set up a political part and get your own platform. At various stages in the process you can submit proposals and issues to be voted on, pressure your politicians.

NO. This indicates an incorrect and ideological understanding of Open Source. Open Source is in no way like 'democracy'. in democracy every coach potato with an axe to grind or imagined grievance gets to vote. it does not work that way in Open Source. Open Source is a tyranny of the contributor. Plain and simple. You write code - you win. You whine - nobody cares.

If you don't like openSuse with systemd ...

Fortunately I do. 20+ years of UNIX administration ... die SysV die. I am so tired of sermons from those of the tired religion of the holy text file. If someones vision of good system administration involves grep and regular expressions I don't want to be employed beside them. These things are HACKS, are always broken (or about the break), and very difficult to figure out when you go into a site.

Roman poet Horace, which I think is appropriate here: If a better system is thine, impart it freely; If not, make use of mine.

This entirely misses the intersection of engineering with reality; reality adds marketting, the zietgeist, and the gravity of user communities. -- Adam Tauno Williams -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Adam Tauno Williams said the following on 05/10/2013 10:15 AM:

...

...

If you don't like openSuse with systemd ... Fortunately I do. 20+ years of UNIX administration ... die SysV die. I am so tired of sermons from those of the tired religion of the holy text file. If someones vision of good system administration involves grep and regular expressions I don't want to be employed beside them. These things are HACKS, are always broken (or about the break), and very difficult to figure out when you go into a site.

I too like systemd and the direction it is taking us. UNIX - and Linux - is a real computer system, not a toy. The big server farms and the array servers are demonstrating that. I'm glad I used V7 and all the small systems; they were a great learning experience, but I HATE HATE HATE what USG did. Lots of bad code and it set the way for breaking the clarity and simplcity of Dennis's creation. Yo me, USG let Entropy in. Looking back, I can see that as a necessary step in the commercialization, but as it documented a lot of stuff, but it lead to things like the X-Wars and the media hasn't given up yet on the idea that the the diversity of *NIX is an advantage over the totalitarianism of the 'locked in' systems. Scripting is great, until it became unmanageable; and the SysVinit suite has long since become a moras. I think it was Gerry Weinberg who coined the idea of "5 finger code", referring to using your fingers to keep marks as you clip back and forth in the 14" fanfold listing or spaghetti code of the COBOL and Assembler days. SysVinit has become like that. Dennis's v7 had simple, clear "do one thing and do it well" scripts, and the SyVini scripts are a complete counterpoint to that clarity. As a home user neiother I not Linda can eb viewed as the main market for UNIX and Linux. I have clients who need systems that aren't difficult to figure out, and the ways systemd works fits that. The way systemd logs is great for them. Even now, well ... Under my desk is one of the crapped out 800Mhz box from the Closet of Anxieties. Its running a DNS server for the other such boxes. The DNS loads a huge set from http://pgl.yoyo.org/as/serverlist.php This morging I watched it load and saw ... Feb 8 10:04:33 server named-checkconf[1810]: zone ad2.lupa.cz/IN: loaded serial 2012100600 Feb 8 10:04:33 server named-checkconf[1810]: zone ad2.mamma.com/IN: loaded serial 2012100600 Feb 8 10:04:33 server rsyslogd-2177: imuxsock begins to drop messages from pid 1810 due to rate-limiting Feb 8 10:04:35 server rsyslogd-2177: imuxsock lost 268 messages from pid 1810 due to rate-limiting Even this crappy old machine can outpace the syslog daemon writing to a text file. Now some of my clients are using syslog to monitor networks of hundreds of machines. And in order to mine the data they are sticking it into a database so they can perform queries on it, ones that are more involved than you can do with grep and regular expressions. Text files can't cut it any more. Even back in the 80s many university sites found that their machines ground to a halt when someone logged in. One of the assumptions that Denis made for the kernel was that the kernel tables were small and so didn't need complicated algorithms. The overhead of things like binary injection/search was little advantage over linear when there were so few entries. But that didn't hold when your password file had thousands of entries, the universities found. So even at BSD4.1/4.2 there were patches for password files that were indexed. Now we have corporations where *NIX is handling the mail for hundreds of thousands of employees. The overhead of accessing a SQL database (which is what's behind many LDAP servers) is trivial by comparison. Heck, even back in 1990 I was using RADIUS at an ISP. Text files can't cut it any more. Well, that's not an ABSOLUTE. Those examples are about high volumes that need to be accessed fast and randomly. (Rather like a disk, eh? So use the BtrFS!) Systemd is, in effect, the system version of what inetd is for network daemons -- a dispatcher and manager. Yes, they could both have their config files in a SQL style database but pretty soon you'll have the Windows Registry. That's neither needed not useful in this context. We're not talking about a high volume or entries or a high rate of repeated access with inetd/xinetd or systemd. Perhaps the debate should be about human intelligible vs machine optimized text files. The style used in systemd, xinit, xorg.conf are documented externally but allows for in-line comments, something I sorely miss when dealing with things like Windows registry. The XML format has the semantics documented elsewhere, hopefully, with the DTD, but how much semantic for the human is there in that? Human manageable configuration text files have their place. Perhaps, just as in _some_ systems, the password file has evolved into something indexed and shared so might systemd and so might xinetd and so might xorg.conf, but I don't see it for any of them in the immediate future. There really isn't the pressure as there is with the high volume or high transaction rate systems I mentioned to open with. -- People who won't quit making the same mistake over and over are what we call conservatives. - Richard Ford, in his novel Independence Day -- 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 Friday, 2013-05-10 at 13:20 -0400, Anton Aylward wrote:

Under my desk is one of the crapped out 800Mhz box from the Closet of Anxieties. Its running a DNS server for the other such boxes. The DNS loads a huge set from http://pgl.yoyo.org/as/serverlist.php This morging I watched it load and saw ...

Feb 8 10:04:33 server named-checkconf[1810]: zone ad2.lupa.cz/IN: loaded serial 2012100600 Feb 8 10:04:33 server named-checkconf[1810]: zone ad2.mamma.com/IN: loaded serial 2012100600 Feb 8 10:04:33 server rsyslogd-2177: imuxsock begins to drop messages from pid 1810 due to rate-limiting Feb 8 10:04:35 server rsyslogd-2177: imuxsock lost 268 messages from pid 1810 due to rate-limiting

Even this crappy old machine can outpace the syslog daemon writing to a text file.

No, that's a known issue and it is solvable, either with an update or an adjusting of your settigns. I reported about that problem here: Date: Wed, 12 Sep 2012 17:14:03 +0200 (CEST) From: Carlos E. R. <> Subject: [opensuse] rsyslog drops thousands of messages. And my machine is powerful enough, yet it was dropping thousands of messages - not because CPU or i/o limits.

Now some of my clients are using syslog to monitor networks of hundreds of machines. And in order to mine the data they are sticking it into a database so they can perform queries on it, ones that are more involved than you can do with grep and regular expressions.

Text files can't cut it any more.

syslog can use databases, too. Just configure it. I also worked sometime for a company that sold a very expensive product that stored text output from logs into databases, producing alarms and usefull things. Hugely expensive... and inefficient. We could find stuff sooner with a PC running Linux and grepping the original text files, than the very expensive machine with expensive software was using. But heck, what we used could not be talked about, or the business from the big official product wuld plummet, and we would not get our salaries! >:-P

Well, that's not an ABSOLUTE. Those examples are about high volumes that need to be accessed fast and randomly. (Rather like a disk, eh? So use the BtrFS!)

Reiserfs was designed to operate like a database. It was to be done for real in version 4, you could add your own modules. Pity.

Perhaps the debate should be about human intelligible vs machine optimized text files. The style used in systemd, xinit, xorg.conf are documented externally but allows for in-line comments, something I sorely miss when dealing with things like Windows registry. The XML format has the semantics documented elsewhere, hopefully, with the DTD, but how much semantic for the human is there in that?

Human manageable configuration text files have their place.

Indeed! :-) - -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlGRQmEACgkQtTMYHG2NR9V5+wCeMw66jrh8Tqc5eumVLh931KWT GqgAnAoQ6wASv66rloZmnjY2sSlhp5IQ =v4N+ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Adam Tauno Williams wrote:

Anton Aylward <opensuse@antonaylward.com> wrote:

...

Compared to Windows, Linux is a liberal democracy. Our democracies may be imperfect (See Churchill on that) but if you don't like it you can join or set up a political part and get your own platform. At various stages in the process you can submit proposals and issues to be voted on, pressure your politicians.

NO. This indicates an incorrect and ideological understanding of Open Source. Open Source is in no way like 'democracy'. in democracy every coach potato with an axe to grind or imagined grievance gets to vote. it does not work that way in Open Source.

Open Source is a tyranny of the contributor. Plain and simple. You write code - you win. You whine - nobody cares.

Yup... I think that's what some of us have been saying. But it's not quite that simple ― as with larger projects, it is also about who is *ALLOWED* to contribute (or in what way). Too many times I've been brushed off with "patches or source code gladly accepted", to come back with a patch that they refused to allow in to mainline on political ― not engineering grounds. Such projects wear the label of "open" only in so much as you are free to go off and do your own thing in a "hole", but don't expect them to be open to changes. They have an established political power base that they want to keep. If they allowed anyone to contribute, it would dilute their power. Perl is a prime example. The one contribution to samba I made was labeled, falsely, as insecure ― as part of the accepted command to enable the feature! (i.e. if you have unix-extensions enabled on a samba server and allowed "wide links" (ones that would span given shares), it meant that client systems could point those wide links anywhere. IF your security policy used samba/winbind for unix access as well as windows (same accounts on both) and you allowed users to login to the local server, this was NOT a security issue, as they would be able to create such symlinks while logged in locally ― so turning off unix-extensions a ridiculous response to the issue. I added an extension to reallow it: "allow client managed wide links = [yes/no]" which says what it did ― allowed client machines to manage wide links directly ― and the decision to allow that could be made based on local security practice/policy. The samba team changed that to "allow insecure wide links = [yes/no]" ― and their manpage says: It is not recommended to enable this option unless you fully understand the implications of allowing the server to follow symbolic links created by UNIX clients. For most normal Samba configurations this would be considered a security hole and setting this parameter is not recommended. -- Which is misleading and on the face of it, inaccurate, unless you consider windows clients to be UNIX clients (?). Having the samba team promote the idea that turning that off makes things more secure in ANY way, while you have setup samba to provide unix-login credentials to windows users (something touted as a samba feature ― single signon access), is misleading, at best. It offers security advice knowing nothing about the clients security setup or their needs when samba sells their single-signon feature as a desireable feature (it is, but it can open the same security holes). Vs. my labeling which I felt added no "spin" to the feature ― but DID say what it did, without having to consult a manpage. So, opensource isn't only about who does the work ― but it's about control of who is allowed to submit and how it is filtered after submission. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Am 05.05.2013 18:15, schrieb Cristian Rodríguez:

...

Its not the job of systemd to purge /tmp.

Yes, it is.

Care to tell us the rationale in making it systemd's job? Philipp -- 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 Thursday, 2013-05-09 at 01:28 +0200, Philipp Thomas wrote:

Am 05.05.2013 18:15, schrieb Cristian Rodríguez:

...

...

Its not the job of systemd to purge /tmp.

Yes, it is.

Care to tell us the rationale in making it systemd's job?

The cron job that was doing it in openSUSE has been removed or disabled, and it is systemd now who does it. I'm neither saying I like it or not, I'm merely stating a fact. - -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlGLEbQACgkQtTMYHG2NR9XNKgCgiL5hwUK53he1CopwA9csZezg HO4Anjn8BrbETL1Rz3aZeZhSEtFz1AQc =lfbx -----END PGP SIGNATURE-----