man-db without cache update (no cron or systemd *.timer)

Andy Grimm agrimm at
Thu Oct 23 17:45:32 UTC 2014

On Mon, Oct 20, 2014 at 3:24 PM, Lennart Poettering
<mzerqung at> wrote:
> On Mon, 20.10.14 15:08, Matthew Miller (mattdm at wrote:
>> On Mon, Oct 20, 2014 at 08:56:19PM +0200, Lennart Poettering wrote:
>> > But again, I am not sure I understand what is going on here. Is
>> > systemd now optional in Fedora?
>> I guess to some degree everything is "optional" in one way or another.
>> It's certainly the init system we are using. I think the context is in
>> cases where the packages are used without an init system, systemd or
>> otherwise — the main case being single-process (or at least
>> single-parent-process) application containers.
>> (I'm also looking forward to systemd as a process manager inside e.g.
>> Docker for more sophisticated multi-process applications which for
>> whatever reason want to be in the same container, but that's a
>> different use case.)
> While I can see the reason why you want this I really find this quite
> dubious in general. Much of our stack relies on /run and all those
> other facilities, of our general execution environment to be properly
> initialized, cleaned up and maintained. We do this with tmpfiles
> snippets, early-boot services, cron jobs, timer units, and so on and
> so on.
> Just saying "no" to these things, ignoring them and not executing them
> will only get you so far. It also creates in a way a new execution
> environment, unless you perfectly replicate the execution
> environment from your container manager, knowing all components in
> play, including all libraries and whatever else.

A container is _absolutely_ a "new execution environment", and the
whole advantage of it, to most users, is that it's more lightweight
than a complete virtualized OS environment, partly because you do not
have to load an entire operating system.  There is enough abstraction
to make running a distinct set of packages (even a different
distro/version) reasonable, but with the luxury of not having to deal
with network setup, filesystem checks and mounts, initialization of
cgroups, and all those other fun things, because a combination of
systemd, docker, and other host services have done all the work.  And
things like logging the output of the service, restarting it if it
crashes, etc. can easily be taken care of by making a systemd unit for
the container in the *host* OS.

I'm not sure what to make of your comment about "knowing all component
in play,  including all libraries and whatever else," because that
seems to indicate that you are worried about dependency closure inside
the container, which is the responsibility of whomever built the
container.  Assuming they did so in a sane way with a package
management system, they will be fine from that standpoint.

> If you really intend to make Fedora in general workable without
> providing support for tmpfiles bits, without cron jobs, without timer
> units, without setting up the execution environmnt the same way as on
> a classic Fedora boot, then please make this a clear goal of
> Fedora. But just trying to add this through the backdoor sounds wrong.

First, I would say that the community has rammed this requirement
right through the front door.  People _are_ running things this way.
This is not some theoretical future feature; it's an adaptation to
existing use cases.

Second, things like tmpfile cleanup and log rotation are not
requirements for a service to function.  This is why, for example,
none of the many packages which put file in /etc/logrotate.d/ actually
require logrotate.  Sure, it's nice if it's there, but a user is also
free to come up with their own procedure for rotating logs, or to not
rotate them at all.

I would be interested to know some other concrete examples of concerns
about the "execution environment" that would actually impact the
functionality of a service in a container.  I won't claim that such
things don't exist, but tmpfile clean-up and log rotation are poor
examples, IMHO.

> Honestly though, I really don't think this is really such a good
> idea. You make things much more complicated for developers that
> way. We *want* developers to make use of the OS services we provide
> after all. It makes the system more uniform and more accessible to our
> admins and users. If you take the vast majority of the facilities that
> we provide for software away, then very little remains, you devalue
> the OS itself.

We are not taking these things away.  Matt even mentioned that he
would like to see us provide containers with systemd inside them as an
option, but it will necessarily be a more heavyweight option than the
current use case which has become so common, and it will be
uninteresting to many users.  The value in these OS services of which
you speak are significant in the host OS, which has to manage the
orchestration of many containers in this new world.  For the developer
(who is *not* a sysadmin) the value of these services is quite
minimal.  They want to build an app, and run the app, and to have as
little concern as possible for the environment in which it runs.  I
can hardly imagine a more uncomplicated world than what they are
already creating for themselves.


> Lennart
> --
> Lennart Poettering, Red Hat
> --
> devel mailing list
> devel at
> Fedora Code of Conduct:

More information about the devel mailing list