so... you expected... something in /var/tmp to be safe? I think it is simple to see the fallacy... Alin -- Without Questions there are no Answers! ______________________________________________________________________ Alin Marin ELENA Advanced Molecular Simulation Research Laboratory School of Physics, University College Dublin ---- Ardionsamblú Móilíneach Saotharlann Taighde Scoil na Fisice, An Coláiste Ollscoile, Baile Átha Cliath ----------------------------------------------------------------------------------- http://alin.elenaworld.net ______________________________________________________________________ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Melchior FRANZ [11-19-11 08:15]:

On Saturday 19 November 2011 12:47:15 Alin Marin Elena wrote:

...

so... you expected... something in /var/tmp to be safe? I think it is simple to see the fallacy...

The key parts are "used to be safe" and "without warning". A responsible distributor doesn't risk his users' data in this way.

conversly, a "responsible user" doesn't store data "expecting it to be save" in a system temporary directory, keyword *temporary*: Temporary \Tem"po*ra*ry\, a. [L. temporarius, fr. tempus, temporis, time: cf. F. temporaire.] Lasting for a time only; existing or continuing for a limited time; not permanent; as, the patient has obtained temporary relief. [1913 Webster] -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Melchior FRANZ [11-19-11 08:15]:

On Saturday 19 November 2011 12:47:15 Alin Marin Elena wrote:

...

so... you expected... something in /var/tmp to be safe? I think it is simple to see the fallacy...

The key parts are "used to be safe" and "without warning". A responsible distributor doesn't risk his users' data in this way.

conversly, a "responsible user" doesn't store data "expecting it to be save" in a system temporary directory, keyword *temporary*: Temporary \Tem"po*ra*ry\, a. [L. temporarius, fr. tempus, temporis, time: cf. F. temporaire.] Lasting for a time only; existing or continuing for a limited time; not permanent; as, the patient has obtained temporary relief. [1913 Webster] ps: default settings on *my_box* do not include /var/tmp so you have made a change or have a local system problem..... -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Saturday 19 November 2011 13:45:36 Melchior FRANZ wrote:

Apparently, 12.1 has added /var/tmp/ to TMP_DIRS_TO_CLEAR in /etc/sysconfig/cron. I was quite surprised when I found out today that I've lost a few GB of data, which used to be safe there.

Needless to say that I'm not pleased. No backups, because it wasn't *that* important, but I find such changes without warning suboptimal, to put it politely.

The Filesystem Hierarchy Standard stipulates that the OS must not delete files in /var/tmp on boot, so if this were the case you would be right. However, I can't see that this is the case on my system. The default setting is /tmp only, and I can't immediately see anything in YaST that would add /var/tmp to it Anders -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2011-11-19 at 15:18 +0100, Anders Johansson wrote:

However, I can't see that this is the case on my system. The default setting is /tmp only, and I can't immediately see anything in YaST that would add /var/tmp to it

# This variable contains a list of directories, in which old files are to # be searched and deleted. The frequency is determined by MAX_DAYS_IN_LONG_TMP # If cleaning of /var/tmp is wanted add it here. # LONG_TMP_DIRS_TO_CLEAR="" - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7HwFYACgkQtTMYHG2NR9UmLQCaAmbVqQbf75HHcdvliIVzj+3D dk4Anjrc2wYz6wQZLmhXs/G42y0j73Sr =CKhg -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sat, 2011-11-19 at 09:03 -0500, Patrick Shanahan wrote:

* Melchior FRANZ [11-19-11 08:15]:

...

On Saturday 19 November 2011 12:47:15 Alin Marin Elena wrote:

...

so... you expected... something in /var/tmp to be safe? I think it is simple to see the fallacy...

The key parts are "used to be safe" and "without warning". A responsible distributor doesn't risk his users' data in this way.

conversly, a "responsible user" doesn't store data "expecting it to be save" in a system temporary directory, keyword *temporary*:

And, "a responsible user" makes backup's & test if restore is functioning satisfactory. period. Specially before doing anything drastic. Even then shit happens: Made regularly backups on two different external drives, and tested them, but in my darkest hour they both failed... Who ever you blame, the distributor shouldn't be part of the equation. hw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Saturday 19 November 2011 16:40:50 Carlos E. R. wrote:

I know. I wonder what the OP got.

$ grep DIRS_TO_CLEAR= /etc/sysconfig/cron TMP_DIRS_TO_CLEAR="/tmp /var/tmp" LONG_TMP_DIRS_TO_CLEAR="" And I haven't set that. Well, at least not since I can remember. So either something in 12.1 or a recent Tumbleweed upgrade has set it, *or* I've set it several years ago and only since a few days it has an effect, maybe because of a bugfix? Anyway, I'm meanwhile restoring parts from a non-backup ... m. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 19/11/11 12:13, Hans Witvliet wrote:

Who ever you blame, the distributor shouldn't be part of the equation.

Yeah, like the stickers some public transport buses used to have here: "If you are late, it isn't the fault of the driver" :-) Maybe the user has the "tmpwatch" package installed.. ? that's gonna delete files in /var/tmp if they are older than 30 days. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Saturday 19 November 2011 13:11:43 Cristian Rodríguez wrote:

Maybe the user has the "tmpwatch" package installed.. ? that's gonna delete files in /var/tmp if they are older than 30 days.

No, he hasn't. In case someone hasn't understood yet: I'm not disputing whether it's a good idea to clean out /var/tmp/ -- it possibly is --, what annoys me is a sudden change in behaviour that kills data without warning, even if they might have been in the wrong place (which isn't such a clear case). But I accept that this isn't default in 12.1 and must come from somewhere else. I also have my ~/tmp/ since years. Still, I considered stuff in /var/tmp/ to be maintained by the applications which put it there. And if $USER put stuff in /var/tmp/$USER/ then I assumed that it would be $USER's responsibility to clean it, whenever s/he feels like it. Temporary doesn't necessarily mean "short-lived". If data is important enough that it should survive rebooting, then it shouldn't be treated as trash by the system. m. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2011-11-19 at 16:58 +0100, Melchior FRANZ wrote:

On Saturday 19 November 2011 16:40:50 Carlos E. R. wrote:

...

I know. I wonder what the OP got.

$ grep DIRS_TO_CLEAR= /etc/sysconfig/cron TMP_DIRS_TO_CLEAR="/tmp /var/tmp" LONG_TMP_DIRS_TO_CLEAR=""

I have in my work partition (11.4), updated many times: TMP_DIRS_TO_CLEAR="/tmp" LONG_TMP_DIRS_TO_CLEAR="/var/tmp" In another test partition, was a fresh install: Telcontar:~ # cat /other/test_a2/etc/SuSE-release openSUSE 11.2 (x86_64) VERSION = 11.2 Telcontar:~ # grep DIRS_TO_CLEAR= /other/test_a2/etc/sysconfig/cron TMP_DIRS_TO_CLEAR="/tmp" LONG_TMP_DIRS_TO_CLEAR="" - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7H7eIACgkQtTMYHG2NR9UA9gCgg3+nJ6EPTU5pD/3RAWu3a4QY pFwAmgIfu/9DJUuOUfIYSC8KYZNXMFpA =PBvP -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Le 19/11/2011 19:25, Roger Luedecke a écrit :

...

m. Were there any release notes related to the changes in tmp etc? I was surprised myself when I opened up the partitioner and sa a bunch of TMPFS I had never seen before, only one of which I could recognize as being something systemd probably needed.

it was said very often that /tmp was copied in tmpfs (if I understood well, not sure) and most work done there. I don't know how much it's related to the present problem jdd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Melchior FRANZ wrote:

Apparently, 12.1 has added /var/tmp/ to TMP_DIRS_TO_CLEAR in /etc/sysconfig/cron. I was quite surprised when I found out today that I've lost a few GB of data, which used to be safe there.

Needless to say that I'm not pleased. No backups, because it wasn't *that* important, but I find such changes without warning suboptimal, to put it politely.

m.

----------------- I would agree with the above. Traditionally /var/tmp has been in "LONG_TMP_DIRS_TO_CLEAR"... I have them set to 'autoclean at 21 and 42 days', respectively. I think it would be irresponsible and violate normal unix-cleaning standards to treat /var/tmp the same as /tmp. If the desire was to treat them the same, then there would never have been two separate directories in the first place! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Cristian Rodríguez wrote:

It is unrelated to this topic and /tmp is no longer a directory that resides in your hard disk, but in shared memory, if you are running out of memory, it will be put in swap. there is nothing you have to be worried or configure, the kernel will do the work for you.

---- [*ouch*....that hurts.] I don't have hmmm, actually I do have gigabytes hmmm... I was gonna complain because I use /tmp to tranfer tars of user dirs that can be (under pathological cases) up to 20-30GB, but USUALLY are <5GB (they are roaming profiles, so I prefer to keep them under 2-3GB)... And for a second I thought those were 'large' files...and to have them consume memory and swap.....but then ...I realized, I'm in 2011, not 199x. *sigh*...Actually, wait-- it STILL could be a problem... Still... 2-3 GB can be large -- photoshop had a cow with a 2.6GB tif this morning -- thought I was 'hosed'...couldn't open it for the longest time...(some layer had been 'distorted' and as a result grew to enormous proportions -- thought it wasn't visible as it was contained in a small ~100px mask....the layer had been a pouring of a paintbucket... Photoshop stores such things as bitmasks...it started as a 4.5Kx4.5K image, so each such "fill layer" (in quotes, cuz there is an official fill layer type, that if chosen, won't create the bit mask, but it's not the default, and it's not an option in the default new-layer dialog). So when it got resized -- apparently via 'perspective', instead of distort, a small shift at one end made the other end VERY large... from the size increase, (1.1G added, and PS gets about 75% compression on a unicolor layer, , it added about 4.4G of pixels, or apparently blew up my 'solid black color for my 100px^2 shape to a 69,000px^2 32 bit/px, image. Oddly, it just hung, trying to open (disk trashing with PS's TMP files...as it self monitors physmem usage and then does it's own spill's to tmp. Had 11G free and 0 swap usage (on an SSD). Hmmm... Right now, for a 1.5G image, PS is using 163GB in /tmp (actually a per-user tmp)....and THAT actually would be a problem if it was on a tmpfs... as I don't have SWAP configged at 4-8X available memory. May not be an issue...BUT..that had been done on windows, I'd be screwed. To edit images I have to keep almost half my hard disk free for Adobe Photoshop 5 -- unbelievable. What a Frickin pig! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sunday 20 November 2011, Carlos E. R. wrote:

On Saturday, 2011-11-19 at 16:18 -0300, Cristian Rodríguez wrote:

...

It is unrelated to this topic and /tmp is no longer a directory that resides in your hard disk, but in shared memory, if you are running out of memory, it will be put in swap. there is nothing you have to be worried or configure, the kernel will do the work for you.

Many people do not have big swaps.

Fortunately, what you say doesn't seem to be true:

If /tmp became tmpfs then this happens hopefully only whith fresh installtion and not after zypper dup!?

Elanor:~ # mount | grep tmp devtmpfs on /dev type devtmpfs (rw,relatime,size=372396k,nr_inodes=93099,mode=755) tmpfs on /dev/shm type tmpfs (rw,relatime) tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)

What's this? /var/run?

tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755) tmpfs on /var/lock type tmpfs (rw,nosuid,nodev,relatime,mode=755) tmpfs on /media type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755) tmpfs on /var/run type tmpfs (rw,nosuid,nodev,relatime,mode=755)

I don't see why /media has to be a tmpfs either. It is used for automounting.

/media is made to hold only auto created dirs for auto mounting. Making it tmpfs might be an elegant way to get it cleared every reboot without needing scripts to do that. In opposite to /tmp it will not eat much swap space. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sunday 20 November 2011, Cristian Rodríguez wrote:

On 19/11/11 21:08, Rüdiger Meier wrote:

...

What's this? /var/run?

Explained in detail here http://lwn.net/Articles/436012/

Ok, so hopefully it's only a systemd issue. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: On Sunday, 2011-11-20 at 01:08 +0100, Rüdiger Meier wrote:

On Sunday 20 November 2011, Carlos E. R. wrote:

If /tmp became tmpfs then this happens hopefully only whith fresh installtion and not after zypper dup!?

My only test install is fresh, and virtual.

...

Elanor:~ # mount | grep tmp devtmpfs on /dev type devtmpfs (rw,relatime,size=372396k,nr_inodes=93099,mode=755) tmpfs on /dev/shm type tmpfs (rw,relatime) tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)

What's this? /var/run?

That's a different one. There is now a /run, and in my test system it is populated: Filesystem Size Used Avail Use% Mounted on rootfs 9.9G 3.4G 6.1G 36% / devtmpfs 364M 36K 364M 1% /dev tmpfs 370M 0 370M 0% /dev/shm tmpfs 370M 572K 370M 1% /run /dev/sda2 9.9G 3.4G 6.1G 36% / tmpfs 370M 0 370M 0% /sys/fs/cgroup tmpfs 370M 572K 370M 1% /var/run tmpfs 370M 0 370M 0% /media tmpfs 370M 572K 370M 1% /var/lock Having those 370M (I hope shared between all of them) it is an issue for me, because this test system is a virtual machine on VMplayer, with only "756944k" of RAM. Both /run and /var/run are different filesystems, but they contain the same files, as far as I can see. Ahhh... The link Cristian posted explains it. A bind mount. They propose to make symlinks later on.

...

I don't see why /media has to be a tmpfs either. It is used for automounting.

/media is made to hold only auto created dirs for auto mounting. Making it tmpfs might be an elegant way to get it cleared every reboot without needing scripts to do that. In opposite to /tmp it will not eat much swap space.

But I don't see why it is needed. Are there that many mounts per minute so that we need to run the /media on ram? - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7JkvIACgkQtTMYHG2NR9V5JwCgk7zhAEiKO5/o5rnXk+AiETci nfUAnRs/NWmIVe+8vHzM092KKuuyC8IK =IoJP -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2011-11-20 at 21:17 -0300, Cristian Rodríguez wrote:

On 20/11/11 20:53, Carlos E. R. wrote:

No, it is not. it is the default tmpfs size, (half of your ram not counting swap) that space IS NOT reserved, it is a "hint" to the maximum size that can be allocated.

Ah, ok. That's better.

...

But I don't see why it is needed. Are there that many mounts per minute so that we need to run the /media on ram?

it is to ease software maintenance, and uses no ram since it is empty.

Mmmm... :-) - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7JnukACgkQtTMYHG2NR9VgTwCfVOoWrsw+qnZq/7O9cpyEMpir wk0AoI4G+n+CbJ4N0yEEpIHiCRQAzI// =kHw/ -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: On Sunday, 2011-11-20 at 23:19 -0500, Ken Schneider - openSUSE wrote:

On 11/20/2011 07:17 PM, Cristian Rodríguez pecked at the keyboard and wrote:

...

On 20/11/11 20:53, Carlos E. R. wrote:

...

Having those 370M (I hope shared between all of them) it is an issue for me, because this test system is a virtual machine on VMplayer, with only "756944k" of RAM.

No, it is not. it is the default tmpfs size, (half of your ram not counting swap) that space IS NOT reserved, it is a "hint" to the maximum size that can be allocated.

...

But I don't see why it is needed. Are there that many mounts per minute so that we need to run the /media on ram?

it is to ease software maintenance, and uses no ram since it is empty.

As in easier to use then "zypper up package1"? What is so fubar'd that some other form of package management is now needed?

We are not talking package management in this thread. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7KRfgACgkQtTMYHG2NR9UUPQCfWHHHPvT4+Dc1oIk2o36zkjag UScAoI+RNiIgA1NfkDYuCesKlAHGWdWH =m9QQ -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2011-11-21 at 08:23 -0500, Ken Schneider - openSUSE wrote:

...

We are not talking package management in this thread.

Sorry for the noise, I guess I just don't understand the logic here.

You probrably got confused with another thread where they are discussing package management. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7KVycACgkQtTMYHG2NR9Xa6wCfeXoOHdJUNejoE6WFRKsetG5x TD4AnAutj7RXwdzAKRwJXUQf2nvTQg0Z =3/D9 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2011-11-21 at 14:14 -0500, Brian K. White wrote:

You do know that tmp stands for "temporary" right? That's pretty much the end of the conversation right there, regardless if that dir ever used to be cleaned automatically or not.

The system is not the exclusive owner of temporary space. People can use it for temporary purposes of their own. The system is free to erase the temporary files it creates, but not the temporary files created by others - - unless the admin explicitly says otherwise. The problem is that the system is unable to keep track of its own temporary files, so it erases all. That must be the decision of the admin, not of the system, ie, the packagers. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7K034ACgkQtTMYHG2NR9WmaACcC8z7V5iVVNdf+NrW5qxMPW5B croAn0gyghkyBdheAoO5AArzQh03dZUW =nkIG -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Melchior FRANZ wrote:

Apparently, 12.1 has added /var/tmp/ to TMP_DIRS_TO_CLEAR in /etc/sysconfig/cron. I was quite surprised when I found out today that I've lost a few GB of data, which used to be safe there.

$ tail -2 /usr/lib/tmpfiles.d/tmp.conf d /tmp 1777 root root 10d d /var/tmp 1777 root root 30d That tells systemd to clear files older than 10 resp 30 days in those directories. systemd does not honor TMP_DIRS_TO_CLEAR. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Nov 23, 2011 at 10:02 AM, Ruediger Meier wrote:

On Wednesday 23 November 2011, Ludwig Nussel wrote:

...

Melchior FRANZ wrote:

...

Apparently, 12.1 has added /var/tmp/ to TMP_DIRS_TO_CLEAR in /etc/sysconfig/cron. I was quite surprised when I found out today that I've lost a few GB of data, which used to be safe there.

$ tail -2 /usr/lib/tmpfiles.d/tmp.conf d /tmp 1777 root root 10d d /var/tmp 1777 root root 30d

systemd is also cron replacement?

...

That tells systemd to clear files older than 10 resp 30 days in those directories. systemd does not honor TMP_DIRS_TO_CLEAR.

If this is really the default now then it should have been a major point on ReleaseNotes. Since this major change was not announced I would consider it a major bug to be fixed by adding /etc/tmpfiles.d according to what is the default in /etc/sysconfig/cron.

cu, Rudi

Rudi, If you read the whole thread: - The user at some point in the past added /var/tmp to /etc/tmpfiles.d - apparently a bug kept that from being honored, so files just sat there - 12.1 fixed the bug and files disappeared. Overall its bad luck, but it is not a major issue from the release management perspective. Greg -- Greg Freemyer Head of EDD Tape Extraction and Processing team Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer CNN/TruTV Aired Forensic Imaging Demo -    http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retriev... The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Ludwig Nussel [2011-11-23 15:46]:

Melchior FRANZ wrote:

...

Apparently, 12.1 has added /var/tmp/ to TMP_DIRS_TO_CLEAR in /etc/sysconfig/cron. I was quite surprised when I found out today that I've lost a few GB of data, which used to be safe there.

$ tail -2 /usr/lib/tmpfiles.d/tmp.conf d /tmp 1777 root root 10d d /var/tmp 1777 root root 30d

That tells systemd to clear files older than 10 resp 30 days in those directories. systemd does not honor TMP_DIRS_TO_CLEAR.

It is kind of ironic how an old request to adapt a similar policy to the above had been shot down on the feature graveyard and was now introduced through the backdoor without discussion. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday 23 November 2011, Cristian Rodríguez wrote:

On 23/11/11 12:02, Ruediger Meier wrote:

...

On Wednesday 23 November 2011, Ludwig Nussel wrote:

...

...

That tells systemd to clear files older than 10 resp 30 days in those directories. systemd does not honor TMP_DIRS_TO_CLEAR.

If this is really the default now then it should have been a major point on ReleaseNotes.

really ? since when it is a major point that the system actually deletes temporary files as it should ?

The point whether it makes sense to store data on /var/tmp has been discussed endless already in this thread... Why not deleting /tmp every nanosecond per default? I have actively configured all our Desktop machines exactly following the openSUSE documented way how and when to delete my /tmp every reboot and every 60 days and deleting /var/tmp after 300 days but not on reboot. If something else happens then it's a bug. Again about /var/tmp use case: Our users know about our setup and they are politely requested to use /var/tmp for their data if no backup is needed, if they need speed (fast local storage) and if they don't need it shared (NFS). This helps me to safe expense /home and backup storage and safes load on NFS for the more important data. My users usually run data mining stuff producing x TB of data to be used just one time if calculation is finished after some weeks. In case their data would be deleted at random dates then they could restart their process to wait another few weeks. But before doing this they would probably kill me. And yes, backuping all this data would be more expensive than waiting again some weeks to reproduce it. Moreover it would not even possible to backup it in real time. And last but not least backuping this data would probably useless because some of their processes simply can't be continued and has to be re-done completely. This use case perfectly matches to what /var/tmp is supposed to be.

The good thing is that systemd allows to use a private,unshared /tmp namespace that daemons can use so this whole story can finally be put to an end.

My users are no daemons. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Nov 23, 2011 at 11:30 AM, Anders Johansson wrote:

On Wednesday 23 November 2011 13:22:55 Cristian Rodríguez wrote:

...

The good thing is that systemd allows to use a private,unshared /tmp

You mean unlike that evil sysV init, that completely blocked daemons from using $TMP?

Any application that does not respect $TMP is simply broken. This includes systemd

Oh, like KDE? KDE ignores $TMP, $TMPDIR. You have to use KDETMPDIR or something. -- Jon -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2011-11-23 at 10:28 +0100, Graham Anderson wrote:

On Monday 21 Nov 2011 23:41:02 Carlos E. R. wrote:

...

The system is not the exclusive owner of temporary space. People can use it for temporary purposes of their own. The system is free to erase the temporary files it creates, but not the temporary files created by others - unless the admin explicitly says otherwise.

The problem is that the system is unable to keep track of its own temporary files, so it erases all. That must be the decision of the admin, not of the system, ie, the packagers.

No. *People* can, and should, put their own temporary data elsewhere.

Where is that mandated?

As you correctly observe the system cannot keep track of all system, service & daemon generated temporary files, so it *must* periodically remove _all_ of

No. Only if the admin says so, and in the manner he says so. And openSUSE defaults to respect this, no temporary files are erased. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7NsC0ACgkQtTMYHG2NR9V3yACgkzxGpp3xcjgpQRpPWDK5XY3V JMQAnieqqY2m3L65oUWYCDUPwWOqMY4z =ESjl -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Graham Anderson writes:

On Monday 21 Nov 2011 23:41:02 Carlos E. R. wrote:

...

On Monday, 2011-11-21 at 14:14 -0500, Brian K. White wrote:

...

You do know that tmp stands for "temporary" right? That's pretty much the end of the conversation right there, regardless if that dir ever used to be cleaned automatically or not.

The system is not the exclusive owner of temporary space. People can use it for temporary purposes of their own. The system is free to erase the temporary files it creates, but not the temporary files created by others - unless the admin explicitly says otherwise.

The problem is that the system is unable to keep track of its own temporary files, so it erases all. That must be the decision of the admin, not of the system, ie, the packagers.

No. *People* can, and should, put their own temporary data elsewhere.

People *can* put their data elsewhere but they should *not*, or so, is what my admin tells me :) And neither posix nor FHS suggest otherwise.

As you correctly observe the system cannot keep track of all system, service & daemon generated temporary files, so it *must* periodically remove _all_ of the data within to ensure the system stays usable. For this reason alone system temporary directories are an entirely unsuitable location for either users or admins to manually place *anything*.

While `the system' (I assume file system here) doesn't keep track of *why* I put my files there, it certainly keeps track of who did it as per file states, stat(1). Why would any daemon not running in my name produce files in $TMPDIR and friends that belong to me? And any daemon that does run in my name and offloads stuff in $TMPDIR is not the business of some system magic. If dcop fails to clean up after itself (or take any program for that matter) fix that, and don't try to fix the user/admin.

Losing data from a system tmp dir is 100% the fault of the user/admin that placed it there.

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

On Wed, Nov 23, 2011 at 03:46:33PM +0100, Ludwig Nussel wrote:

Melchior FRANZ wrote:

...

Apparently, 12.1 has added /var/tmp/ to TMP_DIRS_TO_CLEAR in /etc/sysconfig/cron. I was quite surprised when I found out today that I've lost a few GB of data, which used to be safe there.

$ tail -2 /usr/lib/tmpfiles.d/tmp.conf d /tmp 1777 root root 10d d /var/tmp 1777 root root 30d

That tells systemd to clear files older than 10 resp 30 days in those directories. systemd does not honor TMP_DIRS_TO_CLEAR.

Wait a minute. I just checked on my system upgraded from 11.4 and on my system /usr/lib/tmpfiles.d/tmp.conf also contains these entries. In /etc/sysconfig/cron I have forbidden cleans of /tmp (set to 0 days) and /var/tmp (long tmp is unset). Does the above mean that although I have no .rpmsave or .rpmnew files and no entry in the release notes, the contents of both diretories will be "cleaned up" despite my explicit command to leave them alone? If so, I think an urgent warning need to be issued and the bug should be fixed as quickly as possible. Ciao Joerg -- Joerg Mayer We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Le samedi 19 novembre 2011 à 15:49 +0100, Anders Johansson a écrit :

On Saturday 19 November 2011 15:42:30 Carlos E. R. wrote:

...

On Saturday, 2011-11-19 at 15:18 +0100, Anders Johansson wrote:

...

However, I can't see that this is the case on my system. The default setting is /tmp only, and I can't immediately see anything in YaST that would add /var/tmp to it

# This variable contains a list of directories, in which old files are to # be searched and deleted. The frequency is determined by MAX_DAYS_IN_LONG_TMP # If cleaning of /var/tmp is wanted add it here. # LONG_TMP_DIRS_TO_CLEAR=""

I know, but it is empty by default, and files in my /var/tmp aren't getting deleted on my 12.1

There is one bug I've just been informed where /etc/init.d/boot.cleanup is now replaced by systemd equivalent, which is not doing exactly the same things as the old script. I'll see how I can fix this (see https://bugzilla.novell.com/show_bug.cgi?id=721682 ) -- Frederic Crozat SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Melchior FRANZ [11-28-11 08:40]:

On Monday 28 November 2011 13:55:47 Frederic Crozat wrote:

...

There is one bug I've just been informed where /etc/init.d/boot.cleanup is now replaced by systemd equivalent, which is not doing exactly the same things as the old script.

...

[...] https://bugzilla.novell.com/show_bug.cgi?id=721682

Ahh, interesting. Then it *was* an opensuse bug which killed a few GB of my data. Just checked and I've got the "no" there, while the cron mechanism was disabled as well:

MAX_DAYS_IN_TMP="" TMP_DIRS_TO_CLEAR="/tmp /var/tmp" CLEAR_TMP_DIRS_AT_BOOTUP="no"

No, you didn't read/understand the bug-report. It was about files not being cleared, *not* about files being cleared disreguarding settings. It is an openSUSE bug but not related to your loss. -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Ludwig Nussel writes:

Melchior FRANZ wrote:

...

Apparently, 12.1 has added /var/tmp/ to TMP_DIRS_TO_CLEAR in /etc/sysconfig/cron. I was quite surprised when I found out today that I've lost a few GB of data, which used to be safe there.

$ tail -2 /usr/lib/tmpfiles.d/tmp.conf d /tmp 1777 root root 10d d /var/tmp 1777 root root 30d

That tells systemd to clear files older than 10 resp 30 days in those directories. systemd does not honor TMP_DIRS_TO_CLEAR.

I'm going to add this to the release notes: https://bugzilla.novell.com/show_bug.cgi?id=735027. The behavior per se is ok, but in the update case, when it does not honor old settings, I consider it as a bug. Are there plans to fix this? And, of course, it would have been a bug, if default sysv/sysconfig and systemd related settings would differ... Do we plan to remove these variables from /etc/sysconfig/cron or will we propagate the values from sysconfig to /usr/lib/tmpfiles.d/tmp.conf? -- Karl Eichwalder SUSE LINUX Products GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 06 December 2011, Karl Eichwalder wrote:

Ludwig Nussel writes:

...

Melchior FRANZ wrote:

...

Apparently, 12.1 has added /var/tmp/ to TMP_DIRS_TO_CLEAR in /etc/sysconfig/cron. I was quite surprised when I found out today that I've lost a few GB of data, which used to be safe there.

$ tail -2 /usr/lib/tmpfiles.d/tmp.conf d /tmp 1777 root root 10d d /var/tmp 1777 root root 30d

That tells systemd to clear files older than 10 resp 30 days in those directories. systemd does not honor TMP_DIRS_TO_CLEAR.

I'm going to add this to the release notes: https://bugzilla.novell.com/show_bug.cgi?id=735027.

Note that /usr/lib/tmpfiles.d/*.conf contains systemd's default config only (should not be edited). Users can change it in /etc/tmpfiles.d/*.conf but AFAIR this direcectory does not exist per default yet. see man tmpfiles.d

The behavior per se is ok, but in the update case, when it does not honor old settings, I consider it as a bug. Are there plans to fix this?

And, of course, it would have been a bug, if default sysv/sysconfig and systemd related settings would differ...

If possible I would fix it in 12.1 by adding /etc/tmpfiles.d/* which does nothing else than avoiding conflicts between /etc/sysconfig/cron and /usr/lib/tmpfiles.d/*.conf.

Do we plan to remove these variables from /etc/sysconfig/cron or will we propagate the values from sysconfig to /usr/lib/tmpfiles.d/tmp.conf?

As said in 12.1 it has to be fixed. In Factory I would simply drop the idea of having interchangable sysvinit and systemd. Users should know that using systemd or sysvinit results in completely different behavior. By considering this statement packagers could use systemd features without thinking about sysvinit. Playing around systemd should IMO not affect sysvinit and vice versa. For this particular case it would mean that using systemd should use /etc/tmpfiles.d/*.conf and sysvinit uses /etc/sysconfig/cron only. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 06 December 2011, Karl Eichwalder wrote:

Ruediger Meier writes:

...

In Factory I would simply drop the idea of having interchangable sysvinit and systemd. Users should know that using systemd or sysvinit results in completely different behavior. By considering this statement packagers could use systemd features without thinking about sysvinit. Playing around systemd should IMO not affect sysvinit and vice versa. For this particular case it would mean that using systemd should use /etc/tmpfiles.d/*.conf and sysvinit uses /etc/sysconfig/cron only.

Yes, but this would not save us from re-writing the docs on the variables in /etc/sysconfig/cron. The statements there are just too broad. At least, we must add warnings that sysconfig settings are not valid for systemd.

My idea is to have really distinct systemd and sysvinit installations. If you have systemd installed then there would be only /etc/tmpfiles.d/* and no more /etc/sysconfig/cron and vice versa. If a user wants to change from systemd to sysvinit then there could be a script which converts different config files (Or just a warning that you will get a totally different behaving system using a lot different config files). This implies that you can't switch between systemd and sysvinit at boot time. IMO mixing systemd and sysvinit like done in 12.1 is very bad thing. The reason why this was done is probably to have a working fallback from systemd. But sysvinit can't be a working fallback if it depends on systemd. Moreover leaving both systemd and sysvinit users with many invalid documentation and unused/redundant config files and incomplete ReleaseNotes about major changes was even worse. BTW on this list I've read dozens of times something like "you should learn to do systemd stuff natively". I think this applies also when you end up with non-booting system(d)s: "you should learn to repair systemd rather than expecting a sysvinit fallback". cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 06/12/11 11:43, Ruediger Meier wrote:

IMO mixing systemd and sysvinit like done in 12.1 is very bad thing. The reason why this was done is probably to have a working fallback from systemd.

Well, yeah, it is in transition mode, maintaining 2 separate init systems is a royal pain in the ass, something that no-ones wants to do, at some point sysvinit will go away,hopefully in 1 or 2 release cycles. Work is being done now to migrate the remaining legacy init scripts to reach a point when we cleanly switch. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Le mardi 06 décembre 2011 à 12:28 -0300, Cristian Rodríguez a écrit :

On 06/12/11 11:43, Ruediger Meier wrote:

...

IMO mixing systemd and sysvinit like done in 12.1 is very bad thing. The reason why this was done is probably to have a working fallback from systemd.

Well, yeah, it is in transition mode, maintaining 2 separate init systems is a royal pain in the ass, something that no-ones wants to do, at some point sysvinit will go away,hopefully in 1 or 2 release cycles.

Work is being done now to migrate the remaining legacy init scripts to reach a point when we cleanly switch.

Sidenote : we don't need to migrate sysv services to systemd unit files to "drop" sysvinit as an init system, since systemd handles sysv services correctly.. -- Frederic Crozat SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 06 December 2011, Cristian Rodríguez wrote:

On 06/12/11 11:43, Ruediger Meier wrote:

...

IMO mixing systemd and sysvinit like done in 12.1 is very bad thing. The reason why this was done is probably to have a working fallback from systemd.

Well, yeah, it is in transition mode, maintaining 2 separate init systems is a royal pain in the ass, something that no-ones wants to do,

Yup but maintaining both _plus_ keeping both behavior in sync is even more pain and not even possible as you see in 12.1.

at some point sysvinit will go away,hopefully in 1 or 2 release cycles.

Decoupling sysvinit and systemd would make it possible to let users and packagers decide what they want to maintain/use. Improving systemd support should not affect current sysvinit support. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 06/12/11 14:05, Michal Kubeček wrote:

On Tuesday 06 of December 2011 12:28EN, Cristian Rodríguez wrote:

...

at some point sysvinit will go away,hopefully in 1 or 2 release cycles.

When was this decision made and who decided it? I hope it's still not too late to reconsider it.

It has not been decided, but Im pretty sure we cannot maintain 2 init systems for a long time.. IMHO it could remain in the repos, as unsupported "at your own risk" and not installed by default for some time. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 06/12/11 14:46, Lars Müller wrote:

systemd recently got a feature named 'Journal'. See https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUE...

I hope this will address the missing feature.

Yep, the "journal" which does binary logging only (let the flames begin!!) will likely address this problem. ;) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 07.12.2011 09:24, schrieb Peter Nikolic:

plain text log files please ..

So that attackers can easily mangle them. Yeah, good idea! ;-) -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 07/12/11 05:24, Peter Nikolic wrote:

plain text log files please ..

Plain old syslog is not going anywhere, can still be used for traditional logging, you have rsyslog, syslog-ng, etc to choose from. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 07/12/11 13:13, Peter Nikolic wrote:

Well should not be so wide open to them then simple

That's not possible... any process can claim to be $yourfavoritesoftware. there is no authentication nor access control, by design. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 07/12/11 14:08, Ruediger Meier wrote:

On Wednesday 07 December 2011, Cristian Rodríguez wrote:

...

On 07/12/11 13:13, Peter Nikolic wrote:

...

Well should not be so wide open to them then simple

That's not possible... any process can claim to be $yourfavoritesoftware. there is no authentication nor access control, by design.

? They were talking about reading log files.

No, stefan replied saying that logs files can be manipulated by attackers, particulary writting fake syslog messages. If you have an idea on how to make the messages authenticated, have access control, metadata, a single structure, all of that suitable for servers that log lots of stuff per second in a plain text file, without breaking already existent syslog implementations and tools ..bring it on. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 07.12.2011 19:21, Cristian Rodríguez wrote:

On 07/12/11 14:08, Ruediger Meier wrote:

...

On Wednesday 07 December 2011, Cristian Rodríguez wrote:

...

On 07/12/11 13:13, Peter Nikolic wrote:

...

Well should not be so wide open to them then simple

That's not possible... any process can claim to be $yourfavoritesoftware. there is no authentication nor access control, by design.

? They were talking about reading log files.

No, stefan replied saying that logs files can be manipulated by attackers, particulary writting fake syslog messages.

If you have an idea on how to make the messages authenticated, have access control, metadata, a single structure, all of that suitable for servers that log lots of stuff per second in a plain text file, without breaking already existent syslog implementations and tools ..bring it on.

I remember having played with setting some log files "append only" to protect them. long ago. That way they can not be modified, just writing to the end of file is permitted. I also then remember using lcap to remove the ability to change the append-only flag, CAP_LINUX_IMMUTABLE and ability to do raw I/O. I faintly remember having some problems that made me stop the experiment. I thing at least logrotate didn't work and there may have been some other stuff. Anyways, the intention was to make it impossible for the intruder to change logs. I'm sure it can be done... Vahis -- http://waxborg.servepics.com openSUSE 11.4 (x86_64) 2.6.37.6-0.9-default main host openSUSE 12.1 (x86_64) 3.1.1-48-desktop Tumbleweed in VirtualBox openSUSE 12.1 (i586) 3.1.0-1.2-desktop in EeePC 900 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday, December 07, 2011 08:24:06 AM Peter Nikolic wrote:

plain text log files please ..

I liked that argument and repeated it a lot, but what means plain text. Log is not paper copy, which requires only eyes to read it. It is long string of characters written as one or more strings on a hard disk using file system. There is nothing to see if you don't have running a pile of software starting with kernel and ending with text editor. Even with all that you have to know meaning of fields to be able to understand each line. Then when you understand each line you need other software that will collect data from multiple lines spread accross log file, to actually understand what is going on. Having specialized editor for log files can only improve our ability to make use of logs, and then "text only" makes no more sense, as it is just inefficient way to store and later parse event data. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sunday, December 25, 2011 08:31:18 AM Peter Nikolic wrote:

On Sunday 25 December 2011 04:46:49 Rajko M. wrote:

...

On Wednesday, December 07, 2011 08:24:06 AM Peter Nikolic wrote:

...

plain text log files please ..

I liked that argument and repeated it a lot, but what means plain text.

Ok lets try another way round that then shall we hows about Human Readable not containing any of the upper 128 Chars of the Character set .

No it is not. Human readbale is what you can see with your eyes, not with a help of the computer programs; just as stated in previous email:

...

Log is not paper copy, which requires only eyes to read it.

If you need text editor, bash and kernel to read something, then what is the difference to use specialized, a little bit more complicated editor that will output text that you can read, but that text will be stored in way that is convenient for computer to handle it, and it take lesser space on a disk. What you loose? 1) Ability to use primitive interface between you and logs that have to be huge just to satisfy that primitive interface. 2) Need to learn log file format. 3) Need to compress log every now and then with logrotate. 4) Need to expand logs when you want to read archived copies created with logrotate. What you gain? 1) Ability to store more information in the same space. 2) Ability to write and read logs faster then before. 3) Ability to scan for events faster then before. ...

Nope just plain old boring no special tools text please the only way lets get away from this darn windowsisation of Linux and head back to a more friendly way of life

"Darn windowization" :) Ideologists are in general detached from reality. There are good and bad ways get work done with huge gray zone between them. Is it forbidden to go forward, use better way to do a job, just because it resembles on some other (proprietary) solutions?

Pete . -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 12/26/2011 1:00 AM, Rajko M. wrote:

On Sunday, December 25, 2011 08:31:18 AM Peter Nikolic wrote:

...

On Sunday 25 December 2011 04:46:49 Rajko M. wrote:

...

On Wednesday, December 07, 2011 08:24:06 AM Peter Nikolic wrote:

...

plain text log files please ..

I liked that argument and repeated it a lot, but what means plain text.

Ok lets try another way round that then shall we hows about Human Readable not containing any of the upper 128 Chars of the Character set .

No it is not. Human readbale is what you can see with your eyes, not with a help of the computer programs; just as stated in previous email:

...

...

Log is not paper copy, which requires only eyes to read it.

If you need text editor, bash and kernel to read something, then what is the difference to use specialized, a little bit more complicated editor that will output text that you can read, but that text will be stored in way that is convenient for computer to handle it, and it take lesser space on a disk.

What you loose? 1) Ability to use primitive interface between you and logs that have to be huge just to satisfy that primitive interface. 2) Need to learn log file format. 3) Need to compress log every now and then with logrotate. 4) Need to expand logs when you want to read archived copies created with logrotate.

What you gain? 1) Ability to store more information in the same space. 2) Ability to write and read logs faster then before. 3) Ability to scan for events faster then before.

...

...

Nope just plain old boring no special tools text please the only way lets get away from this darn windowsisation of Linux and head back to a more friendly way of life

"Darn windowization" :) Ideologists are in general detached from reality. There are good and bad ways get work done with huge gray zone between them. Is it forbidden to go forward, use better way to do a job, just because it resembles on some other (proprietary) solutions?

...

Pete .

logs are a thing that need to be acessible in minimalist and/or emergency situations. When a device or server is having a problem, that is not the time you want your diagnostic ability to rely on special tools that might not be available for any number of reasons. - not present on special boot image - broken library dependency - broken file format compatibility - not applicable for redirecting to special consoles, (serial, parallel, net, custom logger/watchdog script, custom loger/watchdog hardware, that might not be modifiable enough to build and install special binary log reader) Sure there are advantages to logging to a database. And they are conveniences that make the "everything is fine" case better at the expense of making the "everything is not fine" worse. The "everything is not fine" case comes along less frequently, but it _always_ comes along, and when it does, it's already bad enough without the complication of your diagnostic tools maybe suspect. On that day, you do not give a tenth of a rats crap for "increased efficiency" of being able to query logs from a db. Being able to sed/grep/awk etc from the file is valuable, and being able to read it directly with anything, even lowly cat or dd, let alone any of a bezillion editors/viewers that already exist everywhere on all platforms all cpus all versions since long before even the damned time_t epoch. Unless the format is human readable, then how do you really know that when you query it and get nothing, that it was really beacause nothing was there that matched and not merely that your human inscrutable special tool didn't simply fail to read the human inscrutable special file in some way? shells, editors, sed/awk/grep/perl etc do not suffer the same impossible burden of garanteeing to always work perfectly, because you can always look at a file directly using an uncountable number of other tools if any one is suspect. there are countless shells, cats dds vis etc... if I run some grep command on a text file and suspect the results, i can simply vi it or cat it or echo it through th shell itself, all 4 utils will not be broken at the same time and my eyes will not be subject to failure due to mere unexpected formatting. You can't demand "what situation will occur that you won't be able to use the log reader util? ". That is backwards thinking that leads to garbage non robust systems. You can't predict specific problems, or predict the impossibility of them. You can only design things so that, as much as possible, you avoid the _possibility_ of being without the ability to access something as important as syslog and dmesg, or fail to, and allow that possibility. "liklihood" isn't the important factor here. possible vs not-possible is. Even if you built the special log reader right into the kernel itself so it can't ever not be available & compatible, that still doesn't help all the examples of logging to devices that expect simple text. You want more efficient access to log data under normal circumstances? Feel free to _copy_ it to the db of your choice. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday 26 December 2011 06:41:01 Claudio Freire wrote:

I feel I'm missing part of the thread. But anyway, I can recognize this as a discussion about the binary log, so let's hack at it:

On Mon, Dec 26, 2011 at 3:00 AM, Rajko M. wrote:

...

What you loose? 1) Ability to use primitive interface between you and logs that have to be huge just to satisfy that primitive interface.

You're forgetting the ability to use the extensive text analysis tools already present in linux: grep, sed, etc, etc.

...

2) Need to learn log file format.

That's not an issue with syslog, which has/can use standardized formats. [0]

...

3) Need to compress log every now and then with logrotate.

Don't kid yourself: binary logs will need compression just as well.

...

4) Need to expand logs when you want to read archived copies created with logrotate.

Already lots of tools for this. vim can read it just like that, with on-the-fly decompression. You also have zless, zgrep, etc...

And you don't loose the need, with binary logs, you'll need to expand them just as well (ie: use a tool to parse the binary data and present it in human readable terms) [1]

...

What you gain? 1) Ability to store more information in the same space.

False. You can store all that information ascii-encoded. Say, you can store binary blobs if you need to - just store them in hex/base64. You usually don't need to, that's why all logs store readable text.

...

2) Ability to write and read logs faster then before.

Speed is not an issue. I've processed gigabytes of text logs quickly enough when doing forensics.

...

3) Ability to scan for events faster then before.

I doubt this point. If you mean processing speed, see 2. If you mean actually reading the log is faster, you're mistaken. Humans never read logs line by line, except when they're really small, and then this point would be moot anyway. For big logs, you analyze them with log analysis tools. Those can work equally well with binary or text logs. Just a matter of format, not content.

Granted, standardization (either in binary or text form) helps a lot here.

[0] what people is actually after is standardization. I theorize that the whole point about this binary logging fuzz is forcing standardization. Binary logs leave no option than to standardize. But they also bring tons of inconveniences. A more directed effort would focus on standardized and complete logging formats (ie: standard across distributions and apps, while containing all the information that might be required, and perhaps the possibility to add extra information fields if needed)

[1] human readable is not about character set, it's about words. Human readable means an alphanumeric representation that can be easily understood by a human without software aids (other than display).

Thanks Claudio very well put Pete . -- Powered by openSUSE 11.3 (x86_64) Kernel: 2.6.34.10-0.4-desktop KDE Development Platform: 4.6.5 (4.6.5) "release 7" 09:35 up 9:18, 4 users, load average: 0.94, 0.98, 0.76 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 26.12.2011 07:41, schrieb Claudio Freire:

...

2) Ability to write and read logs faster then before. Speed is not an issue. I've processed gigabytes of text logs quickly enough when doing forensics.

If you've really ever done real forensics, you'd probably value signed tamper-proof log entries.

[1] human readable is not about character set, it's about words. Human readable means an alphanumeric representation that can be easily understood by a human without software aids (other than display).

I really want to see someone read /var/log/messages without software aid. I cannot. And there is no reason why "less" will not gain the ability to read journal entries, just like it is able to read messages.gz. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stefan Seyfried writes:

Am 26.12.2011 07:41, schrieb Claudio Freire:

...

...

2) Ability to write and read logs faster then before. Speed is not an issue. I've processed gigabytes of text logs quickly enough when doing forensics.

If you've really ever done real forensics, you'd probably value signed tamper-proof log entries.

That just proves that you've never done forensics. Relying on tamper-proofness is a bad idea. The whole feature is a typical thing some people seem to assume that everyone needs. I imagine the reader software will be designed to detect such `tampering' and invalidate it one way or the other. Just imagine a dying disk flipping bits at random with a probability of X. At some point either the signature will be invalid, or the data. Having discarded valuable redundancy by using a binary format, how do you detect the validity and how do you cope with situations like these?

...

[1] human readable is not about character set, it's about words. Human readable means an alphanumeric representation that can be easily understood by a human without software aids (other than display).

I really want to see someone read /var/log/messages without software aid. I cannot.

And there is no reason why "less" will not gain the ability to read journal entries, just like it is able to read messages.gz.

I don't want to depend on that particular less feature, at least not in real-life stress situations. It pains me to see that some people seem to scale their experience with 2 or 3 computers to a farm of 10000+ computers. It's a LOT different. Let's not forget this is new territory for anyone that hasn't done a similar migration (for the better or worse) in the past, promises mean nothing, *experience* is what counts. I could bore you all with stories about a similar movements in the financial industry (it was more about latency and parsing speed rather than tamper safety, etc.). But the fact is that the plain text standard FIX is still by far the most wide-spread despite several attempts to binarify it. I can't help but see similarities between the discussions back then and now. Sebastian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Dec 26, 2011 at 12:00 PM, Stefan Seyfried wrote:

Am 26.12.2011 07:41, schrieb Claudio Freire:

...

...

2) Ability to write and read logs faster then before. Speed is not an issue. I've processed gigabytes of text logs quickly enough when doing forensics.

If you've really ever done real forensics, you'd probably value signed tamper-proof log entries.

Yes, I do. But that can be done with text too. Ever heared of GPG ASCII armor? (I do cryptography and security too, before anyone questions my competence on the field)

...

[1] human readable is not about character set, it's about words. Human readable means an alphanumeric representation that can be easily understood by a human without software aids (other than display).

I really want to see someone read /var/log/messages without software aid. I cannot.

Never did myself. I always grep for quick insight. Can you grep binary logs? [0]

And there is no reason why "less" will not gain the ability to read journal entries, just like it is able to read messages.gz.

Will sed too? Will tail? Will all the other text tools? [0] There's no denying that text processing tools far outnumber journal processing tools. Remember, it all started when some guy wrote a set of text processing tools for IBM. And that it would be dreaming in colors to expect all those tools to be "upgraded" to work with journal files. Mostly because it's indeed outside the scope of those tools. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stefan Seyfried writes: [snip]

...

Let's not forget this is new territory for anyone that hasn't done a similar migration (for the better or worse) in the past, promises mean nothing, *experience* is what counts.

So you surely have filed lots of bugzilla entries about all that bad experience?

It is pretty rude assuming that the guys who are actually volunteering to do parts the work (Cristian is) will certainly screw up.

If I'm looking at Cristians track record regarding openSUSE, I am willing to give him some credit and I assume that he will not screw this up.

Yes I have reported the bugs that most concern me. And none of them got fixed. Great track record. I'm not whole-heartedly discussing this anymore because I decided against opensuse and SLES. Sebastian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Dec 26, 2011 at 10:00 AM, Stefan Seyfried wrote:

...

...

2) Ability to write and read logs faster then before. Speed is not an issue. I've processed gigabytes of text logs quickly enough when doing forensics.

If you've really ever done real forensics, you'd probably value signed tamper-proof log entries.

I have done the work and definitely would love signed tamper-proof logs. I have reviewed FTP, Webserver, and SMTP logs for legal reasons. It complicates life not knowing if those logs can be truly trusted as really having been originated by the daemon in question. Note that it is too late by the time the investigation starts. The underlying logging needs to be tamper resistant from prior to the incident under investigation. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 26/12/11 03:41, Claudio Freire wrote:

...

3) Need to compress log every now and then with logrotate. Don't kid yourself: binary logs will need compression just as well.

the journal supports inline compression,in ONE format, LZMA, the sane, logical choice. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 12/26/2011 3:34 PM, Cristian Rodríguez wrote:

On 26/12/11 03:41, Claudio Freire wrote:

...

...

3) Need to compress log every now and then with logrotate. Don't kid yourself: binary logs will need compression just as well.

the journal supports inline compression,in ONE format, LZMA, the sane, logical choice.

Oh my god you get funnier every post! "foo-of-the-day is the bestest foo evaarrrr the only sane foo to use evarrrrr!" -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 26/12/11 17:47, Brian K. White wrote:

sane foo to use evarrrrr!"

It is the best format currently available, technology may change in the future and proper adaptations may be done accordingly. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 26.12.2011 22:15, schrieb Anders Johansson:

Isn't it true that with any compression format, any mistake anywhere will invalidate the decoding of all subsequent data, making it totally unreadable?

No, that isn't true. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday 26 December 2011 22:42:17 Stefan Seyfried wrote:

Am 26.12.2011 22:15, schrieb Anders Johansson:

...

Isn't it true that with any compression format, any mistake anywhere will invalidate the decoding of all subsequent data, making it totally unreadable? No, that isn't true.

Really? I'm not aware of any codecs that can handle data corruption, except for a few that have been developed for usenet that involve massive redundancy. Could you give an example? Anders -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday 26 December 2011 18:50:56 Claudio Freire wrote:

On Mon, Dec 26, 2011 at 6:47 PM, Anders Johansson wrote:

...

Really? I'm not aware of any codecs that can handle data corruption, except for a few that have been developed for usenet that involve massive redundancy.

Could you give an example?

bzip2.

You can loose blocks, but that only looses you a block, all blocks in bzip2 are independent.

So you loose only a portion of compressed data.

Interesting, I didn't know that. I knew the algorithm broke on corruption, I didn't know they do a keyframe setup to get around it. I see the default block size is 900K, that's a huge chunk of log gone

For lzma, I think (not as sure as with bzip2) blocks exist just as well, only in a different form.

Good question. The bzip2 man page discusses it, but lzma/xz man pages don't. Still, it's not a feature of the algorithm itself. The algorithms fail completely on corrupt data. The important bit is how it's implemented in a tool. Maybe compress line by line? Anders -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 12/26/2011 4:45 PM, Claudio Freire wrote:

On Mon, Dec 26, 2011 at 5:22 PM, Greg Freemyer wrote:

...

On Mon, Dec 26, 2011 at 10:00 AM, Stefan Seyfried wrote:

...

...

...

2) Ability to write and read logs faster then before. Speed is not an issue. I've processed gigabytes of text logs quickly enough when doing forensics.

If you've really ever done real forensics, you'd probably value signed tamper-proof log entries.

I have done the work and definitely would love signed tamper-proof logs.

I have reviewed FTP, Webserver, and SMTP logs for legal reasons. It complicates life not knowing if those logs can be truly trusted as really having been originated by the daemon in question.

Note that it is too late by the time the investigation starts. The underlying logging needs to be tamper resistant from prior to the incident under investigation.

That will never happen. In order to sign entries, the logging daemon needs to have the keys.

The task can be made very difficult, but the jist is, if the daemon can have access to the signing keys, so does an attacker that compromises the daemon.

So, it cannot be made provably secure for legal purposes. But it *can* be made difficult for most attackers, a good yet not infalible protection for practical purposes.

Or, it may just be a great way to allow people in power to delude themselves longer. Things stay hacked longer because idiots believe the logs "prove" they have not been hacked. People go to jail because the logs "prove" they did something. People don't go to jail because the logs "prove" they didn't do something. Idiots in positions of authority routinely mis-use the tools to everyone's harm, and new admins routinely over-trust claims of quality/effectiveness. Remember http://news.ycombinator.com/item?id=3088687 ? They were convinced everything the they saw from their end must be true. At least no one can expect that a plain file can really prove anything by itself. I am intrigued by the idea of utterly trustworthy logs but I don't think they can really exist as easily as that. So again it's just a bad trade. You lose compatibility and flexibility, and gain essentially nothing. This is an example of "progress often isn't". Someone get's an idea, and since they're new they think it's a fine idea, and since all the rest of their generation are just as new they also all think it's a fine idea. Doesn't make it a fine idea. 10 or 15 years after AOL and Microsoft put the internet and email into the hands of the unwashed masses, a research paper came out that "discovered" what the cranky old timers who suddenly comprised only .001% of the internet had been saying since day one to the other 99.99% about the wasted time and effort and increased miscommunications from top-posting. It was very funny reading them "discover" this. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 26/12/11 19:29, Anders Johansson wrote: The important bit is how it's implemented in a

tool. Maybe compress line by line?

That's what it does, according to my understanding, note that we are talking about unrelased software :-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 26/12/11 23:32, Claudio Freire wrote:

On Mon, Dec 26, 2011 at 9:27 PM, Cristian Rodríguez wrote:

...

On 26/12/11 18:45, Claudio Freire wrote:

...

In order to sign entries, the logging daemon needs to have the keys.

There are no keys...looks like nobody has bothered to read anything at all. :-|

It uses chained hashes. Keyed or not, don't remember.

If they're not keyed, anyone can falsify records, they only have to rewrite all hashes.

"in the journal all entries are cryptographically hashed along with the hash of the previous entry in the file. This results in a chain of entries, where each entry authenticates all previous ones. If the top-most hash is regularly saved to a secure write-once location, the full chain is authenticated by it." So tampering any entry will cause a mismatch that can be easily detected, the attacker would have to rewrite the _whole_ content of the history of a particular user (journald stores 1 log for each system user) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 27/12/11 00:35, Claudio Freire wrote:

Usually, you just want to fake or delete the last few records. Deleting is quite simple.

Sure, nothing blocks an attacker that has gained root access to simple rm -rf /var/log/journal/foo.journal

Altering the latest records too, since they haven't yet been backed up.

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

On 27/12/11 01:51, Claudio Freire wrote:

Inject and run a program that does the alteration.

Without being noticed ? defeating tamper-evident Merkle trees ?

Or in any other way drop an egg shell that does that.

Possibilities are quite varied.

Yeah, I can also throw the box into a lake of fire.. :-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 27.12.2011 03:32, schrieb Claudio Freire:

It uses chained hashes. Keyed or not, don't remember.

If they're not keyed, anyone can falsify records, they only have to rewrite all hashes.

Exactly like they can easily insert a commit into a git repo and nobody will ever notice? -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday 26 December 2011 21:15:32 Anders Johansson wrote:

On Monday 26 December 2011 17:34:13 Cristian

=?ISO-8859-1?Q?Rodr=EDguez?= wrote:

...

On 26/12/11 03:41, Claudio Freire wrote:

...

...

3) Need to compress log every now and then with logrotate.

Don't kid yourself: binary logs will need compression just as well.

the journal supports inline compression,in ONE format, LZMA, the sane, logical choice.

Isn't it true that with any compression format, any mistake anywhere will invalidate the decoding of all subsequent data, making it totally unreadable?

The only way to avoid that is through redundancy, thus removing the benefits of compression in the first place.

Besides which, the whole notion of tamper proof logs is silly from the start - there is just no such thing. If I achieve root on a system, I have access to every single key used to cryptographically sign anything (no, there can't be passwords for autonomous daemons, at best the password has to be typed in on boot, but after that the key will be available in RAM for root to read).

And with the keys, I can generate any log you care to examine, and you won't be able to tell the difference.

Sure, you can get around it, by limiting what root can do, or logging to another system, or to hardware unchangeable output such as a printer, but then you can do that with any logging system.

Besides besides which, a new kind of logging system is hardly a valid argument in favour of ripping out the entire core infrastructure of the system.

Most arguments in favour of systemd talk about moving forward, but I have yet to see anyone say why it is considered forward. I don't see that we get anything we didn't already have. Fedora lacked infrastructure that they get with systemd, but we already had all of that. And if someone thinks this logging system is neat, take it out and build a replacement for syslog

I see systemd as a massive amount of work, that will net us exactly zero benefit in the end. It won't boot faster, it won't enable us to do anything new that we couldn't already do before, and we will have amassed a ton of bugs in the process.

I still propose that we drop systemd completely

Anders

+++11111 -- Powered by openSUSE 11.3 (x86_64) Kernel: 2.6.34.10-0.4-desktop KDE Development Platform: 4.6.5 (4.6.5) "release 7" 07:42 up 1 day 7:25, 4 users, load average: 0.10, 0.08, 0.09 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday 26 December 2011 20:31:21 Cristian Rodríguez wrote:

On 26/12/11 03:00, Rajko M. wrote:

...

"Darn windowization" :) Ideologists are in general detached from reality.

Indeed, dogma is not a way to move forward.

Well sorry to say then but you are so far removed it is untrue You are doing a good job of turning a good workable software system into something that no one will want ie just another version of windows and YES i will keep Harping on about it because you are so darn blinded by your ideals you are unable to see past the end of your nose .. Pete . -- Powered by openSUSE 11.3 (x86_64) Kernel: 2.6.34.10-0.4-desktop KDE Development Platform: 4.6.5 (4.6.5) "release 7" 07:58 up 1 day 7:41, 4 users, load average: 0.01, 0.02, 0.03 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Cristian Rodríguez writes: [snip]

...

I still propose that we drop systemd completely

That's sums up all arguments I have heard agaisnt systemd "I do not like it", "it much work", etc..googling sadly reveals zero reasonable technical arguments against it, all you see falls into the following categories (and I googled a lot. before jumping into this ship)

- Appeals to tradition --> we do things this way and works.

- ad hominems --> Lennart is an ass, blabla..

- ad portability --> it is not portable therefore sucks, that the most utter bullshit frecuently heard from the BSD crowd.

Portability in reality means "A whole bunch of code and ugly hacks to make it work in your obscure system" (just take a look at openssl in example)

- People that claim cgroups are ugly/broken, wrong choir !! that's something to complain to kernel developers.

- In general lack of understanding what systemd really does.

Interesting that any discussion always revolves back to systemd. Might I add another category: - Hordes of unfixed bugs, many of them so major no production environment with a risk manager will dare even try this thing in its current state. Sebastian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Sven Burmeister writes:

Am Dienstag, 27. Dezember 2011, 09:56:34 schrieb Sebastian Freundt:

...

...

- In general lack of understanding what systemd really does.

Interesting that any discussion always revolves back to systemd. Might I add another category:

- Hordes of unfixed bugs, many of them so major no production environment with a risk manager will dare even try this thing in its current state.

Cristian asked for bug numbers not polemic and useless statements.

Can't speak for other people, but here's the list of *my* reported/followed, still open bugs: On the novell bug tracker: 737547 automounter doesn't mount nfs shares 737553 rpc.idmapd not started automatically 737636 network is started then stopped right away 737690 systemd does not honour SIGPWR 738604 systemd corrupts disk and dumps core when ntp is started 737551 rpc_pipefs not mounted even though NFS_START_SERVICES="yes" and RPC_PIPEFS_DIR="/var/lib/nfs/rpc_pipefs" 737554 Boot output isn't directed to the console On the upstream tracker: 676856 In runlevel 1 (no network), it asks for NTP time, and hangs waiting for NTP service 698793 /home on NFS mounted partition 700825 Systemd automounts fail to handle connect/disconnect of network devices 713224 Hang during reboot - unable to umount partition 707731 Some partitions are mounted multiple times under certain conditions 719952 reboot or shutdown commands unresponsive during systemd-fsck 757463 NFS filesystems never unmounted, have to poweroff hard 758535 Restarting sshd kills current sessions 770471 systemd dumps core when ntp is started after fsck 759071 time is not correct after reboot If people were half as busy fixing those bugs as they are discussing the pros and cons, systemd might be a half-decent beta product already. Sebastian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Cristian Rodríguez writes:

On 27/12/11 09:57, Sebastian Freundt wrote:

...

Sven Burmeister writes:

...

Am Dienstag, 27. Dezember 2011, 09:56:34 schrieb Sebastian Freundt:

...

...

- In general lack of understanding what systemd really does.

Interesting that any discussion always revolves back to systemd. Might I add another category:

- Hordes of unfixed bugs, many of them so major no production environment with a risk manager will dare even try this thing in its current state.

Cristian asked for bug numbers not polemic and useless statements.

Can't speak for other people, but here's the list of *my* reported/followed, still open bugs:

On the novell bug tracker: 737547 automounter doesn't mount nfs shares 737553 rpc.idmapd not started automatically 737636 network is started then stopped right away 737690 systemd does not honour SIGPWR 738604 systemd corrupts disk and dumps core when ntp is started 737551 rpc_pipefs not mounted even though NFS_START_SERVICES="yes" and RPC_PIPEFS_DIR="/var/lib/nfs/rpc_pipefs" 737554 Boot output isn't directed to the console If people were half as busy fixing those bugs as they are discussing the pros and cons, systemd might be a half-decent beta product already.

what do you expect ? instant bug resolution ? the older bug of that list has been filled one week ago...

I think you have to check out your expectations.

I didn't address you. It's the same endless discussions on the fedora list, and in particular I meant the redhat bug tracker, there are open bugs dating back to 2010. In particular the UsePAM ssh issue and the fsck issues are still unfixed, as I've showed with my 738604. This is more than disappointing seeing as the system overall isn't that complex and redhat has 6 guys man-power. To me this clearly indicates poor design. Sebastian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Dec 27, 2011 at 11:26 AM, Cristian Rodríguez wrote:

To me it indicates that people have a lot of work and have to prioritize things that are really important or what their employer wants them to work in first.

Whatever it means, however old the bug reports are, they're serious bugs you don't want in production servers. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Dec 27, 2011 at 7:11 PM, Cristian Rodríguez wrote:

...

Git lives and dies on being decentral and pushed regularly to independent locations.

The journal will also support a network protocol that permits push and pull just like git.

This has not been implemented yet, though.

This may be my own limitation, but I cannot see how a log can be "distributed" (in the git sense). I mean, push, ok, like a streaming backup. Pull? I don't see that. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Mittwoch, 28. Dezember 2011, 02:33:56 schrieb Joachim Schrod:

I don't know what Sebastian expects -- I would have had expected an attitude that doesn't call for removal of sysvinit while there are such bugs, directly after a release that didn't even had a working postfix.

Are you sure there were never bugs in an openSUSE release that caused services not to start? According to your logic any of those would have indicated that systemv is utterly broken and must not be shipped as default. The RFC is for the next release. I do not see how starting it later would be any better regarding pointing out bugs and fixing them. In fact, if the testing of systemd would have got the attention from those complaining now at this stage and during the development cycle of the 12.1 release a lot more bugs would have been fixed already.

I also wouldn't have had expected an attitude that uses the question "where are the bug numbers?" to squash discussion, and then complains when there are bug numbers cited. Especially when the complaints include wrong assertions. (That Sebastian opened one of those bugs last week doesn't imply that all of his bugs are from last week.)

It does imply that if bugs are not reported they cannot get fixed. And it does imply that reporting bugs just before Christmas holidays will unlikely lead to them getting fixed within a week on the openSUSE part. Sounds reasonable to me.

But obviously, these expectations have been wrong.

Indeed, polemic emails lead to a more aggressive tone and thus nobody should have introduced any polemic statements or subjective comments but just bug numbers and issues in a neutral and objective and technical manner. An attitude that accuses somebody who is actually doing a lot of work on fixing bugs of having the wrong attitude seems questionable to me. Face it, systemv will be gone at some point and the only useful thing you can do to help is report and fix bugs. Endless discussions do not help improving anything. Sven -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday 28 of December 2011 09:27EN, Sven Burmeister wrote:

Face it, systemv will be gone at some point and ...

Once again: is this already decided? If yes, who decided it and when? If not, please don't write things like this as if it was a decision already made. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday 28 December 2011 09:58:48 Michal Kubeček wrote:

On Wednesday 28 of December 2011 09:27EN, Sven Burmeister wrote:

...

Face it, systemv will be gone at some point and ...

Once again: is this already decided? If yes, who decided it and when? If not, please don't write things like this as if it was a decision already made.

Michal Kubeček

I have to admit this is begining to look very like a case of self glorification for someone , Look i made them make the changes i want . And i for one am getting sick of it . Pete . -- Powered by openSUSE 11.3 (x86_64) Kernel: 2.6.34.10-0.4-desktop KDE Development Platform: 4.6.5 (4.6.5) "release 7" 14:33 up 2 days 14:16, 5 users, load average: 1.14, 1.21, 1.16 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

2011/12/28 Michal Kubeček :

...

I agree with the move. systemd goes forward in some areas.

I don't. So far, I haven't seen any (useful) feature that systemd would provide that couldn't be with much less effort achived without it. On the other hand, it brings a lot of problems and complicates things that used to be simple and easy. Some features aren't provided at all and when people point it out, the answer is "you shouldn't want them because systemd doesn't provide them". Saving (possibly) few seconds of boot time is not worth the trouble.

Well, if you don't read the whole post, yes, I can see how you would answer like that. I think just the same. But some stuff *is* a lot easier to maintain with systemd. There's no denying. The problem is its shortsightedness and its refusal to, as you say, implement the features system administrators need. So maybe systemd is an experiment and maybe there will be a superd that supersedes it and fixes all of its mistakes while embracing all of what it did right. Or maybe systemd *can* be fixed. Point is, systemd *does* introduce some forward features, and the community *is* seeking for a sysvinit replacement. If it will be systemd or a successor I don't know. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

2011/12/28 Michal Kubeček :

On Wednesday 28 of December 2011 12:06EN, Claudio Freire wrote:

...

Well, if you don't read the whole post, yes, I can see how you would answer like that.

I read all of it. I just didn't quote (and comment) the parts I agree with. :-)

... blablabla

I agree completely with everything you said. Especially on socket stuff, weird feature indeed. I don't know who needed/asked for it. I'm hoping all those shortcomings you're pointing out in systemd, which are MAJOR, are going to be fixed (because they can be fixed). Because *then* I'd like to have systemd. Not now. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 28/12/11 12:41, Michal Kubeček wrote:

What makes it even worse is the attitude "We created this scheme what a service should look like and the rest of the world is supposed to conform to this scheme."

After been working for years in distro packaging, this is exactly what we need, conforming to one scheme. Systemd units can even be checked with rpmlint to verify if they really do what the say or what the packager wanted to do try to do that with shell scripts.

Not if it means throwing away the flexibility and easy diagnostics of shell scripts.

The shell is not a debugger is it ? I am missing something ? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 28/12/11 11:49, Michal Kubeček wrote:

On the other hand, it brings a lot of problems and complicates things that used to be simple and easy.

Yeah, simple and easy... did you mean obscure, undocumented, racy and impossible to verify in large scale ? Some features aren't provided at all and

when people point it out, the answer is "you shouldn't want them because systemd doesn't provide them"

Well, people is asking for fairly ridiculous things. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Cristian Rodríguez wrote:

On 28/12/11 11:49, Michal Kubeček wrote:

...

On the other hand, it brings a lot of problems and complicates things that used to be simple and easy.

Yeah, simple and easy... did you mean obscure, undocumented, racy and impossible to verify in large scale ?

Hasn't been much of a problem so far. Or do you have a list of applicable bug reports?

Some features aren't provided at all and

...

when people point it out, the answer is "you shouldn't want them because systemd doesn't provide them"

Well, people is asking for fairly ridiculous things.

Oh yeah. Like output from init scripts. Yup. -- Per Jessen, Zürich (2.1°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 28/12/11 15:55, Peter Nikolic wrote:

If people want certain things and systemd is unable to provide them then systemd has no place to be there simple as .

People wantings things does not mean what they want is correct. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 28/12/11 16:46, Guido Berhoerster wrote:

* Cristian Rodríguez [2011-12-28 19:05]: Turning a deaf ear to your customers' or users' preferences and use cases and trying to force something down their throat through technical means will invoke resistance and is ultimately doomed to failure.

Either people will be begrudged by this arrogance and simply turn away or they will find creative technical means to work around the limitations with results which are usually not too pretty. It's sort of what currently happens with GNOME 3 and it's almost exactly the same when back in 2008 some Sun engineers declared the new IPS packaging system on Solaris a "no scripting zone", in fact the similarities in the sorrounding debates are striking.

Someone has to take decisions and those cannot please everybody, currently it works this way: Those who do the work, take decisions. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 28/12/11 16:55, Claudio Freire wrote:

On Wed, Dec 28, 2011 at 4:53 PM, Cristian Rodríguez wrote:

...

Someone has to take decisions and those cannot please everybody, currently it works this way:

Those who do the work, take decisions.

Those who install the distributions do so as well.

Yes, that 's the nice thing, for old school you have debian and slackware and gentoo.. All other distros either are planning to move to systemd, or already switched to it. and that's due the same thing, Those who do the work, take decisions. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Dec 28, 2011 at 2:55 PM, Claudio Freire wrote:

On Wed, Dec 28, 2011 at 4:53 PM, Cristian Rodríguez wrote:

...

Someone has to take decisions and those cannot please everybody, currently it works this way:

Those who do the work, take decisions.

Those who install the distributions do so as well.

openSUSE currently has a 3-tier system officially; Board members users Unofficially it has: project management (Coolo, etc.) developers other contributors non-contributors The board seems to stay out of technical decisions, and the members only vote on the very occasional item. (ie. The members voted on the overall strategy recently.) Most decisions seem to be made by a adhoc combination of project management, members, developers, and other contributors. But the actual developers of the specific effort in question carry by far the most weight. Non-contributing users (those that install) seem to carry very little weight with the openSUSE project currently. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Dec 28, 2011 at 4:30 PM, Cristian Rodríguez wrote:

...

If people want certain things and systemd is unable to provide them then systemd has no place to be there  simple as   .

People wantings things does not mean what they want is correct.

Ok, now this actually has a lot to do with the RFC. I read on systemd's page:

Services cannot read from stdin, as this will be connected to /dev/null. That means interactive init scripts are not supported (i.e. Debian's X-Interactive in the LSB header is not supported either.) Thankfully most distributions do not support interaction in init scripts anyway. If you need interaction to ask disk or SSL passphrases please consider using the minimal password querying framework systemd supports. (details, manual page)

I seem to recall system rescue and live dvds using that interactivity to query the user at boot time what to do or to provide an emergency shell. How is that handled with systemd? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Cristian Rodríguez [2011-12-28 20:54]:

On 28/12/11 16:46, Guido Berhoerster wrote:

...

* Cristian Rodríguez [2011-12-28 19:05]: Turning a deaf ear to your customers' or users' preferences and use cases and trying to force something down their throat through technical means will invoke resistance and is ultimately doomed to failure.

...

Either people will be begrudged by this arrogance and simply turn away or they will find creative technical means to work around the limitations with results which are usually not too pretty. It's sort of what currently happens with GNOME 3 and it's almost exactly the same when back in 2008 some Sun engineers declared the new IPS packaging system on Solaris a "no scripting zone", in fact the similarities in the sorrounding debates are striking.

Someone has to take decisions and those cannot please everybody, currently it works this way:

Those who do the work, take decisions.

I don't dispute that developers are free to do whatever they want with their projects, I just pointed out that certain decisions and attitudes have the consequences that I described above. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org