-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2017-02-26 09:45, H.Merijn Brand wrote:

On Sun, 26 Feb 2017 07:50:28 +0100, nicholas wrote:

...

it seems we have 2 systems for default timed events - systemd and cron - why? - 2 systems is 2X things to learn, 2X things to monitor, 2X things to go wrong

so, keep cron :)

Yes! Same here. ... Yes to all your post. - -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAliyyGEACgkQja8UbcUWM1y4VgD/d9GpL7J1pREgODy2oxuYj5y0 G/SmCAgFsmonXOHysfABAJre2lC5fDzKT3Vk1tvexXqTddWA9p6vgffz/uuqfHL0 =bR+A -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sunday, 26 February 2017 13:11:42 CET Thorsten Kukuk wrote:

On Sun, Feb 26, nicholas wrote:

...

it seems we have 2 systems for default timed events - systemd and cron - why? - 2 systems is 2X things to learn, 2X things to monitor, 2X things to go wrong - systemd has a (very) nice interface/overview "systemctl list-timers --all" And a lot of limitations and bad behavior compared to cron.

...

- from limited experience cron bugs/problems can be quite opaque so why is everything not moved to systemd?

Because systemd timer problems are much worse?

Thorsten (to both points): evidence/examples/references? arch wiki gives overwhelming advantages for systemd timers.

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

On Sonntag, 26. Februar 2017 16:08:26 CET Thorsten Kukuk wrote:

On Sun, Feb 26, nicholas wrote:

...

(to both points): evidence/examples/references? arch wiki gives overwhelming advantages for systemd timers.

I suggest to use it yourself and don't trust any wikis without questioning, why this wiki article was written.

systemd timer don't send you the output via mail by default.

And cron by default does not send output to any mail address I regularly read, as is likely true for most other linux users. I considersending mail to an unread local mail account - requiring some local mail delivery - a bug, not a feature.

systemd timer do already run very early in the boot phase, means you have to make sure that your dependencies are correct.

Its clearly better to rely on required dependencies to exist by using an essentially random delay until running jobs, instead of specifying dependencies.

Daily systemd timer run always at 00:00:00

OnCalendar="daily" is only a shortcut for OnCalendar="*-*-* 00:00:00". I think you are able to figure out the correct syntax for running a timer daily on 4am. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 work: +49 2405 49936-424 -- 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: SHA256 On 2017-02-26 14:06, Mikhail Kasimov wrote:

Hello!

...

... can systemd timers operate on fixed times, like cron?

'/AccuracySec/=1us'. Example:

================================================ k_mikhail@linux-mk500:~> systemctl cat vba32update.timer # /etc/systemd/system/vba32update.timer [Unit] Description=Runs VBA32 Update Hourly Requires=timers.target

[Timer] OnBootSec=2min OnUnitInactiveSec=1h AccuracySec=1us

[Install] WantedBy=timers.target ================================================

================================================ k_mikhail@linux-mk500:~> journalctl -e -u vba32update.service ... Фев 26 12:13:14 linux-mk500 systemd[1]: Started VBA32 Anti-Virus Update Service. Фев 26 13:13:14 linux-mk500 systemd[1]: Starting VBA32 Anti-Virus Update Service ================================================

Do you mean such case?

No. Run at 15:13 every alternate day, for instance. Or 20:22 on Mondays. Or the 1st day of every week or month at 08:01 - -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAliy1DcACgkQja8UbcUWM1yV/wD/SRD9LLoEVPTh8huXs7b1q0lJ 3iVAqqmp9TZgIoesifIA/3TVFDWJnn0tpTRvOztSpL+YBzq1/K8VDZcBtfzsc1W9 =qBuR -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

26.02.2017 15:48, Mathias Homann пишет:

Am Sonntag, 26. Februar 2017, 07:50:28 CET schrieb nicholas:

...

it seems we have 2 systems for default timed events - systemd and cron - why? - 2 systems is 2X things to learn, 2X things to monitor, 2X things to go wrong - systemd has a (very) nice interface/overview "systemctl list-timers --all" - from limited experience cron bugs/problems can be quite opaque so why is everything not moved to systemd?

... can systemd timers operate on fixed times, like cron?

For all I know (might be wrong) they operate on fixed intervals, like anacron jobs... but not at fixed times.

sytemd supports calendar time specification which is functionally equivalent to cron (at least, original cron). Current git also added repetition (like "every two hours") similar to notation supported by modern cron. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sunday 2017-02-26 17:03, Michael Ströder wrote:

Cristian Rodríguez wrote:

...

El 26-02-2017 a las 3:50, nicholas escribió:

...

so why is everything not moved to systemd?

Well.. because we can only migrate the cron scripts shipped by the distribution and that takes some work, that nobody has so far performed.

And furthermore dropping cron completely

"Niemand hat die Absicht, cron zu droppen" (Nobody has reason to drop cron)-- in particular nothing of the sort will happen for existing systems that are upgraded, so stop this panic-making. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sunday, 26 February 2017 19:22:13 CET Carlos E. R. wrote:

Well, as cron is not broken, works fine and is understood, and the distro will keep having it available for people that prefer it, what need do we have to migrate the system cron jobs to systemd? What benefit do we obtain?

Why at all dedicate any effort to the migration? For the novelty?

for one reason it gives a really nice interface of all jobs active/non-active, last run, next run with i assume superior journal integration. from hazy recolections cron gives very poor overview, not so easy to understand failures and is not so easy to debug. and like i said duplicated sub-systems does not make for cleaner system. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Sonntag, 26. Februar 2017, 19:49:14 CET schrieb nicholas:

On Sunday, 26 February 2017 19:22:13 CET Carlos E. R. wrote:

...

Well, as cron is not broken, works fine and is understood, and the distro will keep having it available for people that prefer it, what need do we have to migrate the system cron jobs to systemd? What benefit do we obtain?

Why at all dedicate any effort to the migration? For the novelty?

for one reason it gives a really nice interface of all jobs active/non-active, last run, next run with i assume superior journal integration. from hazy recolections cron gives very poor overview, not so easy to understand failures and is not so easy to debug. and like i said duplicated sub-systems does not make for cleaner system.

...how does a regular (i.e. non-root) user install a systemd timer for himself? cheers MH -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 26.02.2017 um 20:09 schrieb Andrei Borzenkov:

26.02.2017 22:05, Mathias Homann пишет:

...

...how does a regular (i.e. non-root) user install a systemd timer for himself?

Place it in ~/.config/systemd/user or ~/.local/share/systemd/user and run "systemctl --user enable my-own.timer"?

seife@susi:~> systemctl --user enable my-own.timer Failed to enable unit: Process org.freedesktop.systemd1 exited with status 1 Does not look useful. Besides, does this timer also run if the user is not logged in? -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 27.02.2017 um 05:13 schrieb Andrei Borzenkov:

26.02.2017 23:20, Stefan Seyfried пишет:

...

seife@susi:~> systemctl --user enable my-own.timer Failed to enable unit: Process org.freedesktop.systemd1 exited with status 1

Hmm ...

bor@bor-Latitude-E5450:~$ systemctl --user enable my.timer Created symlink from /home/bor/.config/systemd/user/default.target.wants/my.timer to /home/bor/.config/systemd/user/my.timer.

I guess you have an extra systemd instance running for your user? I won't. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 28.02.2017 04:29, Andrei Borzenkov wrote:

27.02.2017 22:07, Stefan Seyfried пишет:

...

I guess you have an extra systemd instance running for your user? I won't.

It is usually started automatically

not for XFCE, it seems

but if you intentionally disable it

fortunately, I did not have to do that (yet) So the executive summary about systemd timers is: * not started if the user is not logged in or does not use GNOME * do not mail the output of the job * jobs might get killed in unexpected ways (and probably, even though it's hard to imagine, but from all things systemd I had to look at over the last years I have some evidence that suggest it, the performance will be abysmal) Cron has not disappointed me during the last almost 20 years, so I'll probably be using it happily for another 20. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- 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: SHA256 On 2017-02-28 11:58, Simon Lees wrote:

On 02/28/2017 05:53 PM, Stefan Seyfried wrote:

...

On 28.02.2017 04:29, Andrei Borzenkov wrote:

...

27.02.2017 22:07, Stefan Seyfried пишет:

...

I guess you have an extra systemd instance running for your user? I won't.

It is usually started automatically

not for XFCE, it seems

...

but if you intentionally disable it

fortunately, I did not have to do that (yet)

So the executive summary about systemd timers is: * not started if the user is not logged in or does not use GNOME

This part is not entirely true, KDE, Enlightenment and possibly others all launch inside a systemd user session so i'd expect they work as well. As a side note currently to run wayland the desktop needs to be run in a systemd user session (know one got to making another way) so most desktops are slowly heading that way.

So, unless you login to one of those desktops, and only while you do, will user timers work. Not good. - -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAli1WTsACgkQja8UbcUWM1xzlAEAmdTKSAyI9wXvQv3AtzsFk0Fp WeZ/HaNO1I6R8ZHIKe0BAI5LBhqv9lXBevag5YhkJDUmbxDkwcQ/TxdULoRwky2R =pcmJ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

28.02.2017 19:44, Stefan Seyfried пишет:

On 28.02.2017 11:58, Simon Lees wrote:

...

...

So the executive summary about systemd timers is: * not started if the user is not logged in or does not use GNOME

This part is not entirely true, KDE, Enlightenment and possibly others

Doesn't matter. If you are not logged in, your timers will not run.

Which is not entirely correct. But I suppose you are not interested and do not care anyway :) -- 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: SHA256 On 2017-02-28 18:12, Andrei Borzenkov wrote:

28.02.2017 19:44, Stefan Seyfried пишет:

...

On 28.02.2017 11:58, Simon Lees wrote:

...

...

So the executive summary about systemd timers is: * not started if the user is not logged in or does not use GNOME

This part is not entirely true, KDE, Enlightenment and possibly others

Doesn't matter. If you are not logged in, your timers will not run.

Which is not entirely correct. But I suppose you are not interested and do not care anyway :)

Others may ;-) I will probably keep using cron. I know how it works and how to debug it. But I'm not closed to using timers if the need arises. And then, there are more people that read this or may read it in the future. - -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAli1ugIACgkQja8UbcUWM1yYYQEAmMMyRZvSuls0fEQTN/RYNSa6 0JqqRzg4PeN2+Dzmu3oA/28x+gXNZh+296dyIV5nCC1rYPSEy1tk3yVJaLDWzXAQ =GgbF -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 28 February 2017, Andrei Borzenkov wrote:

28.02.2017 20:57, Carlos E. R. пишет:

...

On 2017-02-28 18:12, Andrei Borzenkov wrote:

...

28.02.2017 19:44, Stefan Seyfried пишет:

...

On 28.02.2017 11:58, Simon Lees wrote:

...

...

So the executive summary about systemd timers is: * not started if the user is not logged in or does not use GNOME

This part is not entirely true, KDE, Enlightenment and possibly others

Doesn't matter. If you are not logged in, your timers will not run.

Which is not entirely correct. But I suppose you are not interested and do not care anyway :)

Others may ;-)

I already answered this in this thread.

Even on default systemd setup a user can easily start his systemd user instance using a cronjob: @reboot sleep 9999d & ... no lingereing settings by user root are needed. $ ps aux | grep rudi rudi 28099 0.0 0.0 36052 4004 ? Ss 19:34 0:00 /usr/lib/systemd/systemd --user rudi 28101 0.0 0.0 62152 2184 ? S 19:34 0:00 (sd-pam) rudi 28102 0.0 0.0 0 0 ? Zs 19:34 0:00 [sh] <defunct> rudi 28103 0.0 0.0 4248 660 ? S 19:34 0:00 sleep 9999d The user instance will run as long as the sleep command is running. Thanks cron's superior design this sleep will also survive crond restarts/stops etc. :) cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

28.02.2017 21:55, Carlos E. R. пишет: ...

...

... no lingereing settings by user root are needed.

...

$ ps aux | grep rudi rudi 28099 0.0 0.0 36052 4004 ? Ss 19:34 0:00 /usr/lib/systemd/systemd --user rudi 28101 0.0 0.0 62152 2184 ? S 19:34 0:00 (sd-pam) rudi 28102 0.0 0.0 0 0 ? Zs 19:34 0:00 [sh] <defunct> rudi 28103 0.0 0.0 4248 660 ? S 19:34 0:00 sleep 9999d

...

Then, the user timers run because there is at least one process of that user.

No. Because there is systemd user instance for this user.

On Tuesday 28 February 2017, Andrei Borzenkov wrote:

28.02.2017 21:55, Carlos E. R. пишет: ...

...

...

... no lingereing settings by user root are needed.

$ ps aux | grep rudi rudi 28099 0.0 0.0 36052 4004 ? Ss 19:34 0:00 /usr/lib/systemd/systemd --user rudi 28101 0.0 0.0 62152 2184 ? S 19:34 0:00 (sd-pam) rudi 28102 0.0 0.0 0 0 ? Zs 19:34 0:00 [sh] <defunct> rudi 28103 0.0 0.0 4248 660 ? S 19:34 0:00 sleep 9999d

...

...

Then, the user timers run because there is at least one process of that user.

No. Because there is systemd user instance for this user.

There are 3 cases: 1. Per default there is only a systemd user instance if "logged in". 2. Adminstrators may disable user instances completely. 3. Administrators may enablelingereing to always have user instances. regarding 1: It's very confusing ... what does it mean "logged in"?. A cron job would start a user instance but login via "su" would not. Moreover I've seen systems where the user instances where not killed on logout. regarding 3: It's very unlikely because it does not even seem possible to enable lingering for ALL users and probably no adminstrator would run hundreds or thousands of processes (one per user). Alltogether for me it looks like systemd timers are not a good choice for users who want to schedule jobs reliable depending on calendar schedules. A user would require much administrator knowledge just to be able to find out when his jobs would run and when not. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 28 February 2017, Jan Engelhardt wrote:

On Tuesday 2017-02-28 20:31, Ruediger Meier wrote:

...

There are 3 cases:

1. Per default there is only a systemd user instance if "logged in".

regarding 1: It's very confusing ... what does it mean "logged in"?. A cron job would start a user instance but login via "su" would not.

Because it's not about log-in, but logind sessions. Since you already have a session at the time of su, no new one is started.

And it's torn down in leap too. 20:49 zap:~ > ssh ki@localhost Password: Last login: Tue Feb 28 20:48:22 2017 Have a lot of fun... 20:49 zap:~ > ps uxaf|grep systemd...user jengelh 1187 0.0 0.0 40864 4860 ? Ss Feb25 0:00 /usr/lib/systemd/systemd --user ki 27515 0.2 0.0 40864 4944 ? Ss 20:49 0:00 /usr/lib/systemd/systemd --user 20:49 zap:~ > logout Connection to localhost closed. 20:49 zap:~ > ps uxaf | grep systemd...user jengelh 1187 0.0 0.0 40864 4860 ? Ss Feb25 0:00 /usr/lib/systemd/systemd --user

Whatever a session is and whyever I get one for cronjobs, but not for su/sudo ... ... at the end I don't understand the sense, why systemd timers would work while an arbitrary cronjob is running or while I'm logged in via ssh but not if I'm logged in via su? Actually I don't even want to understand this anymore. It's one of the biggest non-sense things I've ever seen. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

cron - trying to find if btrfsmaintenance is actually running. looked in the journal -> no mention of the cron job starting, no mention of btrfsmaintenance, no mention of balance, i finally nailed it by searching on the activity that balance invokes "relocating block group". If i have missed something let me know, otherwise this is not how a good interface should work. seems to me cron operates on a "script and pray" principle -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

28.02.2017 10:23, Stefan Seyfried пишет:

On 28.02.2017 04:29, Andrei Borzenkov wrote:

...

27.02.2017 22:07, Stefan Seyfried пишет:

...

I guess you have an extra systemd instance running for your user? I won't.

It is usually started automatically

not for XFCE, it seems

It does here. On vanilla Leaf and TW, under XFCE in both cases. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

26.02.2017 22:13, Rüdiger Meier пишет:

BTW I still have not understood if user timers would run for sure if I'm not logged in.

Not by default. systemd spawns one instance per user when first user session is opened. Once all sessions are terminated, user instance is shut down (stopping all units) unless lingering is enabled for this user. Enabling lingering is privileged operation. When lingering is enabled for a user, user instance is started when system boots and persists until system is shutdown. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sun, Feb 26, 2017 at 10:42 PM, Rüdiger Meier wrote:

On February 26, 2017 8:16:57 PM GMT+01:00, Andrei Borzenkov wrote:

...

26.02.2017 22:13, Rüdiger Meier пишет:

...

BTW I still have not understood if user timers would run for sure if I'm not logged in.

Not by default. systemd spawns one instance per user when first user session is opened. Once all sessions are terminated, user instance is shut down (stopping all units) unless lingering is enabled for this

And already running jobs are just killed?

It goes through normal stop sequence. There are two levels here - user instance stopping user processes and PID1 stopping user instance. For the former it is whatever unit definitions contain. Default is to send SIGTERM and SIGKILL if processes are left after ExecStop (or if there is no ExecStop). For the latter it is user@.service template, which at least in current upstream defaults to KillMode=mixed meaning that all processes still alive will get SIGKILL. You should be able to suppress it with e.g. KillMode=none or SendSIGKILL=no.

...

user. Enabling lingering is privileged operation.

When lingering is enabled for a user, user instance is started when system boots and persists until system is shutdown.

Does this mean there would be 1000 extra processes if I want to use systemd timers instead of cron for 1000 users? Sounds very stupid.

cu, Rudi -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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

Martin Wilck wrote:

On Sun, 2017-02-26 at 22:16 +0300, Andrei Borzenkov wrote:

...

26.02.2017 22:13, Rüdiger Meier пишет:

...

BTW I still have not understood if user timers would run for sure if I'm not logged in.

Not by default. systemd spawns one instance per user when first user session is opened. Once all sessions are terminated, user instance is shut down (stopping all units) unless lingering is enabled for this user. Enabling lingering is privileged operation.

When lingering is enabled for a user, user instance is started when system boots and persists until system is shutdown.

That's still very different from cron. With cron, a user can have jobs running without ever having logged in, and independent of "lingering". That's very useful, I've done it on practically all systems I've been doing serious work on. It's also highly useful for non-human system accounts that need to do stuff repeatedly.

(Btw, "lingering" enables quite some additional services to run on the user's behalf except timers, doesn't it? I'm not sure if I'd want that but I have to admit I haven't looked at the details so far).

I'm certain there's some kind of systemd magic that would also make this kind of scheduling-without-login possible. But it's nowhere close to being able to replace cron. Maybe in the long run, systemd's capabilities in this area will actually surpass cron's, and maybe even usability will be a match. But that day hasn't come yet.

First of all I have to admit that my knowledge about systemd's capabilities is ... nearly not existent. Nevertheless I'm working with Linux/Unix machines since more than 30 years now. I love it because you have a high number of small fine tools doing a specific Job - and not more but this very good. Whenever I hear about systemd I get the impression that we're getting closer to windows - which is sad in my opinion. I like these small specialists - and I hate the "I do everything" tools - too complicated, too much potential problems. one of my favourite candidates here KDE - terrible:-( another one is the "new" logging mechanism - awful. The "way" of systemd (doing a lot of tasks which were assigned to several dedicated tools before) is in my opinion not the "unix way". Yes for sure you can find some arguments for doing it this way - nevertheless my system does (from my point of view) neither better nor worse since we use systemd - I (as a user here) can't see any improvements. Maybe it's "more elegant" - but I don't care. What I realize is: it's more complicated. From a maintenance point of view I personally still prefer the small simple tools - It's easier to understand and maintain. But maybe I'm slowly converting to a sort of a dinosaur - and I'm threatened with extinction. So short summary - I cannot (and do not want to) stop the development of systemd to whatever tool it gets - but please don't forget the "linux way" of having small simple specialist - like "cron". Andreas

On Fri, 3 Mar 2017 00:59:26 -0500, Anton Aylward wrote:

On 03/03/17 12:34 AM, Kyek, Andreas, Vodafone DE (External) wrote:

...

but please don't forget the "linux way" of having small simple specialist

I 100% agree with Keyk. I started with System3, worked with VME, Solaris, AIX (version 2 .. 5), HP-UX (version 7.0 .. 11.31), OSF/1, and most of the Linux flavors.

Oh, you mean like the very, very small original small and fast Bourne shell of the V7 era (about 24k binary on a PDP-11 IIR) .... which we abandoned in favour of the bloated, complex Korn shell and in due course the Born Again Shell, BASH, which is even more bloated, has more built in commands and plug-in structure that lets you add even more (isn't that a security violation?).

No, not at all. sh/bash is a bad counter-example. It's main purpose did NOT change at all, it just got more features. When I started, we just had sh and csh. As a scripting tool, sh was the only portable tool available, but as UI/shell, csh was way more user-friendly than sh. Then indeed came ksh. But then also came tcsh. Users had a choice again, as both shells were functional enough to do ones daily work. Then came bash and zsh and probably a few more: portability became an issue. I still write my shell scripts in the original bourne-shell syntax not using any features of modern shells. For portability. But for user interaction, my daily shell is tcsh.

Your point being?

Emacs would have been a better counter-example. ed, ex and vi were standard, and they just had one single function: edit a file. (g)vim, elvis and all other vi clones do not change that: they are just editors. emacs however adds a complete infrastructure to integrate various other activities into editing. Just like netbeans, idea, and eclipse. That is why I try to stay away from these as long as possible. I see cron as ed. I see systemd as emacs. They both have their target audience, and if you look at how enthusiastic their users are, on both camps, and how many flame-wars have been started over the years on this, I think it warrants the existence of both. Users and system administrators are humans: they all have their preferences. I like all my windows as separate windows and have on average about 20 windows open at the same time. My co-worker might have three windows open, of which one is always maximized hiding the info of all the others. I could not work like he does and he could not work like I do.

You admit ignorance of systemd and rely on the word of others who don't get it for your arguments, ones that are easily disproven and have been. But you pass over those articles.

Irrelevant. Really

On Tuesday, nicholas wrote a rather good parody of these kinds of denunciations of 'new technology; on the main forum. Message-ID: <1689789.g315aOOmSE@asus> https://lists.opensuse.org/opensuse/2017-02/msg00946.html That sums up this thread well.

-- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.25 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/

On 03.03.2017 11:23, Carlos E. R. wrote:

With a difference. You can do the things emacs does with any other editor plus other tools for those other things it does which I do not know about. Not with systemd, there is no alternative.

Hu? There are many more linux systems running fine without systemd than there are running systemd. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Stefan Seyfried [03-03-17 23:29]:

On 03.03.2017 11:23, Carlos E. R. wrote:

...

With a difference. You can do the things emacs does with any other editor plus other tools for those other things it does which I do not know about. Not with systemd, there is no alternative.

Hu? There are many more linux systems running fine without systemd than there are running systemd.

w/o reference, your statement is merely a collection of symbols without any validity, best left unsaid, ie: FUD. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 Photos: http://wahoo.no-ip.org/piwigo @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 04.03.2017 um 13:57 schrieb Patrick Shanahan:

* Stefan Seyfried [03-03-17 23:29]:

...

On 03.03.2017 11:23, Carlos E. R. wrote:

...

With a difference. You can do the things emacs does with any other editor plus other tools for those other things it does which I do not know about. Not with systemd, there is no alternative.

Hu? There are many more linux systems running fine without systemd than there are running systemd.

w/o reference, your statement is merely a collection of symbols without any validity, best left unsaid, ie: FUD.

Just google for sales numbers of android phones. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Simon Lees wrote:

This whole argument is pretty pointless without some firmer description of the types of systems, for example new Samsung TV's / smartwatches for atleast the last year use Tizen which is a linux os that uses systemd,

---- Now we are getting down to the real reason for all those samsung phones catching on fire! They drew too much power with that always-on doing-everything-sysd-thing! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

"H.Merijn Brand" writes:

Emacs would have been a better counter-example. ed, ex and vi were standard, and they just had one single function: edit a file. (g)vim, elvis and all other vi clones do not change that: they are just editors. emacs however adds a complete infrastructure to integrate various other activities into editing. Just like netbeans, idea, and eclipse. That is why I try to stay away from these as long as possible.

I take objection to how you characterize Emacs. You simply don't understand what Emacs is. At it's heart, Emacs is simply a lisp interpreter specializing in manipulating text streams. The so called "editor" itself is actually a collection of programs written in elisp (99% of Emacs is written in elisp with a few primitive functions, that speed is critical, written in C). Thus one should think of Emacs as a lisp machine/vm. All of Emacs's functions are just lisp programs that changes the state of that vm. If you don't want some additional functions, just don't load the corresponding lisp files. Charles -- "Linux: the operating system with a CLUE... Command Line User Environment". (seen in a posting in comp.software.testing)

"Carlos E. R." writes:

Why do you add a white line between each text line? It makes things harder for the other side.

-- Cheers / Saludos,

Carlos E. R.

(from 42.2 x86_64 "Malachite" (Minas Tirith))

I am not seeing any white lines on my end. I don't know where you are getting it from. Charles -- if (argc > 1 && strcmp(argv[1], "-advice") == 0) { printf("Don't Panic!\n"); exit(42); } (Arnold Robbins in the LJ of February '95, describing RCS)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2017-03-04 03:03, Charles Philip Chan wrote:

Charles Philip Chan writes:

Hi Carlos,

...

I am not seeing any white lines on my end. I don't know where you are getting it from.

As you can see, from the mailing list archive:

https://lists.opensuse.org/opensuse-factory/2017-03/msg00148.html

there are no white lines. Something is fishy on your end.

No, because yours are the only posts that show this problem. Not in this post, but the previous one, and in Thunderbird, not in Pine. - -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAli6IqQACgkQja8UbcUWM1zAhgD/XFlGsXuw0tCVIcY3Oc5Dhe1f xNpYe/SfUpuKlAL6zygBAIyI8v2NXrP5hMDTmvWBGe2BeZxXUKfid8RQK/SjI7AD =q+O8 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2017-03-04 03:19, Charles Philip Chan wrote:

"Carlos E. R." writes:

...

No, because yours are the only posts that show this problem. Not in this post, but the previous one, and in Thunderbird, not in Pine.

OK, so it is a Thunderbird problem, since Pine shows it correctly.

Not really. There is something in the mail that triggers it. Perhaps the lines are fixed length, not flowed. Trimmed at the same length where Firefox wraps the lines locally, so that I get a double wrap. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))

Am 04.03.2017 um 03:12 schrieb Carlos E. R.:

No, because yours are the only posts that show this problem. Not in this post, but the previous one, and in Thunderbird, not in Pine.

So it might be a Thunderbird problem? Even though the MIME sent by Emacs looks fishy to my untrained eye. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 04.03.2017 um 11:32 schrieb Charles Philip Chan:

Stefan Seyfried writes:

...

Even though the MIME sent by Emacs looks fishy to my untrained eye.

Why does it look fishy>

Charles

Quote: ======================================================================== Message-ID: <87a892ggux.fsf@karnak> [...] MIME-Version: 1.0 Content-Type: multipart/signed; boundary="===-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --===-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: multipart/signed; boundary="==-=-=" --==-=-= Content-Type: text/plain Content-Disposition: inline "H.Merijn Brand" writes:

Emacs would have been a better counter-example. ed, ex and vi were ========================================================================

And in Thunderbird it looked like: ======================================================================== Content-Type: text/plain Content-Disposition: inline "H.Merijn Brand" writes:

Emacs would have been a better counter-example. ed, ex and vi were

standard, and they just had one single function: edit a file. (g)vim, ========================================================================

The Content-* is probably not intended as part of the "payload" of the message but should be hidden from the reader. If that is Thunderbird's or Emacs' fault? No idea. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, 2017-03-03 at 00:59 -0500, Anton Aylward wrote:

On Tuesday, nicholas wrote a rather good parody of these kinds of denunciations of 'new technology; on the main forum. Message-ID: <1689789.g315aOOmSE@asus> https://lists.opensuse.org/opensuse/2017-02/msg00946.html That sums up this thread well.

Just that this sort of ridicule will not bring us any closer to a solution. On the contrary, it will likely cause the other side to harden its position. It's true that not all arguments in discussions like this are technically well-founded. There's way too much emotion in these discussions, but that's hard to settle once it started, and postings like the one you referenced are rather not the right way to reconcile the dispute. Like it or not, Unix traditionalists represent a substantial part of the Linux user community. Most of these people are neither ignorant nor generally opposed to new technology. You just need very good arguments to force them to fundamentally change their way of working. Despite the vocal opposition, systemd has successfully taken over a lot of functionality from traditional daemons already, in openSUSE as well as elsewhere, so I can hardly understand the heat on the pro-systemd side. Why not sit back and enjoy what you already achieved? systemd timers are simply not a fully functional replacement of cron yet. Even if they were, to achieve full user acceptance, some sort of "compatibility UI" similar to systemd's sysvinit support might be in order [*]. Creating new timer units in $HOME/.config/systemd/user is just not as user-friendly as "crontab -e", not in general, and specifically not for seasoned unix users. Call me stupid, I've been working with systemd for I-dont-know-how-many years now, and I still need to open several man pages every time I create a new unit file. Regards Martin [*] See other thread - "init 3" is indeed easier to type and memorize than "systemctl isolate multi-user.target", and therefore systemd's legacy support is a good thing. -- Dr. Martin Wilck , Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, Mar 3, 2017 at 12:05 PM, Stefan Seyfried wrote:

Just imagine:

one user several machines different cron jobs on those machines shared $HOME.

Does not work with systemd timers AFAICT.

In principle, there is ConditionHost= which can be used in any unit (not only timer) and will gracefully skip unit start on non-matching host. -- 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: SHA256 On 2017-03-03 11:31, Rüdiger Meier wrote:

On 03/03/2017 10:29 AM, Andrei Borzenkov wrote:

...

On Fri, Mar 3, 2017 at 12:05 PM, Stefan Seyfried wrote:

...

Just imagine:

one user several machines different cron jobs on those machines shared $HOME.

Does not work with systemd timers AFAICT.

In principle, there is ConditionHost= which can be used in any unit (not only timer) and will gracefully skip unit start on non-matching host.

And if you want to migrate to another machine then you have to edit all unit files.

Yes, but in this case might be one single file on the shared home with some conditional section for each machine :-? - -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAli5R0AACgkQja8UbcUWM1y8qwD/VjRpGN/W0JgLtNRnJX7uYI2u aukC5BJnDW3/YiEn0r4A/2yZw0lKhxF2Wv+3THtY6yRiPb6Qxs9eTLv/lHff4ySx =a0m0 -----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: SHA256 On 2017-03-03 11:43, Andrei Borzenkov wrote:

And if you want to migrate to another machine you need to create crontab on another machine.

You can simply copy the file(s). Meaning "/var/spool/cron/tabs/" and /etc/cron.d/ Plus monthly, daily, weekly, hourly. I'm considering the /etc/crontab file as not used by the local admin, but the distribution.

I am not sure what you aim at with this response. I simply try to provide technical background about systemd to assist in better and more substantiated decision. Did I ever try to convince *you* that you must drop cron? Why you feel like bickering with *me*?

I know :-) - -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAli5StMACgkQja8UbcUWM1zshQD+NZVculNjDW/sI+0WlEXEbn6m K3gf0nDdmu5RT8/pOTABAJu216SbAGZSJvat1oUgvRQA2Oe1HWMECLBpKpJESOP5 =dhYa -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 03/03/17 04:00 AM, Stefan Seyfried wrote:

On 03.03.2017 06:59, Anton Aylward wrote:

...

On 03/03/17 12:34 AM, Kyek, Andreas, Vodafone DE (External) wrote:

...

but please don't forget the "linux way" of having small simple specialist

Oh, you mean like the very, very small original small and fast Bourne shell of the V7 era (about 24k binary on a PDP-11 IIR) ....

Whataboutism isnt going to help your alternative facts.

No "alternative" about it. That's what is was. I quote the size on the PDP-11 since I did maintenance programming on that. I've not seen that shell compiled on 64-but Linux so I can't quote the size. If anyone has, then I'd be interested in hearing about it. -- They say that if you play a Win cd backward you hear satanic messages. That's nothing! 'cause if you play it forwards, it installs windows. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 03/03/17 11:29 AM, Stefan Seyfried wrote:

...

...

...

Oh, you mean like the very, very small original small and fast Bourne shell of the V7 era (about 24k binary on a PDP-11 IIR) ....

...

...

Whataboutism isnt going to help your alternative facts. o "alternative" about it. That's what is was.

But it has nothing to do with the issue at hand. Thus whataboutism.

Not. You people keep saying what UNIX and Linux is supposed to be, quoting old maxims. You forget that many of then grew out of context, as as I keep saying, Context is Everything The context *WAS* the PDP-11. Small memory space, small disk space. As a result, the shell was important and it was a small binary because this was a small machine. And as such it was very simple. That was design decision that resulted from the constraints of using a PDP-11. And along with that were the collection of other small programs. They each did one thing and one thing only because of the space limitation. On the PDP-11 of that era many system tools, many applications, were written in shell script. And small scripts at that, ones that could fit in a single or perhaps a small number of disk blocks. It was easier to do that than have binaries that took up more space (in core and on disk) and resulted in more swapping and degraded performance. And so began a tradition that persisted even when those constraints no longer applied. Some of those 'maxims' were specific to the PDP-11 context. Perhaps they were good ones; certainly scripting is a powerful approach. But then again, scripting is based around the idea of using an interpreter. In "The Mythical man Month" (page 102 of the original edition) Brooks points out the advantage of using an interpreter: <quote> I recall a young man undertaking to build a an elaborate console interpreter for an IBM 360. He ended up packing it into an incredibly small amount of space by building and interpreter for the interpreter, recognising that human interactions were slow and infrequent, but space was dear. </quote> Interestingly, the section is titled "Representation is the Essence of Programming" and the paragraph before the above quotation has <quote> Show me your tables, and I won't usually need your flowcharts; they'll be obvious. </quote> UNIX and Linux have *SO* many tables. Colon delimited one like /etc/passwd; space delimited one like /etc/fstab. It is important to noted that while inetd used a single file, space delimited configuration file, its replacement, Xinetd, used a single file per service format. https://en.wikipedia.org/wiki/Xinetd#Configuration This offered a lot more controllability and flexibility, as well as visibility and ability to document each service and its why and wherefores. If you want an example of the "each thing does only one thing" axiom, we have here 'each thing specifies only one thing'. The table, instead of being all in one file, is now, in effect, "one row in each file". If you think about it, this is an ancestor, conceptually speaking, to the system unit files. Despite what you say, Stefan, it is relevant because it shows how we got here, shows the progression of changes as the constraints changed, and how a few immensely powerful basic ideas, namely table representation and the use of an interpreter to apply those table entries, has been a constant feature though UNIX and Linux. And, personally speaking, I'm glad those unit files are not all one big XML file! -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday, 6 March 2017 14:47:30 CET Michal Suchánek wrote:

There is also a development paradigm called "divide and conquer". Even if your system resources allows for one 'sysd' that does everything from managing interrupts to editing your spreadsheet it is benefical to divide the problem of running a system into sub-problems that are easy to understand and solved in isolation.

"divide and conquer" - back to engineering by catch-phrase. not all complex systems can be 'isolated' into sub-problems and 'solved in isolation' effectivly. you make the assumption that a complex system of individual agents can perform a given task just as well as a integrated one, when what can happen (in abstract) is exponentially complexity, feedback loops, prolifereation of permissions, hard to find bugs. HURD? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Friday 2017-03-03 06:34, Kyek, Andreas, Vodafone DE (External) wrote:

The "way" of systemd (doing a lot of tasks which were assigned to several dedicated tools before) is in my opinion not the "unix way".

but please don't forget the "linux way" of having small simple specialist - like "cron".

http://0pointer.de/blog/projects/the-biggest-myths.html #6 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Can we please all drop the religious pro and contra systemd stuff from this thread, especially the attacks against people. and return to the matter at hand, which to me looks like cron NOT being obsolete at all, even though systemd can offer per-user timer units. On 03.03.2017 09:08, Stefan Seyfried wrote:

On 03.03.2017 09:14, Jan Engelhardt wrote:

...

On Friday 2017-03-03 06:34, Kyek, Andreas, Vodafone DE (External) wrote:

...

The "way" of systemd (doing a lot of tasks which were assigned to several dedicated tools before) is in my opinion not the "unix way".

but please don't forget the "linux way" of having small simple specialist - like "cron". http://0pointer.de/blog/projects/the-biggest-myths.html #6 Irrelefant for a distribution, where only one preconfigured systemd binary is shipped.

And the, Lennarts page is certainly not a good source for unbiased discussion about sytemd, unless you want to cater to his alternative facts.

-- 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: SHA256 On 2017-03-03 10:18, Mathias Homann wrote:

Can we please all drop the religious pro and contra systemd stuff from this thread, especially the attacks against people. and return to the matter at hand, which to me looks like cron NOT being obsolete at all, even though systemd can offer per-user timer units.

Nay, we already know that cron is not obsolete at all. - -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAli5RlYACgkQja8UbcUWM1zJ0QD/R9ICb9B4UGw6u1dEnTGxvAFL IP6GAIaOgUIjzB7sNzYA/2JLofM5pPZ9yk3/CZlusbvySBWRoYibN3FN41vSH/J/ =e+3w -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 03.03.2017 15:31, Anton Aylward wrote:

On 03/03/17 04:08 AM, Stefan Seyfried wrote:

...

Irrelefant for a distribution, where only one preconfigured systemd binary is shipped.

And the, Lennarts page is certainly not a good source for unbiased discussion about sytemd, unless you want to cater to his alternative facts.

Actually I think its a good analogy, since the kernel is one preconfigured binary but with modules you can choose.

As for Lennart, since he wrote systemd I'd think he would be the definitive source about what it is and is not.

No, absolutely not. Because of course from his POV everything about systemd is great, the best and everything.

No 'alternative" about his facts.

You're just making fallacious ad-hominem attacks. https://www.logicallyfallacious.com/tools/lp/Bo/LogicalFallacies/1/Ad_Homine... This means that you have no solid basis for your arguments, that you turn to personal abuse of the author.

No, there is lots of software Lennart created, that makes a lot of sense and is really useful. And the beginnings of systemd certainly were well-intended. But as so often, the execution is less than optimal. Instead of shoving everything and the kitchen sink into systemd, and trying to replace everything with it, the existing problems (ever tried to read your journal back in finite time? ans that is just one example I'm fighting with every day) should be fixed. But that seldom happens. I really could not care less who writes a piece of software. If it works well. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 03.03.2017 um 19:01 schrieb Carlos E. R.:

About the logs. You know that you can keep syslog standard logs, too. And even disable systemd writing logs.

No you can't. It will always put the journal in /run. And even with the journal on a ramdisk, it performs abysmally. (It takes more than 8 hours to read 4GB of journal (default size) from the ramdisk and output it to stdout, I'll see if I can find the bugzilla with all the dirty details, but since it's against SLES, it will probably be secret anyway).

Or limit some of what it writes or the size. -- Stefan Seyfried

"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 04.03.2017 um 13:05 schrieb Carlos E. R.:

On 2017-03-04 10:54, Stefan Seyfried wrote:

...

Am 03.03.2017 um 19:01 schrieb Carlos E. R.:

...

About the logs. You know that you can keep syslog standard logs, too. And even disable systemd writing logs.

...

No you can't. It will always put the journal in /run. And even with the journal on a ramdisk, it performs abysmally. (It takes more than 8 hours to read 4GB of journal (default size) from the ramdisk and output it to stdout, I'll see if I can find the bugzilla with all the dirty details, but since it's against SLES, it will probably be secret anyway).

Yes, you can. I do it.

Ok, but that is not a supported configuration on SLES, I'm pretty sure. And you'll lose logs. Because some things are only in the journal, others are only in syslog.

Of course, this means that "systemctl status ..." will not show log entries.

That would be a feature. Saves typing "--lines=0" with "systemctl status" all the time. But our SLES Support contract would be moot probably :-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 04.03.2017 um 22:59 schrieb Carlos E. R.:

On 2017-03-04 22:16, Stefan Seyfried wrote:

...

And you'll lose logs. Because some things are only in the journal, others are only in syslog.

I don't know about that, either. I think it would be a bug. I suspect that entries sometimes have different order. Missing entries I have no proof. Maybe some that are related to systemd debug.

I have to dig out the service requests and related bugzillas, but in the end it was "forwarding to syslog failed for $NUMBER messages" in journal, and nothing in syslog. The "only in syslog" thing might have been when I was still using syslog-ng, I'm not 100% sure about that.

...

That would be a feature. Saves typing "--lines=0" with "systemctl status" all the time.

LOL.

Well, that's one thing I find useful, seeing some logs entries related to the failure to start.

Well, but it makes "systemctl foobar status" take lots of time (tens of seconds) when running on rotating rust, because of the superior performance and design of the journal database.

...

But our SLES Support contract would be moot probably :-)

I don't know about that.

You could limit the size of the journal files. That's what I do on other computers. After all, the mail and nntp log fills the journal with useless stuff, so the journal is about useless to me. On this laptop I'm trying no journal at all.

Why save 4 GB of current journal logs? Save a few hundred megs.

It's the default configuration. Something about "n percent of available memory, max 4GB". And on those machines, 4GB is clearly much less than one percent of available memory ;) Anyway, copying 40GB of logfiles off the machine takes maybe 5, max 10 minutes. Dumping 4GB of journal data takes 8+ hours. (The bug btw is bsc#997615 and it was fixed by doing "journalctl -b| head -n xxx" because journalctl performance apparently could not be fixed).

Mind, this configuration works with rsyslog, but not with syslog-ng if I remember correctly the one. The later takes the log entries watching the files, so it gets nothing.

Yes, that's another issue, forcing people to switch to rsyslog (which I personally don't oppose, but still choice would be nice). -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- 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: SHA256 On 2017-03-05 14:12, Mathias Homann wrote:

Am 05.03.2017 um 11:56 schrieb Stefan Seyfried:

...

Am 04.03.2017 um 22:59 schrieb Carlos E. R.: LOL.

...

Well, that's one thing I find useful, seeing some logs entries related to the failure to start. Well, but it makes "systemctl foobar status" take lots of time (tens of seconds) when running on rotating rust, because of the superior performance and design of the journal database.

are you sure you don't mean tens of MILLISECONDS?

No, I'm certain he means seconds. His log is large. See:

Anyway, copying 40GB of logfiles off the machine takes maybe 5, max 10 minutes. Dumping 4GB of journal data takes 8+ hours. (The bug btw is bsc#997615 and it was fixed by doing "journalctl -b| head -n xxx" because journalctl performance apparently could not be fixed).

- -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAli8Fv8ACgkQja8UbcUWM1wGEwD/exd7SccibX3KJNZEENjJ70n+ tXwAvtAU9xCv0mE8iGkA/3VTvqQ0HAn88yicbk0PtUlEAsdO3c/JNfwWhkwFfzev =se4/ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 05.03.2017 um 14:12 schrieb Mathias Homann:

Am 05.03.2017 um 11:56 schrieb Stefan Seyfried:

...

...

Well, that's one thing I find useful, seeing some logs entries related to the failure to start. Well, but it makes "systemctl foobar status" take lots of time (tens of seconds) when running on rotating rust, because of the superior

Am 04.03.2017 um 22:59 schrieb Carlos E. R.: LOL. performance and design of the journal database.

are you sure you don't mean tens of MILLISECONDS?

server:~ # time systemctl status ntpd.service ● ntpd.service - NTP Server Daemon Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled; vendor preset: disabled) Drop-In: /run/systemd/generator/ntpd.service.d └─50-insserv.conf-$time.conf Active: active (running) since So 2017-03-05 09:16:50 CET; 9h ago Docs: man:ntpd(1) Process: 1622 ExecStart=/usr/sbin/start-ntpd start (code=exited, status=0/SUCCESS) Main PID: 1658 (ntpd) Tasks: 2 (limit: 512) Memory: 1.4M CPU: 3.848s CGroup: /system.slice/ntpd.service ├─1658 /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u ntp:ntp -i /var/lib/ntp -c /etc/ntp.conf └─1659 ntpd: asynchronous dns resolver Mär 05 09:16:49 server sntp[1645]: sntp 4.2.8p9@1.3265-o Mon Dec 19 17:18:19 UTC 2016 (1) [...] Mär 05 09:16:50 server start-ntpd[1622]: Starting network time protocol daemon (NTPD) Hint: Some lines were ellipsized, use -l to show in full. real 0m3.199s user 0m0.009s sys 0m0.113s This machine has journal on a bcache backed device, so it's not really rotating rust only.

akari:/var/log/journal/69768dcfb08c8d9ed6558c265239e83b # time systemctl status apache2.service ● apache2.service - The Apache Webserver Loaded: loaded (/usr/lib/systemd/system/apache2.service; enabled; vendor preset: disabled) Active: active (running) since Do 2017-02-23 00:30:52 CET; 1 weeks 3 days ago Main PID: 3039 (httpd-prefork) Status: "Total requests: 7746; Current requests/sec: 0; Current traffic: 0 B/sec" Tasks: 11

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

real 0m0.039s user 0m0.001s sys 0m0.015s

...and that is a dualcore AMD turion2 so definitely not a supercomputer.

SSD or rotating rust? FS cache hot or cold? But it has been slighty improved during the last years. Nowadays the fragmentation is not that bad anymore as it was a few versions ago. So it's probably no longer tens of seconds, only "a few seconds". I'm still typing "-n 0" to avoid that. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 05.03.2017 um 18:38 schrieb Jan Engelhardt:

On Sunday 2017-03-05 18:32, Stefan Seyfried wrote:

...

server:~ # time systemctl status ntpd.service Mär 05 09:16:49 server sntp[1645]: sntp 4.2.8p9@1.3265-o Mon Dec 19 17:18:19 UTC 2016 (1) [...] Mär 05 09:16:50 server start-ntpd[1622]: Starting network time protocol daemon (NTPD) Hint: Some lines were ellipsized, use -l to show in full.

real 0m3.199s user 0m0.009s sys 0m0.113s

This machine has journal on a bcache backed device, so it's not really rotating rust only.

In all fairness, grepping through 4 GB of syslog text logs would equally take as much time, I'd argue.

This is not the "journal non-persistent on a 4GB ramdisk" machine. server:~ # journalctl --disk-usage Archived and active journals take up 1.3G on disk. And in all fai The 4GB ramdisk journal machine greps very fast through 4rness, if systemctl goes through the whole stored journal data to find the last 10 lines of output, then I'd really question its benefits over plain old syslog ;-) Interesting though, that the 1.3GB of journal storage amount to only about one tenth of log message text: server:~ # journalctl -m | wc -c 150200227 So it seems that journal's efficiency is -- ahem -- suboptimal (I always thought it would be stored compressed and indexed for fast access, but it doesn't look like it is implemented like that). -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 05.03.2017 um 20:24 schrieb Carlos E. R.:

And without grepping, just obtaining the text.

In theory, journal might still be faster because you don't have to grep through the text but can just select the entries you are interested in by unit, tag, whatever it is called. In practice, of course, my observations do not support that theory :-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- 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: SHA256 On 2017-03-05 11:56, Stefan Seyfried wrote:

Am 04.03.2017 um 22:59 schrieb Carlos E. R.:

...

On 2017-03-04 22:16, Stefan Seyfried wrote:

...

And you'll lose logs. Because some things are only in the journal, others are only in syslog.

I don't know about that, either. I think it would be a bug. I suspect that entries sometimes have different order. Missing entries I have no proof. Maybe some that are related to systemd debug.

I have to dig out the service requests and related bugzillas, but in the end it was "forwarding to syslog failed for $NUMBER messages" in journal, and nothing in syslog. The "only in syslog" thing might have been when I was still using syslog-ng, I'm not 100% sure about that.

Ah. Dunno. Maybe they were fast coming messages, and I don't have that many to replicate. Maybe a script writing numbered entries fast.

...

...

That would be a feature. Saves typing "--lines=0" with "systemctl status" all the time.

LOL.

Well, that's one thing I find useful, seeing some logs entries related to the failure to start.

Well, but it makes "systemctl foobar status" take lots of time (tens of seconds) when running on rotating rust, because of the superior performance and design of the journal database.

Ahhhh! Understood. Uchh!

...

...

But our SLES Support contract would be moot probably :-)

I don't know about that.

You could limit the size of the journal files. That's what I do on other computers. After all, the mail and nntp log fills the journal with useless stuff, so the journal is about useless to me. On this laptop I'm trying no journal at all.

Why save 4 GB of current journal logs? Save a few hundred megs.

It's the default configuration. Something about "n percent of available memory, max 4GB". And on those machines, 4GB is clearly much less than one percent of available memory ;)

Well, you can limit it: SystemMaxUse=100M RuntimeMaxUse=30M Does the contract say that you can not edit settings at all? Just write sensible values.

Anyway, copying 40GB of logfiles off the machine takes maybe 5, max 10 minutes. Dumping 4GB of journal data takes 8+ hours. (The bug btw is bsc#997615 and it was fixed by doing "journalctl -b| head -n xxx" because journalctl performance apparently could not be fixed).

Yeah. :-( They tested it on SSD.

...

Mind, this configuration works with rsyslog, but not with syslog-ng if I remember correctly the one. The later takes the log entries watching the files, so it gets nothing.

Yes, that's another issue, forcing people to switch to rsyslog (which I personally don't oppose, but still choice would be nice).

But it is the fault of syslog-ng. They are doing it wrong. (effectively syslog-ng seems to be doing a "journalctl --follow") - -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAli8FE0ACgkQja8UbcUWM1y0AAD9EY3cErcT4F3e13BUdXnKBrDK gvdUGZdkrFZD57FO/Q4A/2LuVxQJi1nBXKt8Eqif2bcVgzHuTRWh3Rg3chsqEWgP =YDs6 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stefan Seyfried wrote:

Am 03.03.2017 um 19:01 schrieb Carlos E. R.:

...

About the logs. You know that you can keep syslog standard logs, too. And even disable systemd writing logs.

No you can't. It will always put the journal in /run. And even with the journal on a ramdisk, it performs abysmally. (It takes more than 8 hours to read 4GB of journal (default size) from the ramdisk and output it to stdout, I'll see if I can find the bugzilla with all the dirty details, but since it's against SLES, it will probably be secret anyway).

--- 8 hours?! Even if it was compressed with "xz -9", it wouldn't take that long to decompress. Being on ram or disk shouldn't matter, since 4GB would fit in memory for many or most systems these days. Even if it was on a hard disk, the linux kernel, would, by default, buffer the file in memory if it was randomly accessed all over the place and used small I/O sizes. Even SSD's can be slow if you only do small I/O's. Sending a large email from Windows to my linux box -- when it stores it to the remote IMAP store, uses 4K packets. For a 24MB file, it took 225 seconds meaning I was getting ~110KB/s -- over a 10Gb link (SMB2 file read/write speed is about 200MB/s). Whereas on the IMAP server side, the disk BW is near 1GB/s and locally its coming off 4 SSD's in a RAID0 -- easily capable of over 200MB/s (near 600MB/s new). So disk I/O isn't the bottleneck it's the small I/O size that lowers BW by 2048! Also, possible slowing it down would be if it was decompression using direct-I/O rather than buffered I/O, or possible telling the kernel not to cache the journal under decompression -- so as to never get any benefit from the kernel's buffering. That just sounds too slow to be real -- i.e. you are talking about 146KB/s... and that's not even over a network. *suspicious* -- wondering about presence of delay loops to discourage people dumping logs... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Carlos, On 06.03.2017 05:18, Carlos E. R. wrote:

Example on machine with SSD, both journal and syslog:

cer@Isengard:~> journalctl --disk-usage Archived and active journals take up 856.0M on disk. cer@Isengard:~> time journalctl | wc -l 733258 <======

It would actually be interesting to use "wc -c" to see how much actual data comes out. I was very surprised to find my journal being 1.4GB but containing only about 150MB worth of log data... But this might of course be my fault for not tuning the journal probably and just using the defaults.

It is always the same time. Almost all ram is cache. Machine is not busy. Almost all the time used for reading the journal is user cpu time, not sys. So it is time decoding the files, not reading them.

Yes, journal reading is nowadays, especially when running from SSD, clearly CPU bound.

Syslog has about the same lines as the journal, compressed in much less size (16 megs), and reads much faster. I don't understand why the journal is so big in size; there must be redundancy of some sort.

Look above, on my home systems, it has about a 10x overhead: server:~ # journalctl --disk-usage Archived and active journals take up 1.3G on disk. server:~ # time journalctl -m | wc -c 150653116 real 0m24.173s user 0m22.660s sys 0m9.015s (Hot caches). On my notebook, it's even worse: susi:~ # journalctl --disk-usage Archived and active journals take up 792.6M in the file system. susi:~ # time journalctl -m | wc -c 5061219 real 0m1,724s user 0m1,696s sys 0m0,448s That's 790MB for 3 weeks worth of logs. susi:~ # du -sh /var/log/journal/ /var/log/ 793M /var/log/journal/ 101M /var/log/ So everything else (including 20MB YaST2 ~25MB zypp/zypper etc) takes 101M for 1year+ of logs, and journal takes almost 800MB for 3 weeks. I'm very impressed.

My interpretation is that it has to read, decompress, and sort.

Compression is probably done per record, not per file. And only the text. I hope.

Well, it looks like the compression is not very effective... :-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 06.03.2017 09:56, Andrei Borzenkov wrote:

journal collects a lot of metadata associated with log entry, so for each line in syslog we get rather more in journal. You can compare "journalctl -o short" and "journalctl -o verbose"

Still ridiculous: susi:~ # journalctl --disk-usage Archived and active journals take up 792.6M in the file system. susi:~ # journalctl -m -o verbose | wc -c 43112828 It's only 19 times the size, not 100 times...

Oh, BTW, coredumps may go into journal (I am not sure what are default settings).

susi:~ # coredumpctl list No coredumps found. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- 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: SHA256 On 2017-03-06 09:26, Stefan Seyfried wrote:

Hi Carlos,

On 06.03.2017 05:18, Carlos E. R. wrote:

...

Example on machine with SSD, both journal and syslog:

cer@Isengard:~> journalctl --disk-usage Archived and active journals take up 856.0M on disk. cer@Isengard:~> time journalctl | wc -l 733258 <======

It would actually be interesting to use "wc -c" to see how much actual data comes out.

cer@Isengard:~> time journalctl | wc -c 57953583 real 0m31.913s user 0m26.989s sys 0m7.521s cer@Isengard:~> cer@Isengard:~> journalctl --disk-usage Archived and active journals take up 864.0M on disk. cer@Isengard:~> More than ten times.

I was very surprised to find my journal being 1.4GB but containing only about 150MB worth of log data... But this might of course be my fault for not tuning the journal probably and just using the defaults.

You are right. But what tuning?

...

It is always the same time. Almost all ram is cache. Machine is not busy. Almost all the time used for reading the journal is user cpu time, not sys. So it is time decoding the files, not reading them.

Yes, journal reading is nowadays, especially when running from SSD, clearly CPU bound.

...

Syslog has about the same lines as the journal, compressed in much less size (16 megs), and reads much faster. I don't understand why the journal is so big in size; there must be redundancy of some sort.

Look above, on my home systems, it has about a 10x overhead:

About same on mine. More than ten, actually.

server:~ # journalctl --disk-usage Archived and active journals take up 1.3G on disk. server:~ # time journalctl -m | wc -c 150653116

real 0m24.173s user 0m22.660s sys 0m9.015s

(Hot caches). On my notebook, it's even worse:

susi:~ # journalctl --disk-usage Archived and active journals take up 792.6M in the file system. susi:~ # time journalctl -m | wc -c 5061219

real 0m1,724s user 0m1,696s sys 0m0,448s

That's 790MB for 3 weeks worth of logs.

Mine starts November 26.

susi:~ # du -sh /var/log/journal/ /var/log/ 793M /var/log/journal/ 101M /var/log/

So everything else (including 20MB YaST2 ~25MB zypp/zypper etc) takes 101M for 1year+ of logs, and journal takes almost 800MB for 3 weeks.

I'm very impressed.

Yes, similarly on my desktop machine last time I looked.

...

My interpretation is that it has to read, decompress, and sort.

Compression is probably done per record, not per file. And only the text. I hope.

Well, it looks like the compression is not very effective... :-)

Not if there is some redundancy... - -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAli9u18ACgkQja8UbcUWM1zDewD/RLscxpGAuuDy7k/9lWy2V2HC eR5+FqO4DsqKdOUFNCMA+gO++xP5WJEwkPnzuae7L4AYUjkEKpxkSM20QPQf0dol =jpG8 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 03/03/17 11:35 AM, Stefan Seyfried wrote:

No, absolutely not. Because of course from his POV everything about systemd is great, the best and everything.

Well, you've just told us that you know nothing about programmers or programming, as the real world sees them. No professional programmer[1] ever thinks his work is the 'ne plus ultra'. It can always be better. Even if he has to scrap it and start over. It's never good enough. It's never complete. The really good programmers will also tell you that their work is also never bug free. What he is saying is that its a better alternative to SysVInit. He does list specific problems with SysVInit that systemd addresses, and these are problems that Linux needs to address if its to be considered a serious OS, competing with the likes of VM/CMS and its peers. Which is where the people at RedHat and Novel and others want to go. 'Cos, as Willie Hutton was reputed to have said about banks, its where the money is. Linux isn't a "hobby" system any more. [1] And that goes for many engineers and other professions as well. -- Men fear thought as they fear nothing else on earth, more than ruin, more even than death. . . . Thought is subversive and revolutionary, destructive and terrible, thought is merciless to privilege, established institutions, and comfortable habit. Thought looks into the pit of hell and is not afraid. Thought is great and swift and free, the light of the world, and the chief glory of man. -- Bertrand Russell -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 03.03.2017 um 20:58 schrieb Anton Aylward:

On 03/03/17 11:35 AM, Stefan Seyfried wrote:

...

I really could not care less who writes a piece of software. If it works well.

That's a it simplistic. Its simplistic on a number of counts.

First and foremost, "works well" .. for who (or is it 'whom'? Are there any Grammar-nazis around?) ... and under what conditions and constraints?

Lennart pointed out that SysVinit could fail and break the system under quite a number of conditions.

I think nobody really disputes that. But the implication that systemd is different is... not what I'm experiencing. In my experience, and I have seen quite a number of productive machines of all sizes, those sysv tfailure cases were rare and easily worked around. At least on the systems "where the money is", as you liked to put it. In practice, systemd works best on hobby systems. Less than 128GB of RAM, not much stuff going on, but some dynamic stuff (USB sticks being plugged and unplugged, WIFI connections, fast SSD storage). Unfortunately those are not the machines "where the money is". The bugs / problems I'm finding in everyday usage are on other types of machines, where it becomes absolutely clear that this stuff was obviously not heavily tested besides some hobby-class machines. And then people tend to think "what problems does systemd really solve for us, and are those worth the new troubles we have now?" And while I'm still advocating systemd (even though you might not believe that, but I'm as realistic that I don't think it is going away soon, so we definitely need to cope with it), I'm not going to tell anyone it's a great piece of software / engineering work when it isn't. What I like about it is, for example, that you no longer need to care if you are on a SLES or RHEL machine -- the concepts and procedures are the same now. The biggest problems we had before with old sysv init was -- mostly due to bad init scripts -- "oh, the service wants to start but $DEPENDENCY is not yet there". This was often solved -- ugly, but working -- with a "sleep 60" in the services init scripts and the machine ran happily ever after. And on servers that need 10 minutes to even run through the BIOS, 5 minutes to start up their disks, then (already in the Kernel) another 5 minutes to online all their processors and initialize memory, nobody could care less about that 60 seconds delay. But people do care, if the task is "get the logs out, then reboot ASAP" if dumping 4GB of journal to stdout takes more than 8 hours. And no, the forwarding to syslog does not forward everything. So you need both, syslog and journal.

Then there are issue to do with what I'd term 'communication'. Is the code clear? That begins with not in-line comments or a man page, but with a clear statement of architecture and objectives. On that count, systemd wins hands down over SysVInit, which has no formal design, no defined protocols, is all 'informal' and 'just grew'. In fact that's its problem, some code did things that were not very good, for reasons that were unclear.

Well, if I look at systemd, there is also some code that does things that are not very good :-) And I only can guess the reasons why it does them bad instead of good.

Which gets into the issue of 'maintainability.' If you've ever been a maintenance programmer you'll know that having a clear statement of architecture and objectives, what the code is doing (or not doing) what it is, over and above the in-line comments, is vitally important. If you don't understand this then any changes you might make could end up being damaging.

Some programmers do take this care. Some programmers make sure that their work is 'resilient', that is that "it works well - even when abused".

And you have the feeling that systemd programmers do?

So yes, I do care who writes it.

Yes, and in this regard, I have a certain opinion about systemd, from experience and past bugs. But I would think (not being a native english speaker) that this is considered "ad hominem". If I'm expressing "I'm not going to trust software from Bob, because the last 5 years his stuff had a constant history of stupid bugs", then this is something slightly differnt than if I would be saying "I dont trust Bob's software, because I don't like him".

[...]

There are a few other programs I use that were built by people with a vision and with a discipline. All are incredibly well designed, well architected and well documented.

And that relates to systemd how exactly? ;-P

VIM? Yes, its like systemd in many ways. And trust me, Bill Joy's original VI code was bloody awful! The designers of VIM threw it away and went back and worked on a properly architected editor that just happened to have the same UI. But because it was well architected from the start it became extensible in ways that Joy's wasn't, all without breaking it.

A compiler is probably the most complicated piece of software you'll use, but GCC is, like systemd, like vim, very modular and extensible. Again, vision and architecture and coding discipline.

I DO care about who writes the code I use.

Yes, in this sense I do, too. But I wouldn't dismiss code on ground of who wrote it (which is what I understood you wanted to express with accusing me of ad hominem attacks). -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 04/03/17 05:21 AM, Stefan Seyfried wrote:

In practice, systemd works best on hobby systems. Less than 128GB of RAM, not much stuff going on, but some dynamic stuff (USB sticks being plugged and unplugged, WIFI connections, fast SSD storage). Unfortunately those are not the machines "where the money is". The bugs / problems I'm finding in everyday usage are on other types of machines, where it becomes absolutely clear that this stuff was obviously not heavily tested besides some hobby-class machines.

There's a lot of operational and business psychology going on there that you are not taking into account. "Hobby-class" contexts are more likely to experiment and work with bleeding edge, innovative and uncertain configurations. Why? Because they are not "business critical". It's not that the 'business critical' workhorses are flawless, its that they are known quantities, and the conservative mindset of the higher level business decision makers are conservative about such things. I would be too. Heck, I am; my experiences with Tumbleweed recently have me running back to 13.2 and taking baby steps into 42.1 !!! Once you are dealing with large footprint machines there are quite different sysadmin issues from smaller ones, and in turn the smaller footprint (ironically more cores but less memory & storage than desktops) of 'phones are a different sysadmin issue as well[1]. (In some ways its it a bit like managing older MS-Windows!) As for "not heavily tested besides some hobby-class machines", well that might be an indictment of Linux as a whole rather than systemd in particular :-) It probably is more a statement about numbers, the distribution of end users who are willing to try out newly released software[2]. It is inherent, as I say, in the psychology of the people concerned, the classic curve or 'early adopters' vs 'late adopters' that many pundits in the industry have written articles and books about. [1] So where can I get a kernel update for my Samsung S2 and S3, possibly one that uses systemd? [2] Without it being forced on them ala Windows-10 updates, whether they like it or not. At least with Linux I can choose whether or not to install specific updates & patches. Those poor Windows-10 users don't have such control of granularity. -- I Just Work Here Maxim: No salesperson, engineer, or executive of a company that sells or designs security products or services is prepared to answer a significant question about vulnerabilities, and few potential customers will ever ask them one. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello, On Mar 3 09:14 Jan Engelhardt wrote (excerpt):

http://0pointer.de/blog/projects/the-biggest-myths.html #6

which reads two times "at compile time". If "systemd is modular (only) at compile time", it proves that "systemd is not modular (in practice)". Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- 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: SHA256 On 2017-03-03 16:50, Anton Aylward wrote:

On 03/03/17 10:09 AM, Johannes Meixner wrote:

...

Hello,

On Mar 3 09:14 Jan Engelhardt wrote (excerpt):

...

http://0pointer.de/blog/projects/the-biggest-myths.html #6

which reads two times "at compile time".

If "systemd is modular (only) at compile time", it proves that "systemd is not modular (in practice)".

Different definition of modular. Build time modular, not run time modular. Yes.

Well with the kernel you can compile a module in or load it dynamically. The kernel as shipped has ext4 compiled in but not BtrFS. Odd that, since the installer takes BtrFS and XFS as the default options, not ext4.

Good for me.

You'd think in that case BtrFS would be compiled in and not ext4. "Obviously" the kernel isn't modular!

On the contrary. The kernel is runtime modular.

Its a stupid argument!

After all, one of those modules is the ability to recognise when systemctl (which, by the way is part of the systemd suite but a separate ... well, program, not 'module') is called as init. If it wasn't for that it would be smaller, eh? Perhaps you'd like to do without that?

Knowing how a program is called is trivial code. I use the trick on some of my scripts.

The real modularity is what comes afterwards. The unit files.

That's like saying a C compiler is modular because it reads an application source code built of a thousand files. No. - -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAli5rpEACgkQja8UbcUWM1xVJwD+O5DXFlyvlummOXZrXf5dHz/Y bypgbZsFNsUDUb3j/QAA/iLQJ/n+5F4j3a3MdzKbFsJMseeiv+M7J84P53lRIYr+ =r7Ag -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt wrote:

On Friday 2017-03-03 06:34, Kyek, Andreas, Vodafone DE (External) wrote:

...

The "way" of systemd (doing a lot of tasks which were assigned to several dedicated tools before) is in my opinion not the "unix way".

but please don't forget the "linux way" of having small simple specialist - like "cron".

http://0pointer.de/blog/projects/the-biggest-myths.html #6

---- It's not modular at the program or package levels as the system before it was. The only modular features it has are at build time. From the perspective of non-developers, that is not modular as it isn't reconfigurable by non-developers nor on on systems without the necessary build tools. Developers are in the minority among all users. Claiming something is "modular" because you can reconfigure it at build time, is evidence of being out-of-touch with most users by a huge margin. At what point does being out-of-touch with the rest of society imply some type of sociopathology? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sun, 05 Mar 2017 14:53:39 +0100
nicholas  wrote:

> On Sunday, 5 March 2017 14:18:36 CET L A Walsh wrote:
> > Jan Engelhardt wrote:  
> > > On Friday 2017-03-03 06:34, Kyek, Andreas, Vodafone DE (External)
> > > wrote:  
> > >> The "way" of systemd (doing a lot of tasks which were assigned
> > >> to several dedicated tools before) is in my opinion not the
> > >> "unix way".
> > >> 
> > >> but please don't forget the "linux way" of having
> > >> small simple specialist - like "cron".  
> > > 
> > > http://0pointer.de/blog/projects/the-biggest-myths.html #6  
> > 
> > ----
> >     It's not modular at the program or package levels as the system
> > before it was.  The only modular features it has are at build time.
> > 
> >  From the perspective of non-developers, that is not modular as it
> > isn't reconfigurable by non-developers nor on on systems without the
> > necessary build tools.  Developers are in the minority among all
> > users.
> > 
> > Claiming something is "modular" because you can reconfigure it at
> > build time,
> > is evidence of being out-of-touch with most users by a huge margin.
> > 
> > At what point does being out-of-touch with the rest of society
> > imply some type of sociopathology?  
> im finding your im just a "user" thing hard to buy
> 1) why would a "user" want to change anything significanlty at the
> level of architecture

Because I want to use another piece of software for the functionality

> 2) whats easier impliment systemd unit or your own init scripts (and
> to do so reliably)

The latter. There are many good initscript examples and many bad
systemd service examples.

> 3) which gives the most transparent and clean monitoring tools

cron/sysvinit. You monitor your system processes the same way as your
user processes regardless of init system involved.

> 4) as a "user" is it not easier to move between distributions with
> systemd?

Not at all. I have to diff the user scripts *and* the system scripts.
Because the user-modified service might depend on some system services
which might not be present or implemented differently on different
systems.

> 5) if the definition of modular is a jumble of scripts you
> are correct 

Both systemd and sysvinit become jumble of scripts over time. No
appreciable difference there.

> 6) another name for someone out of touch with the
> confusion of the masses is a visionary

And so when you meet one you have to check the vision against reality
and not run off the cliff as a lemming when the vision calls for that.

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

On 02.03.2017 22:00, Martin Wilck wrote:

(Btw, "lingering" enables quite some additional services to run on the user's behalf except timers, doesn't it? I'm not sure if I'd want that but I have to admit I haven't looked at the details so far).

# getent passwd|wc -l 1503 Those are only the users of a single department. But there is no way AFAICT to configure "lingering" for *all* users, you need to explicitly enable every user (and on each machine, probably). Another one of these "works fine on my notebook at home" systemd "solutions". -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- 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: SHA256 On 2017-03-03 22:10, Stefan Bruens wrote:

On Freitag, 3. März 2017 09:57:44 CET Stefan Seyfried wrote:

...

On 02.03.2017 22:00, Martin Wilck wrote:

...

(Btw, "lingering" enables quite some additional services to run on the user's behalf except timers, doesn't it? I'm not sure if I'd want that but I have to admit I haven't looked at the details so far).

# getent passwd|wc -l 1503

How many of those use a user crontab?

All those *may* use it.

...

Those are only the users of a single department.

But there is no way AFAICT to configure "lingering" for *all* users, you need to explicitly enable every user (and on each machine, probably).

You are able to type crontab -e, fill it out correctly according to syntax and semantics, but are not able to type loginctl enable-linger?

I understand that has to be done by root. And do that in a script that lists all users and do it for each one. - -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAli55aYACgkQja8UbcUWM1yKIgEAhCzutO0aja58izkkyogogB8q r4oli679Bajc36IBtzkA/ijVTO+hZdjz6p9rXf2jVJf8v2r7iNc/L6FrDjAgX+bE =MCyl -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 03.03.2017 um 23:23 schrieb Stefan Bruens:

Reading may help understanding ...

$> pkcheck --action-id org.freedesktop.login1.set-self-linger --process $$ ; echo $?

Try this on a machine where you are not logged in at the console. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sun, Feb 26, Carlos E. R. wrote:

Well, as cron is not broken, works fine and is understood, and the distro will keep having it available for people that prefer it, what need do we have to migrate the system cron jobs to systemd? What benefit do we obtain?

If you think about single purpose operating systems, it would make absolutly sense to migrate anything to systemd timer and drop cron. Like we currently do for SUSE CaaS Platform. But for a multi-purpose OS, it doesn't make any sense, because you still need the cron service. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Thorsten Kukuk wrote:

On Sun, Feb 26, Carlos E. R. wrote:

...

Well, as cron is not broken, works fine and is understood, and the distro will keep having it available for people that prefer it, what need do we have to migrate the system cron jobs to systemd? What benefit do we obtain?

If you think about single purpose operating systems, it would make absolutly sense to migrate anything to systemd timer and drop cron. Like we currently do for SUSE CaaS Platform.

But for a multi-purpose OS, it doesn't make any sense, because you still need the cron service.

Even in the generic case it doesn't matter what daemon actually runs /etc/cron.{hourly,daily,weekly,monthly}. As long as the scripts are run as expected nobody should care whether it's cron or systemd. So we could easily get rid of cron in a minimal install at least. The shell script that wakes up every 15 minutes just to find out that there's nothing to do deserves to be reworked after 19 years of service :-) cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- 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: SHA256 On 2017-02-27 13:38, Ruediger Meier wrote:

On Monday 27 February 2017, Ludwig Nussel wrote:

...

Thorsten Kukuk wrote:

...

On Sun, Feb 26, Carlos E. R. wrote:

...

Even in the generic case it doesn't matter what daemon actually runs /etc/cron.{hourly,daily,weekly,monthly}. As long as the scripts are run as expected nobody should care whether it's cron or systemd. So we could easily get rid of cron in a minimal install at least.

Hopefully not removing DAILY_TIME functionality in /etc/sysconfig/cron.

And of course we still need to keep /etc/cron.{hourly,daily,weekly,monthly} for compatibility because it's not only used by distrubution but by admin's custom scripts.

Yes.

Beside this I personally don't like that distribution's units, timers, etc. are usually installed into /usr. In past mostly everything which happens on a system could be found in /etc. Nowadays weird services or timers might be installed by updates or new packages and watching /etc (even using git) became useless.

That too.

...

The shell script that wakes up every 15 minutes just to find out that there's nothing to do deserves to be reworked after 19 years of service :-)

I can't remember any issues since at least 15 years. Maybe this is one good reason to keep it as is.

Indeed! If the current system works, why change it?

BTW on my 42,2 systems I can see only one active timer: systemd-tmpfiles-clean.service

... and this service is really bad in comparison to the old "clean-tmpfiles script". The old one was carefully developed over years and did not removed active sockets for example.

Absolutely. And the current one doesn't seem to clean all tmp files right.

So if we really want to avoid cron's 15min-wakeup thing then I would suggest only adding 4 systemd timers hourly,daily,weekly,monthly which simply call the scripts from the /etc/cron.* dirs in alphabetically order.

At least that. And be able to choose the preferred run time in the current place. - -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAli0MzMACgkQja8UbcUWM1x95gD/bK/uJilbzXkq73Qt98U/Bahw 7n1GeocSC4jwieOPHSIA/Rj/S54z9UIX9DPg4PsMo0H8RkprRiSOeGge4mKegSZJ =VhRX -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday 27 February 2017, Cristian Rodríguez wrote:

On Mon, Feb 27, 2017 at 11:09 AM, Carlos E. R.

wrote:

...

Indeed! If the current system works, why change it?

It works until you get a runaway job. which cron is unable to track..even if you stop the cron daemon..it wont stop the processes it forked.

That's exactly like wanted. cron's purpos is to _start_ jobs but not stop them. Why on earth should it kill my programs just because crond is stopped or restarted? It would be as stupid as a shell always killing all childs on exit. Processes may get SIGHUP and do whatever they want with it. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 27.02.2017 um 15:09 schrieb Carlos E. R.:

Indeed! If the current system works, why change it?

STOP IT RIGHT NOW! With this question, you have clearly marked yourself non-competent wrt. systemd :-) ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday 2017-02-27 13:38, Ruediger Meier wrote:

Beside this I personally don't like that distribution's units, timers, etc. are usually installed into /usr. In past mostly everything which happens on a system could be found in /etc.

If you really find such a system layout attractive, you should quit using a contemporary GNU/Linux userspace and switch to BSD. There, everything is like it used to be 20 years ago, including /etc being the dumping ground for anything and everything (making things like factory resets unnecessarily hard, but hey, if you want that). -- 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: SHA256 On 2017-02-27 16:35, Ruediger Meier wrote:

On Monday 27 February 2017, Jan Engelhardt wrote:

Is this really better and easier than just placing a one liner "fstrim -a" into a crontab or into /etc/cron.weekly?

...

(making things like factory resets unnecessarily hard, but hey, if you want that).

Ah, you mean rm -rf /etc would do a nice factory reset? I doubt it ...

All systems where I ever made "Factory resets" had some kind of /rom partitions or overlay file systems. For openSUSE there is a DVD-ROM to do a Factory reset....

Perhaps it is the systemd mechanism by which services in /usrsomething can be superseded by placing the same service file under /etcsomething. Erasing those files on /etc would revert to factory settings, no? And it also allows the admin to replicate the changes easily on another machine, and to do updates without local modifications being erased. Is that it? - -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAli0dWwACgkQja8UbcUWM1yjwwD/YK+ElGMWc6vobkMdlkfTscmL VbYAxzQqsVW0iuJiVAsA/ipdT08r4/pFvXTTQf3fnREQA0ZSxJtT1y5kiWQMyOj0 =DL/Z -----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: SHA256 On 2017-03-06 13:20, Michal Suchánek wrote:

On Mon, 27 Feb 2017 19:52:28 +0100 "Carlos E. R." <> wrote:

...

Perhaps it is the systemd mechanism by which services in /usrsomething can be superseded by placing the same service file under /etcsomething. Erasing those files on /etc would revert to factory settings, no?

...

And it also allows the admin to replicate the changes easily on another machine, and to do updates without local modifications being erased.

That also means updates without service updates being applied.

Because you copy the *WHOLE* service, make changes, and any updates to the service are lost on update.

Well, you can instead edit the original service file, and perhaps when the rpm is updated you get rpmorig files.

Sane services are configurable so you put a file in /etc/ that configures the service and do not change the service itself unless you need to fix some error in the service definition.

Well, initd services were not configurable that way either (except that configuration that a particular service would design). We had to edit the service script, and watch out on updates for replacements (rpmorig etc). - -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAli9XpUACgkQja8UbcUWM1zX0QD7BLRvWeeM0X6GNzZnPRACanWg /cWTfwiZdpfLqf1naqQA+wZr6epoRYsxFn3GRuV8lCVjl6YoFTTJ7gClk10Ri/v/ =z2/W -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Montag, 6. März 2017 13:20:57 CET Michal Suchánek wrote:

On Mon, 27 Feb 2017 19:52:28 +0100

...

Perhaps it is the systemd mechanism by which services in /usrsomething can be superseded by placing the same service file under /etcsomething. Erasing those files on /etc would revert to factory settings, no?

And it also allows the admin to replicate the changes easily on another machine, and to do updates without local modifications being erased.

That also means updates without service updates being applied.

Because you copy the *WHOLE* service, make changes, and any updates to the service are lost on update.

Sane services are configurable so you put a file in /etc/ that configures the service and do not change the service itself unless you need to fix some error in the service definition.

But nobody writes systemd services that accept configuration so you have to fix the service definition to be configurable and only then you can configure it /o\

Why are the systemd haters always claiming stuff without once reading the man pages? man systemd.unit: EXAMPLES ... Example 2. Overriding vendor settings [...] Suppose there is a vendor-supplied unit /usr/lib/systemd/system/ httpd.service with the following contents: [...] The first possibility is to copy the unit file to /etc/systemd/system/httpd.service and change the chosen settings: [...] Alternatively, the administrator could create a drop-in file /etc/systemd/system/httpd.service.d/local.conf with the following contents: [...] Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 work: +49 2405 49936-424 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, 7 Mar 2017 01:45:08 +0100 Stefan Bruens wrote:

On Montag, 6. März 2017 13:20:57 CET Michal Suchánek wrote:

...

On Mon, 27 Feb 2017 19:52:28 +0100

...

Perhaps it is the systemd mechanism by which services in /usrsomething can be superseded by placing the same service file under /etcsomething. Erasing those files on /etc would revert to factory settings, no?

And it also allows the admin to replicate the changes easily on another machine, and to do updates without local modifications being erased.

That also means updates without service updates being applied.

Because you copy the *WHOLE* service, make changes, and any updates to the service are lost on update.

Sane services are configurable so you put a file in /etc/ that configures the service and do not change the service itself unless you need to fix some error in the service definition.

But nobody writes systemd services that accept configuration so you have to fix the service definition to be configurable and only then you can configure it /o\

Why are the systemd haters always claiming stuff without once reading the man pages?

man systemd.unit: EXAMPLES ... Example 2. Overriding vendor settings [...] Suppose there is a vendor-supplied unit /usr/lib/systemd/system/ httpd.service with the following contents: [...]

The first possibility is to copy the unit file to /etc/systemd/system/httpd.service and change the chosen settings: [...]

Alternatively, the administrator could create a drop-in file /etc/systemd/system/httpd.service.d/local.conf with the following contents: [...]

Regards,

Stefan

How nice. Unfortunately, when you are modifying a systemd service and look at systemd.service(5) there is nothing about that. Given systemd has a dozen of these man pages I would expect a cross-link to the explanation. But in systemd.service you get "A number of options that may be used in this section are shared with other unit types. These options are documented in systemd.exec(5), systemd.kill(5) and systemd.resource-control(5)." Nothing about systemd.unit. It's only mentioned in the generic See Also section and far from prominent there. So yes, an additional paragraph there as seen in systemd.unit(5) or possibly just link to the explanation there could potentially save everyone a lot of trouble. A package can ship these override files prefilled with commented-out defaults so you can see them in the file list just like it ships /etc/default files. There is very little awareness of this feature. When you ask about changing service files all you hear is "copy it to /etc/.. and edit it". I have read a few systemd tutorials when migrating to systemd and I have no idea this exists. So while systemd enthusiasts that read everything about systemd from cover to cover and back again may know the casual packager or administrtator who has had systemd shoved down their throat by the committee which decides the default init system of their distro just reads the systemd.service(5), writes a service definition which may even work with some luck, rants how useless maintaining that service is, and moves on. This results in a lots of rants available when you ask WTF you should do to write a service file for this piece of software that has worked flawlessly for 25 years but now cannot be started on your system because it does not have a systemd service file. Michal -- 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: SHA256 On 2017-03-07 15:13, Johannes Meixner wrote: ...

I think more than hundred man pages about systemd tells a lot what it means until one can configure and use it correctly.

I guess we need a systemd man pages search engine service with its own man page: man systemd-man.service ;-)

What about "pinfo" instead? It links pages. I see the pages highlighted, click or enter and I get to that page. Is there a systemd index page? 150 pages is daunting. - -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAli+xk0ACgkQja8UbcUWM1xpMAD/YOy3nYrl6WuCRmYdMUjdO89G ZYXehDCFl7iXUmIG75oA/2oOSZnhc/A1TOK8W8lxlOXaRBC1iCzrgaDYlP3sLi01 =FrS+ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, 7 Mar 2017 10:11:12 -0500 Anton Aylward wrote: