Re: [systemd-devel] [RFC] the chopping block

[Mike Gilbert]

On Wed, Feb 24, 2016 at 10:42 PM, Mike Gilbert  wrote:
> On Fri, Feb 19, 2016 at 7:22 AM, Lennart Poettering
>  wrote:
>> On Thu, 18.02.16 20:33, Mike Gilbert (flop...@gentoo.org) wrote:
>>
>>> On Thu, Feb 11, 2016 at 12:06 PM, Lennart Poettering
>>>  wrote:
>>> > 1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
>>> >time Debian was still using that, maybe this changed now?
>>>
>>> Gentoo allows switching between systemd and openrc (sysvinit) at boot
>>> time, and will continue to do so for the foreseeable future.
>>>
>>> By default, sysvinit owns /sbin/initctl, /sbin/halt, etc. Users may
>>> swap these to symlinks to systemd and systemctl by setting a USE flag,
>>> but if they do so they knowingly lose the ability to switch back to
>>> openrc without a rebuild of the affected packages.
>>>
>>> I would like to selfishly request that you keep this interface around
>>> as long as possible; if you remove it I will have to come up with some
>>> replacement.
>>
>> So here's probably what is going to happen.
>>
>> The initctl support in systemctl will be dropped and replaced by some
>> callout script support. i.e. when you want to use systemctl to reboot
>> a sysvinit system, then systemctl won't do that anymore, but it will
>> invoke some shell script as a fallback, where distros can place the
>> necessary commands if they care about this. This follows how we do
>> sysv script enable/disable handling (i.e. the chkconfig hookup).
>>
>> We'll eventually kill /dev/initctl support. Distros should really find
>> their own replacement for this. They can either take the current code,
>> build it externally, or write some new code. You might be able to
>> implement this in a carefully prepared shell script that invokes
>> busctl to do the reboot. You could use "dd" to read the initreq
>> structure from STDIN with the precise size, then figure out which kind
>> of request it is (again, by using dd to extract the four bytes
>> starting at index 4 of that request structure) and then simply execute
>> the right busctl command to poweroff/reboot/...
>>
>> I'll not drop this right-away, but let's say in 6month or so this will
>> go away. This should be an ample heads-up to find a replacement and
>> prepare for this.
>
> The existing systemd-initctl (/dev/initctl) interface works quite
> nicely, so I will probably end up extracting it from systemd when you
> drop it, or just building/installing it from an older systemd tarball.
> No need to reinvent the wheel.
>
> Thanks for the response.

Ripping systemd-initctl out of the systemd source tree was more
difficult than I anticipated. Instead, I rewrote a simpler version.
The code is on bitbucket.

https://bitbucket.org/floppym/gentoo-systemd-initctl/src
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Mike Gilbert]

On Fri, Feb 19, 2016 at 7:22 AM, Lennart Poettering
 wrote:
> On Thu, 18.02.16 20:33, Mike Gilbert (flop...@gentoo.org) wrote:
>
>> On Thu, Feb 11, 2016 at 12:06 PM, Lennart Poettering
>>  wrote:
>> > 1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
>> >time Debian was still using that, maybe this changed now?
>>
>> Gentoo allows switching between systemd and openrc (sysvinit) at boot
>> time, and will continue to do so for the foreseeable future.
>>
>> By default, sysvinit owns /sbin/initctl, /sbin/halt, etc. Users may
>> swap these to symlinks to systemd and systemctl by setting a USE flag,
>> but if they do so they knowingly lose the ability to switch back to
>> openrc without a rebuild of the affected packages.
>>
>> I would like to selfishly request that you keep this interface around
>> as long as possible; if you remove it I will have to come up with some
>> replacement.
>
> So here's probably what is going to happen.
>
> The initctl support in systemctl will be dropped and replaced by some
> callout script support. i.e. when you want to use systemctl to reboot
> a sysvinit system, then systemctl won't do that anymore, but it will
> invoke some shell script as a fallback, where distros can place the
> necessary commands if they care about this. This follows how we do
> sysv script enable/disable handling (i.e. the chkconfig hookup).
>
> We'll eventually kill /dev/initctl support. Distros should really find
> their own replacement for this. They can either take the current code,
> build it externally, or write some new code. You might be able to
> implement this in a carefully prepared shell script that invokes
> busctl to do the reboot. You could use "dd" to read the initreq
> structure from STDIN with the precise size, then figure out which kind
> of request it is (again, by using dd to extract the four bytes
> starting at index 4 of that request structure) and then simply execute
> the right busctl command to poweroff/reboot/...
>
> I'll not drop this right-away, but let's say in 6month or so this will
> go away. This should be an ample heads-up to find a replacement and
> prepare for this.

The existing systemd-initctl (/dev/initctl) interface works quite
nicely, so I will probably end up extracting it from systemd when you
drop it, or just building/installing it from an older systemd tarball.
No need to reinvent the wheel.

Thanks for the response.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Lennart Poettering]

On Thu, 18.02.16 20:33, Mike Gilbert (flop...@gentoo.org) wrote:

> On Thu, Feb 11, 2016 at 12:06 PM, Lennart Poettering
>  wrote:
> > 1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
> >time Debian was still using that, maybe this changed now?
> 
> Gentoo allows switching between systemd and openrc (sysvinit) at boot
> time, and will continue to do so for the foreseeable future.
> 
> By default, sysvinit owns /sbin/initctl, /sbin/halt, etc. Users may
> swap these to symlinks to systemd and systemctl by setting a USE flag,
> but if they do so they knowingly lose the ability to switch back to
> openrc without a rebuild of the affected packages.
> 
> I would like to selfishly request that you keep this interface around
> as long as possible; if you remove it I will have to come up with some
> replacement.

So here's probably what is going to happen.

The initctl support in systemctl will be dropped and replaced by some
callout script support. i.e. when you want to use systemctl to reboot
a sysvinit system, then systemctl won't do that anymore, but it will
invoke some shell script as a fallback, where distros can place the
necessary commands if they care about this. This follows how we do
sysv script enable/disable handling (i.e. the chkconfig hookup).

We'll eventually kill /dev/initctl support. Distros should really find
their own replacement for this. They can either take the current code,
build it externally, or write some new code. You might be able to
implement this in a carefully prepared shell script that invokes
busctl to do the reboot. You could use "dd" to read the initreq
structure from STDIN with the precise size, then figure out which kind
of request it is (again, by using dd to extract the four bytes
starting at index 4 of that request structure) and then simply execute
the right busctl command to poweroff/reboot/...

I'll not drop this right-away, but let's say in 6month or so this will
go away. This should be an ample heads-up to find a replacement and
prepare for this.

Thanks,

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Mike Gilbert]

On Thu, Feb 11, 2016 at 12:06 PM, Lennart Poettering
 wrote:
> 1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
>time Debian was still using that, maybe this changed now?

Gentoo allows switching between systemd and openrc (sysvinit) at boot
time, and will continue to do so for the foreseeable future.

By default, sysvinit owns /sbin/initctl, /sbin/halt, etc. Users may
swap these to symlinks to systemd and systemctl by setting a USE flag,
but if they do so they knowingly lose the ability to switch back to
openrc without a rebuild of the affected packages.

I would like to selfishly request that you keep this interface around
as long as possible; if you remove it I will have to come up with some
replacement.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Ahmed S. Darwish]

Hi :-)

On Thu, Feb 11, 2016 at 06:06:45PM +0100, Lennart Poettering wrote:
> Heya!
...
> 5) Here's the controversial one I think: support for booting up
>without /var. We have kludges at quite a few places because we
>cannot access /var early during boot. I am tempted to stop
>supporting this altogether. Of course, this does *not* mean that
>people with split off /var would be left in the cold. It just means
>that they have to mount /var from the initrd, exactly like this is
>already handled from /usr. 
>

What about fastboot, < 1 second, _initrd-less_, embedded systems
that usually mount root read-only, while mounting /var as a tmpfs?

Does any solution exist for these systems if such changes are
applied?

Thanks a lot,

-- 
Darwish
http://darwish.chasingpointers.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Lennart Poettering]

On Fri, 12.02.16 23:37, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> > > > As long as it's only one package I am happy to break this I must say...
> > > I check this now, and samba compiles fine with systemd-compat-libs.rpm
> > > removed. So no problem here.
> > > 
> > > Our compat support consists of two parts:
> > > libsystemd-{journal,daemon,...}.pc and the .so libraries. I think we
> > > should still keep the .pc files for now.
> > 
> > Why? do you know any package that still needs it?
> 
> Not everything is packaged, people might have other code.
> There is no maintenance cost, it's just four tiny text files.
> So if we remove something that was documented as an official
> interface, I think there should be a clear saving.

Well, but we really want people to fix up their stuff eventually. I am
fine with maintaining compat for a while, and we did for 2y, but I am
very sure we should be strict after the transition phase and cut
things off. There *must* always be a strategy how to finish the
transition, and they only viable strategy I see is to make a hard cut
after a long transition phase, and I think that's now.

In general, I think ABI compatibility is a ton more relevant than mere
API compatibility anyway. Maintaining ABI compat means being nice to
users, and I think that's worth a lot. But providing API compat that
requires only a rebuild to fix ABI is just a service to developers,
and that's far less of a priority.

Moreover, the .so files we shipped for the last 2y generated linker
warnings anyway, so people should really have noticed. And fixing
their build is still trivially easy, it just means changing the
pkg-config line in their configure script a tiny bit.

I think we should cut this off fully. Let's please get rid of this
bitrotting crap now!

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Lennart Poettering]

On Sat, 13.02.16 00:10, Christian Seiler (christ...@iwakd.de) wrote:

> On 02/12/2016 10:34 PM, Lennart Poettering wrote:
> > On Fri, 12.02.16 17:49, Simon McVittie (simon.mcvit...@collabora.co.uk) 
> > wrote:
> > 
> >> On 11/02/16 17:06, Lennart Poettering wrote:
> >>> 5) Here's the controversial one I think: support for booting up
> >>>without /var. We have kludges at quite a few places because we
> >>>cannot access /var early during boot.
> >>
> >> I don't think /var is really the same thing as /usr: for a start, it has
> >> to be read/write, whereas /usr and / can be read-only for at least the
> >> early stages of boot.
> >>
> >> On stateless systems with a read-only / and /etc, requiring /var to be
> >> mounted from the initramfs would mean that the mechanism for setting up
> >> /var (NFS or tmpfs or whatever) would have to move into the
> >> initramfs.
> > 
> > Since initrds tend to cover root-on-nfs, root-on-iscsi and so on
> > anyway, that sounds like no change in behaviour really..
> 
> Well, kind-of. The root-on-nfs and root-on-iscsi are dumbed-down
> versions of what's possible once a system is booted.

Well, to my understanding dracut and stuff makes pretty much all
storage tech that is available during the normal system also available
in the initrd, with the same software, to make sure testing stays
managable. It waits for the root disk and for /usr with the same
machanics (i.e. the systemd logic of .device units, fsck services and
.mount units). And quite frankly that's really how an initrd should
work really: use the same logic and the same software as the host
would...

I think you are extrapolating from limitations of one specific initrd
implementation, no? It sounds really as if that implementation should
be fixed though... 

> PS: Btw. if you do run journald already in initramfs (which I
> think is a good thing to have), then it still needs to have
> code to flush /run/log/journal to /var/log/journal. So in that
> case you don't actually gain anything.

The journal isn't really the issue, as /var is generally read-only
initially anyway. 

(and yeah, I am pretty sure initrd should run systemd – which implies
running journald too – for reasons described above: you want to keep
the differences minimal)

My maingoal here is really about having read-access to things, and
being able to schedule stuff based on configuration and existance of
things, even if that stuff cannot be written to yet. If /var is
mounted this late it makes things a lot more complex.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Reindl Harald]

Am 13.02.2016 um 13:01 schrieb Lennart Poettering:

My maingoal here is really about having read-access to things, and
being able to schedule stuff based on configuration and existance of
things, even if that stuff cannot be written to yet. If /var is
mounted this late it makes things a lot more complex.


it's still unclear *what* that chnage means for setups like over the 
long and it makes a lot of sense to have /var/log not on the sysroot for 
as example inbound spamfilters logging a lot to prevent fill the rootfs


[root@mail-gw:~]$ cat /etc/fstab | grep log
UUID=a8fc620d-8046-47a3-8b63-102c525ce5e8  /var/log  ext4  defaults, 
noexec  0 1




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Christian Seiler]

On 02/13/2016 01:01 PM, Lennart Poettering wrote:
> On Sat, 13.02.16 00:10, Christian Seiler (christ...@iwakd.de) wrote:
> 
>> On 02/12/2016 10:34 PM, Lennart Poettering wrote:
>>> On Fri, 12.02.16 17:49, Simon McVittie (simon.mcvit...@collabora.co.uk) 
>>> wrote:
>>>
 On 11/02/16 17:06, Lennart Poettering wrote:
> 5) Here's the controversial one I think: support for booting up
>without /var. We have kludges at quite a few places because we
>cannot access /var early during boot.

 I don't think /var is really the same thing as /usr: for a start, it has
 to be read/write, whereas /usr and / can be read-only for at least the
 early stages of boot.

 On stateless systems with a read-only / and /etc, requiring /var to be
 mounted from the initramfs would mean that the mechanism for setting up
 /var (NFS or tmpfs or whatever) would have to move into the
 initramfs.
>>>
>>> Since initrds tend to cover root-on-nfs, root-on-iscsi and so on
>>> anyway, that sounds like no change in behaviour really..
>>
>> Well, kind-of. The root-on-nfs and root-on-iscsi are dumbed-down
>> versions of what's possible once a system is booted.
> 
> Well, to my understanding dracut and stuff makes pretty much all
> storage tech that is available during the normal system also available
> in the initrd, with the same software, to make sure testing stays
> managable.

Ok, so I just checked.

So the very last version of dracut (released 3 months ago) supports
starting iscsid in the initramfs, older versions do not - and only
if systemd is installed in the initramfs image. If there's no
systemd in the initramfs or an older version is used, dracut uses
the iscsistart binary as I explained. So support for this is very,
very new.

NFS (latest dracut git master): idmapping for NFSv4 is supported to
some extent, but there are a lot of assumptions going in: it assumes
that nsswitch is used for idmapping (which is probably the most
common case on clients, but it need not be the only possibility), it
tries to install all nsswitch modules found in /etc/nsswitch.conf,
but doesn't know anything about their configuration.

What's not supported at all: NFS with Kerberos support. I should note
note that NFS w/ Kerberos doesn't work out of the box for /var on a
running system either, because you still need to fetch a Kerberos
ticket for all the system users that access /var, but it's relatively
easy to set something like that up, because you just need to write
a simple systemd service for that and run it at boot - which most
admins will be able to do - modifying the initramfs is a lot more
complicated (especially because the documentation is sparse and the
criticism of many people that initramfs are black magic is there for
a reason).

So basically: it's probably going to work in many cases as long as
you don't want a Kerberized setup, but not everything will work out
of the box, even if you don't use Kerberos.

NBD: dracut (current git master) currently doesn't even support
/usr on nbd if / isn't on it (and even then only if on the same
device).

And then there are still other setups that I had mentioned.
DRBD with cluster filesystem: not supported in initramfs. sshfs:
doesn't work in initramfs. FUSE filesystems in general: I only
know that some people have experimented with zfs-fuse for the
rootfs, and it was very fiddly at best from what I remember.
And while most people who want to use ZFS on Linux nowadays use
the kernel module (where binaries can't be distributed for legal
reasons), other FUSE filesystems still have the same issue. The
problem is that storage is complicated. You need to special-case
each different storage type and add specific code to make that
work in the initramfs. If you look at the dracut source code,
every different storage solution is special-cased. You need to
make sure that the programs required for that storage work in an
initramfs environment and can either terminated before
switch_root and then restarted in the running system, or
alternatively support being kept around during switch_root. You
need to have glue code that copies the right files into the
initramfs.

For rootfs there are certain limitations that have been widely
accepted, but if you now start to say that lots of common mount
points, especially some parts of /var, to be required to be
mounted in the initramfs, you'll make life a lot more complicated
for a lot of people.

A _lot_ of different projects will have to make sure that their
software now works in an initramfs context, even if it was never
intended to be used for the root filesystem. That's a lot of
work for other people, especially since coordination between
different projects is required, just to save yourself from a bit
of complexity in systemd.

> I think you are extrapolating from limitations of one specific initrd
> implementation, no?

No. dracut has had some improvements in this regard very recently,
but the main point that more 

Re: [systemd-devel] [RFC] the chopping block

[Christian Seiler]

On 02/13/2016 01:44 PM, Reindl Harald wrote:
> [root@mail-gw:~]$ cat /etc/fstab | grep log
> UUID=a8fc620d-8046-47a3-8b63-102c525ce5e8  /var/log  ext4  defaults, noexec  
> 0 1

To be fair to Lennart: your specific use case, if /var/log is just a
separate partition, will work perfectly fine even with Lennart's
change, because mounting a partition on a local storage device using
the UUID is already supported by initramfs implementations (see the
/usr case).

My objection to the change is about more complicated storage setups,
where one would need to put in a lot of work to be rid of limitations
we all have accepted for / and /usr.

Regards,
Christian



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Mantas Mikulėnas]

On Thu, Feb 11, 2016 at 7:06 PM, Lennart Poettering 
wrote:

> 5) Here's the controversial one I think: support for booting up
>without /var. We have kludges at quite a few places because we
>cannot access /var early during boot. I am tempted to stop
>supporting this altogether. Of course, this does *not* mean that
>people with split off /var would be left in the cold. It just means
>that they have to mount /var from the initrd, exactly like this is
>already handled from /usr.
>

I didn't care about /usr, I always thought mounting it from the initrd is
fine. (Especially since most people I've seen only have the separate
filesystem directly at /usr, not separate ones at /usr/bin, /usr/lib, etc.)

But doing that with more and more filesystems, especially /var, somewhat
feels like going backwards from what systemd itself was trying to push
once, doesn't it? It used to be "sysv's mount -a is inflexible and you
should specify correct dependencies and use RequiresMountsFor" and all
that. Now we're going back to "specifying correct dependencies is a pain
and you should mount everything at once before starting any services"...

It's also unclear what precisely needs to be present, since people *do*
often have mountpoints for individual subdirectories under /var, e.g. I've
seen /var/log and /var/lib/mysql. So, for example, will systemd require
/var/lib/mysql to be mounted by my initramfs, even if mysql.service already
takes care of it? Or will it only require /var/lib/systemd or /var/log? How
is one supposed to know?

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Reindl Harald]

Am 13.02.2016 um 14:17 schrieb Christian Seiler:

On 02/13/2016 01:44 PM, Reindl Harald wrote:

[root@mail-gw:~]$ cat /etc/fstab | grep log
UUID=a8fc620d-8046-47a3-8b63-102c525ce5e8  /var/log  ext4  defaults, noexec  0 1


To be fair to Lennart: your specific use case, if /var/log is just a
separate partition, will work perfectly fine even with Lennart's
change, because mounting a partition on a local storage device using
the UUID is already supported by initramfs implementations (see the
/usr case)


that's what i wanted to have finally confirmed



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Colin Guthrie]

Lennart Poettering wrote on 11/02/16 17:49:
> On Thu, 11.02.16 18:29, Matthias Urlichs (matth...@urlichs.de) wrote:
> 
>> Hi,
>>
>> Lennart Poettering:
>>> 5) Here's the controversial one I think: support for booting up
>>>without /var.
>>
>> Meh. I have quite a few multi-boot systems with a common /var/log
>> partition. Plus, unlike the other "spring cleaning" changes this would
>> cause a boot failure after update.
> 
> Again: this does not break systems with split off /var, as I tried to
> make very clear in my original mail. All that's needed is that the
> initrd mounts /var before handing off control to the main system.
> 
> The initrd already does that for / and for /usr, hence /var is just
> one more step.

Hmmm, has all the split-usr code been fully removed from systemd now? A
quick grep suggests not.

While I don't personally have a problem with this removal, I do think
that comparing it to /usr is bogus.

While you may not *support* /usr being split out and mounted by /, it
does still work and systemd *is* still sympathetic to that.

The situation with /var is much more brutal. You're suggesting that it
would now be something that *has* to be done by the initrd and if you go
down that route, you may as well ditch all the split-usr stuff too as if
the initrd *has* to mount /var, it may as well do /usr too now even if
there were some hold outs.


Like I say, I get your reasoning for wanting to do this, but it's not
really comparable to /usr support.


Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Lennart Poettering]

On Thu, 11.02.16 19:44, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> On Thu, Feb 11, 2016 at 06:45:52PM +0100, Lennart Poettering wrote:
> > On Thu, 11.02.16 17:34, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) 
> > wrote:
> > 
> > > On Thu, Feb 11, 2016 at 06:06:45PM +0100, Lennart Poettering wrote:
> > > > Heya!
> > > > 
> > > > So I am thinking about some spring cleaning, and would love to remove
> > > > the following bits from the systemd package:
> > > > 
> > > > 1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
> > > >time Debian was still using that, maybe this changed now?
> > > > 
> > > > 2) compat support for libsystemd-login.so and friends (these were
> > > >merged into a single libsystemd.so a long time ago). We are still
> > > >building compat libraries to ease the transition, but that was a
> > > >long time ago, hence I'd really love to see this go. Any distro
> > > >still using this?
> > > Fedora ;)
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1125086
> > > But looking at https://bugzilla.samba.org/show_bug.cgi?id=10672#c14
> > > maybe it'd be enough to rebuild samba without the compat headers
> > > >installed.
> > 
> > As long as it's only one package I am happy to break this I must say...
> I check this now, and samba compiles fine with systemd-compat-libs.rpm
> removed. So no problem here.
> 
> Our compat support consists of two parts:
> libsystemd-{journal,daemon,...}.pc and the .so libraries. I think we
> should still keep the .pc files for now.

Why? do you know any package that still needs it?

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Lennart Poettering]

On Thu, 11.02.16 23:32, Michael Biebl (mbi...@gmail.com) wrote:

> 2016-02-11 18:06 GMT+01:00 Lennart Poettering :
> > Heya!
> >
> > So I am thinking about some spring cleaning, and would love to remove
> > the following bits from the systemd package:
> >
> > 1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
> >time Debian was still using that, maybe this changed now?
> 
> Debian still uses that, yes. Is this causing any maintenance issues?

It's bitrotting because unmaintained, and I don't like the code. I'd
rather not maintain such legacy stuff.

> It's a pretty isolated component after all.

Well, it's in the systemd repo, which mean I have to take core for it,
but I'd rather not.

What's Debian's strategy for phasing this out? I mean, to say this
clearly: even if we don't delete it today, we'll delete it sooner or
later, hence Debian really should figure out what it wants to do for
this case. Debian could fix sysvinit's reboot to try sending
SIGRMIN+{4,5} to PID 1 in case it needs a poweroff or reboot and
/dev/initctl is not connectable. Or you could maintain the thing
downstream. Or you could suggest people to use 

"reboot || /usr/bin/kill -RTMIN+4 1" 

or so if they want to downgrade from systemd to sysvinit.

> > 2) compat support for libsystemd-login.so and friends (these were
> >merged into a single libsystemd.so a long time ago). We are still
> >building compat libraries to ease the transition, but that was a
> >long time ago, hence I'd really love to see this go. Any distro
> >still using this?
> 
> As Martin already pointed out, we dropped the comapt libs a while
> ago.

Excellent!

> > 3) systemd-reply-password – this is really old stuff used by the GNOME
> >ask-password stuff which was experimental at best, and never found
> >much use. Unless am very wrong pretty much nobody is using this,
> >and we can just kill this without replacement. Anybody knows a user
> >of this that I am not aware of?
> 
> Not actually sure what this tool is actually supposed to do and why it
> was added in the first place.
> Does GNOME shell implement the password agent interface now
> natively?

nope. never did. i figure system-level LUKS disks aren't a priority
for DEs.

> > 5) Here's the controversial one I think: support for booting up
> >without /var. We have kludges at quite a few places because we
> >cannot access /var early during boot. I am tempted to stop
> >supporting this altogether. Of course, this does *not* mean that
> >people with split off /var would be left in the cold. It just means
> >that they have to mount /var from the initrd, exactly like this is
> >already handled from /usr.
> 
> I'm worried about this one. /var can hold a lot of data and is often
> backed by complex setups (iSCSI, nbd, involving remote access).
> Pulling all that into the initramfs seems like a huge amount of
> work.

Well, you have to support that anyway, if you want to allow iscsi-root
and things like that. This should change very little, no?

> Can you enumerate the problems that a split-off of /var is causing?

See other mail.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Christian Seiler]

On 02/12/2016 10:34 PM, Lennart Poettering wrote:
> On Fri, 12.02.16 17:49, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote:
> 
>> On 11/02/16 17:06, Lennart Poettering wrote:
>>> 5) Here's the controversial one I think: support for booting up
>>>without /var. We have kludges at quite a few places because we
>>>cannot access /var early during boot.
>>
>> I don't think /var is really the same thing as /usr: for a start, it has
>> to be read/write, whereas /usr and / can be read-only for at least the
>> early stages of boot.
>>
>> On stateless systems with a read-only / and /etc, requiring /var to be
>> mounted from the initramfs would mean that the mechanism for setting up
>> /var (NFS or tmpfs or whatever) would have to move into the
>> initramfs.
> 
> Since initrds tend to cover root-on-nfs, root-on-iscsi and so on
> anyway, that sounds like no change in behaviour really..

Well, kind-of. The root-on-nfs and root-on-iscsi are dumbed-down
versions of what's possible once a system is booted.



iSCSI: currently the rootfs works fine, because for the rootfs one
can easily tell the initramfs implementation explicitly that it's
on iSCSI. If your rootfs is on network storage, you have to do so
anyway, so that's not an issue.

But there's no way to determine *just* from looking at /etc/fstab
that a given file system is on iSCSI (or nbd for that matter),
because those just look like regular SCSI block devices (which
don't exist yet if the initramfs hasn't logged in to the iSCSI
session).

This is already somewhat problematic for /usr, but since I've never
seen a setup where people put /usr on iSCSI but / not, so this
was never a huge issue in that regard.

On the other hand, what I have seen in practice are systems with
/var/log on iSCSI.

Also, if you look at how iSCSI login in initramfs works currently,
it's basically just running a binary called 'iscsistart' that tells
the kernel to log in to a specific session where the rootfs is on,
the real daemon isn't started yet. So only a specific session
that is configured separately (!) from all the other configured
sessions is logged into in the initramfs - and the daemon that
reads the proper configuration is only started after the system has
booted.

So in order to support generic filesystems on iSCSI in initramfs,
one would need to start the full daemon already in the initramfs,
plus the full configuration database must be available in the
initramfs (which can change with just some admin commands, after
which the admin would need to remember to regenerate the
initramfs image), and the daemon would need to be modified to
support that.





NFS:

nfsroot is supported only for NFSv2/3 and (depending on the
initramfs implementation) in NFSv4 with sec=sys without idmapping.
If you need NFSv4 with idmapping or want to actually have a secure
NFS mount (e.g. encrypted + authenticated via Kerberos), that
currently doesn't work at all from the initramfs. idmapping
requires that request-key works within the initramfs and properly
calls the nfsidmap binary, which will in turn usually require
the full NSS stack of the system to be available. For Kerberos
you need rpc.svcgssd to be running, as well as have a program like
k5start running to get a ticket for the root user, otherwise the
file system is inaccessible on a kernel level. (And Kerberos also
requires idmapping btw.) Also, in contrast to e.g. iSCSI, where
you could probably get away with killing the daemon before
switching to the rootfs, and then restarting the daemon, both the
idmapping binaries and the rpc.svcgssd have to remain available,
(the former as an upcall from the kernel, the latter as a running
daemon), otherwise the kernel won't be able to properly handle
the filesystem.






And NFS and iSCSI are just two things I have quite a bit of
experience with. You could also imagine that people put /var/log
on sshfs, or any other FUSE filesystem for that matter, which as
of now works, but will break if you introduce the change, because
the vast majority of FUSE filesystems (if any at all) support
running from initramfs. Or you could have /var/log as a bind
mount of a directory within an OCFS2 filesystem on a multi-master
DRBD. It's not that difficult to set up on a normal system, but
good luck getting that to work from an initramfs.





Of course, it's not impossible to make all these setups work.
But it would require changes to a lot of other software that's
currently used, which are probably going to be relatively
painful and it's going to be a lot of work for a lot of other
people.

The maintenance burden in systemd for buffering things in /run
before /var, /var/log, etc. are available is minuscule compared
to that amount of pain this change would cause other people.
Which in turn means what would more likely happen is that this
would not be implemented in many cases and then once the version
of systemd with this requirement hits distributions, this would
break users' systems without them being 

Re: [systemd-devel] [RFC] the chopping block

[Lennart Poettering]

On Fri, 12.02.16 10:04, Colin Guthrie (gm...@colin.guthr.ie) wrote:

> Lennart Poettering wrote on 11/02/16 17:49:
> > On Thu, 11.02.16 18:29, Matthias Urlichs (matth...@urlichs.de) wrote:
> > 
> >> Hi,
> >>
> >> Lennart Poettering:
> >>> 5) Here's the controversial one I think: support for booting up
> >>>without /var.
> >>
> >> Meh. I have quite a few multi-boot systems with a common /var/log
> >> partition. Plus, unlike the other "spring cleaning" changes this would
> >> cause a boot failure after update.
> > 
> > Again: this does not break systems with split off /var, as I tried to
> > make very clear in my original mail. All that's needed is that the
> > initrd mounts /var before handing off control to the main system.
> > 
> > The initrd already does that for / and for /usr, hence /var is just
> > one more step.
> 
> Hmmm, has all the split-usr code been fully removed from systemd now? A
> quick grep suggests not.

Well, we support installing the package with split bin directories,
but we don't really support booting without /usr around. I mean, udev
rules aren't restarted as soon as /usr and the binaries on it become
available, hence it simply cannot work correctly to have /usr not
available during early boot. If distros claim that, they are just
lying to themselves and their users... (note that many packages
install their own udev rules, such as sane, udisks and so on, and they
are generally located in /usr, hence they all, together with *all*
their deps – which include things such as glib and so on – would have
to be placed in /, too, but to my knowledge no distro does that). 

The only things we official support:

a) / and /usr are on one file system, either with or without initrd
b) / and /usr are split, but then you have to mount it from the
   initrd, and you need one

> While I don't personally have a problem with this removal, I do think
> that comparing it to /usr is bogus.

Well, it's the same thing, really. We'd just make the change to say
that /, /usr and /var either have to be all on the same fs, in which
case initrd and non-initrd boots are supported. Or people can split up
/, /usr and /var into as many pieces as they like, but in that case an
initrd has to be in place and mount things before the system
transitions to the host init system.

> While you may not *support* /usr being split out and mounted by /, it
> does still work and systemd *is* still sympathetic to that.

Not really.

> The situation with /var is much more brutal. You're suggesting that it
> would now be something that *has* to be done by the initrd and if you go
> down that route, you may as well ditch all the split-usr stuff too as if
> the initrd *has* to mount /var, it may as well do /usr too now even if
> there were some hold outs.

Well, not mounting /usr in the initrd is pretty much broken, except
that some exotic cases might still work superficially (i.e systems
where you install zero other packages, and no sane, no udisks, and
nothing like that), but not really. And it would be the exact same
with /var. Sure, we'd still boot up, and a lot of stuff will still
appear to work, execept that it's actually pretty fucked.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Lennart Poettering]

On Fri, 12.02.16 17:49, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote:

> On 11/02/16 17:06, Lennart Poettering wrote:
> > 5) Here's the controversial one I think: support for booting up
> >without /var. We have kludges at quite a few places because we
> >cannot access /var early during boot.
> 
> I don't think /var is really the same thing as /usr: for a start, it has
> to be read/write, whereas /usr and / can be read-only for at least the
> early stages of boot.
> 
> On stateless systems with a read-only / and /etc, requiring /var to be
> mounted from the initramfs would mean that the mechanism for setting up
> /var (NFS or tmpfs or whatever) would have to move into the
> initramfs.

Since initrds tend to cover root-on-nfs, root-on-iscsi and so on
anyway, that sounds like no change in behaviour really..

> Which specific subdirectories of /var do you want mounted before pid 1
> starts? Presumably /var/lib/systemd and /var/log, and everything that's
> necessary to mount those, but not necessarily their siblings?

Yeah, mostly those, see other mail.

> Would it be feasible to buffer read/write stuff in /run until /var comes
> up, and then write it out afterwards? (I realise that's already how some
> of it works, notably the Journal.)

That's what we do currently. I'd love to reduce this.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Lennart Poettering]

On Thu, 11.02.16 19:18, Matthias Urlichs (matth...@urlichs.de) wrote:

> On 11.02.2016 18:49, Lennart Poettering wrote:
> > Again: this does not break systems with split off /var, as I tried to
> > make very clear in my original mail. All that's needed is that the
> > initrd mounts /var before handing off control to the main system.
> I know that. Please don't assume that I misunderstood you just because
> every systemd-basher during the last five years did the same thing. :-P
> 
> However, it *does* break systems which do not mount /var in their initrd
> despite having /var (or a piece thereof) split off.
> Such changes should have a "deprecated" phase between "works fine" and
> "needs manual intervention".

Well, it's just a matter of shifting responsibilities between systemd
and the initrd, that's all. I'd really like to see this responsibility
being moved over to the initrd, like we already did for the /usr case.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Lennart Poettering]

On Thu, 11.02.16 21:39, Reindl Harald (h.rei...@thelounge.net) wrote:

> 
> 
> Am 11.02.2016 um 20:37 schrieb Jóhann B. Guðmundsson:
> >Arguably you should chop away the environment files support in the
> >process since you are already wielding the axe...
> 
> no - damned there are a ton of reasons to use them where it *do not matter*
> if you would do whatever this way or not

Not this again!

Johann, Reindl, the next time you start flaming each other about the
EnvironmentFile= thing again on this ML I'll put both of you on moderation,
reagrdless who started it.

We had this discussion many times, I made clear that I think
EnvironmentFile= was a mistake, but that it will stay, and that's
really the end of the story.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Lennart Poettering]

On Thu, 11.02.16 21:59, Martin Pitt (martin.p...@ubuntu.com) wrote:

> Hello,
> 
> answering for Debian/Ubuntu.
> 
> Lennart Poettering [2016-02-11 18:06 +0100]:
> > 1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
> >time Debian was still using that, maybe this changed now?
> 
> This would apply if you boot with systemd, then install sysvinit, and
> want to reboot the machine (using SysV's /sbin/reboot), right? Or the
> other way around?

yeah, it's about making legacy tools speak to systemd. i.e. you booted
up with systemd, and now want to use sysv "reboot" to reboot the
system. i.e for downgrading from systemd to sysvinit.

> This is still somewhat relevant for Debian, but maybe there's
> something simpler that can be done for that case? If there's any other
> way to reboot the machine in that situation, it can also become
> documentation.

You can send SIGINT to PID 1. Tha triggers a reboot on both sysvinit
and systemd.

> 
> Not relevant for Ubuntu.
> 
> > 2) compat support for libsystemd-login.so and friends (these were
> >merged into a single libsystemd.so a long time ago). We are still
> >building compat libraries to ease the transition, but that was a
> >long time ago, hence I'd really love to see this go. Any distro
> >still using this?
> 
> D/U dropped the compat libs months ago.

very good!

Given that fedora got rid of it too with the exception of samba (which
as reported seems to have been fixed upstream already), I think we can
kill this now.

> > 3) systemd-reply-password – this is really old stuff used by the GNOME
> >ask-password stuff which was experimental at best, and never found
> >much use. Unless am very wrong pretty much nobody is using this,
> >and we can just kill this without replacement. Anybody knows a user
> >of this that I am not aware of?
> 
> First time I hear about it TBH. I'm not a GNOME-y/desktop-y person any
> more, but this suggests that it's nowhere being used except for the
> rather old systemd-ui:
> https://codesearch.debian.net/perpackage-results/systemd-reply-password/2/page_0
> 
> dracut apparently installs it into the generated initrd, but that's a
> trivial thing to drop.

That sounds very wrong. I'll ping Harald!

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Zbigniew Jędrzejewski-Szmek]

On Fri, Feb 12, 2016 at 10:16:14PM +0100, Lennart Poettering wrote:
> On Thu, 11.02.16 19:44, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> 
> > On Thu, Feb 11, 2016 at 06:45:52PM +0100, Lennart Poettering wrote:
> > > On Thu, 11.02.16 17:34, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) 
> > > wrote:
> > > 
> > > > On Thu, Feb 11, 2016 at 06:06:45PM +0100, Lennart Poettering wrote:
> > > > > Heya!
> > > > > 
> > > > > So I am thinking about some spring cleaning, and would love to remove
> > > > > the following bits from the systemd package:
> > > > > 
> > > > > 1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
> > > > >time Debian was still using that, maybe this changed now?
> > > > > 
> > > > > 2) compat support for libsystemd-login.so and friends (these were
> > > > >merged into a single libsystemd.so a long time ago). We are still
> > > > >building compat libraries to ease the transition, but that was a
> > > > >long time ago, hence I'd really love to see this go. Any distro
> > > > >still using this?
> > > > Fedora ;)
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=1125086
> > > > But looking at https://bugzilla.samba.org/show_bug.cgi?id=10672#c14
> > > > maybe it'd be enough to rebuild samba without the compat headers
> > > > >installed.
> > > 
> > > As long as it's only one package I am happy to break this I must say...
> > I check this now, and samba compiles fine with systemd-compat-libs.rpm
> > removed. So no problem here.
> > 
> > Our compat support consists of two parts:
> > libsystemd-{journal,daemon,...}.pc and the .so libraries. I think we
> > should still keep the .pc files for now.
> 
> Why? do you know any package that still needs it?

Not everything is packaged, people might have other code.
There is no maintenance cost, it's just four tiny text files.
So if we remove something that was documented as an official
interface, I think there should be a clear saving.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Zbigniew Jędrzejewski-Szmek]

On Thu, Feb 11, 2016 at 06:45:52PM +0100, Lennart Poettering wrote:
> On Thu, 11.02.16 17:34, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> 
> > On Thu, Feb 11, 2016 at 06:06:45PM +0100, Lennart Poettering wrote:
> > > Heya!
> > > 
> > > So I am thinking about some spring cleaning, and would love to remove
> > > the following bits from the systemd package:
> > > 
> > > 1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
> > >time Debian was still using that, maybe this changed now?
> > > 
> > > 2) compat support for libsystemd-login.so and friends (these were
> > >merged into a single libsystemd.so a long time ago). We are still
> > >building compat libraries to ease the transition, but that was a
> > >long time ago, hence I'd really love to see this go. Any distro
> > >still using this?
> > Fedora ;)
> > https://bugzilla.redhat.com/show_bug.cgi?id=1125086
> > But looking at https://bugzilla.samba.org/show_bug.cgi?id=10672#c14
> > maybe it'd be enough to rebuild samba without the compat headers
> > >installed.
> 
> As long as it's only one package I am happy to break this I must say...
I check this now, and samba compiles fine with systemd-compat-libs.rpm
removed. So no problem here.

Our compat support consists of two parts:
libsystemd-{journal,daemon,...}.pc and the .so libraries. I think we
should still keep the .pc files for now.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Jóhann B . Guðmundsson]

On 02/11/2016 05:34 PM, Zbigniew Jędrzejewski-Szmek wrote:

>2) compat support for libsystemd-login.so and friends (these were
>merged into a single libsystemd.so a long time ago). We are still
>building compat libraries to ease the transition, but that was a
>long time ago, hence I'd really love to see this go. Any distro
>still using this?

Fedora;)
https://bugzilla.redhat.com/show_bug.cgi?id=1125086
But looking athttps://bugzilla.samba.org/show_bug.cgi?id=10672#c14
maybe it'd be enough to rebuild samba without the compat headers installed.



The upstream bug is few months short of it's 2 year anniversary and this 
move will just get the samba developers to apply the patch in that 
upstream report and close that bug.


Andrew is there any reason the patch in that upstream report has not 
been applied and samba moved to use libsystemd.so?


JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Armin K.]

On 11.02.2016 20:44, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Feb 11, 2016 at 06:45:52PM +0100, Lennart Poettering wrote:
>> On Thu, 11.02.16 17:34, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) 
>> wrote:
>>
>>> On Thu, Feb 11, 2016 at 06:06:45PM +0100, Lennart Poettering wrote:
 Heya!

 So I am thinking about some spring cleaning, and would love to remove
 the following bits from the systemd package:

 1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
time Debian was still using that, maybe this changed now?

 2) compat support for libsystemd-login.so and friends (these were
merged into a single libsystemd.so a long time ago). We are still
building compat libraries to ease the transition, but that was a
long time ago, hence I'd really love to see this go. Any distro
still using this?
>>> Fedora ;)
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1125086
>>> But looking at https://bugzilla.samba.org/show_bug.cgi?id=10672#c14
>>> maybe it'd be enough to rebuild samba without the compat headers
installed.
>>
>> As long as it's only one package I am happy to break this I must say...
> I check this now, and samba compiles fine with systemd-compat-libs.rpm
> removed. So no problem here.
> 
> Our compat support consists of two parts:
> libsystemd-{journal,daemon,...}.pc and the .so libraries. I think we
> should still keep the .pc files for now.

Yes, please! I've been doing just that ever since libsystemd was introduced.
Sadly, the change to always install .pc files even when libraries weren't
built was rejected.



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Martin Pitt]

Martin Pitt [2016-02-11 21:59 +0100]:
> This would apply if you boot with systemd, then install sysvinit, and
> want to reboot the machine (using SysV's /sbin/reboot), right? Or the
> other way around?
> 
> This is still somewhat relevant for Debian, but maybe there's
> something simpler that can be done for that case? If there's any other
> way to reboot the machine in that situation, it can also become
> documentation.

... I figure "systemctl reboot" should do?

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Jóhann B . Guðmundsson]

On 02/11/2016 09:44 PM, Andrew Bartlett wrote:

On Thu, 2016-02-11 at 20:04 +, Jóhann B. Guðmundsson wrote:

On 02/11/2016 05:34 PM, Zbigniew Jędrzejewski-Szmek wrote:

2) compat support for libsystemd-login.so and friends (these
were
merged into a single libsystemd.so a long time ago). We are
still
building compat libraries to ease the transition, but that
was a
long time ago, hence I'd really love to see this go. Any
distro
still using this?

Fedora;)
https://bugzilla.redhat.com/show_bug.cgi?id=1125086
But looking athttps://bugzilla.samba.org/show_bug.cgi?id=10672#c14
maybe it'd be enough to rebuild samba without the compat headers
installed.


The upstream bug is few months short of it's 2 year anniversary and
this
move will just get the samba developers to apply the patch in that
upstream report and close that bug.

Andrew is there any reason the patch in that upstream report has not
been applied and samba moved to use libsystemd.so?

There isn't a patch for upstream master and the 4.1 patch doesn't
apply.

(I realise it may be trivial to fix it, but we need it tested against
old and new systemd installs etc, so if I can get such a patch it will
be much easier)

Sorry,


There was someone ( Armin ) on this thread that responded this had 
already been applied upstream since last summer which inconsistent with 
the current status of the bug in your tracker and your response and I 
think it's safe to assume you know better anyway you are aware of what's 
about to take place and need to adjust accordingly as do rest of 
downstreams that still might be using/relying on this although ( thus 
far ) samba seems to be the only affected by this change.


JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Armin K.]

On 11.02.2016 21:04, Jóhann B. Guðmundsson wrote:
> 
> 
> On 02/11/2016 05:34 PM, Zbigniew Jędrzejewski-Szmek wrote:
>>> >2) compat support for libsystemd-login.so and friends (these were
>>> >merged into a single libsystemd.so a long time ago). We are still
>>> >building compat libraries to ease the transition, but that was a
>>> >long time ago, hence I'd really love to see this go. Any distro
>>> >still using this?
>> Fedora;)
>> https://bugzilla.redhat.com/show_bug.cgi?id=1125086
>> But looking athttps://bugzilla.samba.org/show_bug.cgi?id=10672#c14
>> maybe it'd be enough to rebuild samba without the compat headers installed.
>>
> 
> The upstream bug is few months short of it's 2 year anniversary and this move 
> will just get the samba developers to apply the patch in that upstream report 
> and close that bug.
> 
> Andrew is there any reason the patch in that upstream report has not been 
> applied and samba moved to use libsystemd.so?

It has been applied at least since the last summer.



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Michael Biebl]

2016-02-11 18:06 GMT+01:00 Lennart Poettering :
> Heya!
>
> So I am thinking about some spring cleaning, and would love to remove
> the following bits from the systemd package:
>
> 1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
>time Debian was still using that, maybe this changed now?

Debian still uses that, yes. Is this causing any maintenance issues?
It's a pretty isolated component after all.


> 2) compat support for libsystemd-login.so and friends (these were
>merged into a single libsystemd.so a long time ago). We are still
>building compat libraries to ease the transition, but that was a
>long time ago, hence I'd really love to see this go. Any distro
>still using this?

As Martin already pointed out, we dropped the comapt libs a while ago.

> 3) systemd-reply-password – this is really old stuff used by the GNOME
>ask-password stuff which was experimental at best, and never found
>much use. Unless am very wrong pretty much nobody is using this,
>and we can just kill this without replacement. Anybody knows a user
>of this that I am not aware of?

Not actually sure what this tool is actually supposed to do and why it
was added in the first place.
Does GNOME shell implement the password agent interface now natively?

> 5) Here's the controversial one I think: support for booting up
>without /var. We have kludges at quite a few places because we
>cannot access /var early during boot. I am tempted to stop
>supporting this altogether. Of course, this does *not* mean that
>people with split off /var would be left in the cold. It just means
>that they have to mount /var from the initrd, exactly like this is
>already handled from /usr.

I'm worried about this one. /var can hold a lot of data and is often
backed by complex setups (iSCSI, nbd, involving remote access).
Pulling all that into the initramfs seems like a huge amount of work.
Can you enumerate the problems that a split-off of /var is causing?


> 6) The .snapshot unit type. These sounded like a smart idea, I am
>pretty sure though nobody is using them properly, and they are
>pretty hard to use. If anything like this should exist at al, then
>probably as a concept of "transient targets", but not as a separate
>unit type. Anyone knows any real users of this stuff?

Seems fine to drop.

Michael



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Reindl Harald]

Am 11.02.2016 um 20:37 schrieb Jóhann B. Guðmundsson:

Arguably you should chop away the environment files support in the
process since you are already wielding the axe...


no - damned there are a ton of reasons to use them where it *do not 
matter* if you would do whatever this way or not


they can be shared between a dozens sepearated but related local 
services what you can't do with systemd snippets


please refrain from propose remove *useful* featzres with *zero* 
maintaince costs just because *you* won't use them - just don't use them 
and you are done but stop trying to dicatate the world how all others 
have to configure their systems - it's NOT your business




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Jóhann B . Guðmundsson]

On 02/11/2016 08:41 PM, Armin K. wrote:

On 11.02.2016 21:04, Jóhann B. Guðmundsson wrote:


On 02/11/2016 05:34 PM, Zbigniew Jędrzejewski-Szmek wrote:

2) compat support for libsystemd-login.so and friends (these were
merged into a single libsystemd.so a long time ago). We are still
building compat libraries to ease the transition, but that was a
long time ago, hence I'd really love to see this go. Any distro
still using this?

Fedora;)
https://bugzilla.redhat.com/show_bug.cgi?id=1125086
But looking athttps://bugzilla.samba.org/show_bug.cgi?id=10672#c14
maybe it'd be enough to rebuild samba without the compat headers installed.


The upstream bug is few months short of it's 2 year anniversary and this move 
will just get the samba developers to apply the patch in that upstream report 
and close that bug.

Andrew is there any reason the patch in that upstream report has not been 
applied and samba moved to use libsystemd.so?

It has been applied at least since the last summer.


If that's the case the samba community does not close open bugs as 
fixed, what a waste of time that must be for everybody anyway then the 
only concern ( thus far ) has already been fixed upstream.


JBG

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Reindl Harald]

Am 11.02.2016 um 22:11 schrieb Martin Pitt:

Martin Pitt [2016-02-11 21:59 +0100]:

This would apply if you boot with systemd, then install sysvinit, and
want to reboot the machine (using SysV's /sbin/reboot), right? Or the
other way around?

This is still somewhat relevant for Debian, but maybe there's
something simpler that can be done for that case? If there's any other
way to reboot the machine in that situation, it can also become
documentation.


... I figure "systemctl reboot" should do?


"reboot -f" helped a lot for the *one time change* as systemd was 
introdocued into Fedora long ago.




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Lennart Poettering]

On Thu, 11.02.16 20:48, Andrei Borzenkov (arvidj...@gmail.com) wrote:

> 11.02.2016 20:06, Lennart Poettering пишет:
> > 
> > 5) Here's the controversial one I think: support for booting up
> >without /var. We have kludges at quite a few places because we
> >cannot access /var early during boot. I am tempted to stop
> >supporting this altogether. Of course, this does *not* mean that
> >people with split off /var would be left in the cold. It just means
> >that they have to mount /var from the initrd, exactly like this is
> >already handled from /usr. 
> > 
> 
> Does it apply to whole /var, to each part of /var or to specific subdirs
> in /var? In openSUSE various subtrees under /var are split off in
> individual volumes on btrfs, forcing mounting them all in initrd is not
> much appealing.

btrfs's subvolumes are pretty nice as they are just special
directories. There's no need to mount them in any special way.

That said, this is about /var/log and these kinds of things. If some
random late-boot package needs something under /var (let's say mysql
needs /var/lib/mysql), then systemd really doesn't care about it...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Andrei Borzenkov]

11.02.2016 20:52, Lennart Poettering пишет:
> On Thu, 11.02.16 20:48, Andrei Borzenkov (arvidj...@gmail.com) wrote:
> 
>> 11.02.2016 20:06, Lennart Poettering пишет:
>>>
>>> 5) Here's the controversial one I think: support for booting up
>>>without /var. We have kludges at quite a few places because we
>>>cannot access /var early during boot. I am tempted to stop
>>>supporting this altogether. Of course, this does *not* mean that
>>>people with split off /var would be left in the cold. It just means
>>>that they have to mount /var from the initrd, exactly like this is
>>>already handled from /usr. 
>>>
>>
>> Does it apply to whole /var, to each part of /var or to specific subdirs
>> in /var? In openSUSE various subtrees under /var are split off in
>> individual volumes on btrfs, forcing mounting them all in initrd is not
>> much appealing.
> 
> btrfs's subvolumes are pretty nice as they are just special
> directories. There's no need to mount them in any special way.
> 

There is, but this is off topic here.

> That said, this is about /var/log and these kinds of things. If some

You will need to be specific, which kind of things then. And yes,
/var/log is mount point by default as well. Please if you are going to
drop support for these things being mount point, list them precisely and
exhaustively.

> random late-boot package needs something under /var (let's say mysql
> needs /var/lib/mysql), then systemd really doesn't care about it...
> 
> Lennart
> 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Matthias Urlichs]

On 11.02.2016 18:49, Lennart Poettering wrote:
> Again: this does not break systems with split off /var, as I tried to
> make very clear in my original mail. All that's needed is that the
> initrd mounts /var before handing off control to the main system.
I know that. Please don't assume that I misunderstood you just because
every systemd-basher during the last five years did the same thing. :-P

However, it *does* break systems which do not mount /var in their initrd
despite having /var (or a piece thereof) split off.
Such changes should have a "deprecated" phase between "works fine" and
"needs manual intervention".

The number of such systems is definitely not zero. In addition to
multi-boot machines with shared /var/{log,tmp,cache} sub-mounts, there's
the "somewhat-embedded system with root on SDHC card and /var on hard
disk / NFS / whatever" usecase. Some of these may not even *have* an initrd.

-- 
-- Matthias Urlichs
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Zbigniew Jędrzejewski-Szmek]

On Thu, Feb 11, 2016 at 06:06:45PM +0100, Lennart Poettering wrote:
> Heya!
> 
> So I am thinking about some spring cleaning, and would love to remove
> the following bits from the systemd package:
> 
> 1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
>time Debian was still using that, maybe this changed now?
> 
> 2) compat support for libsystemd-login.so and friends (these were
>merged into a single libsystemd.so a long time ago). We are still
>building compat libraries to ease the transition, but that was a
>long time ago, hence I'd really love to see this go. Any distro
>still using this?
Fedora ;)
https://bugzilla.redhat.com/show_bug.cgi?id=1125086
But looking at https://bugzilla.samba.org/show_bug.cgi?id=10672#c14
maybe it'd be enough to rebuild samba without the compat headers installed.

> 3) systemd-reply-password – this is really old stuff used by the GNOME
>ask-password stuff which was experimental at best, and never found
>much use. Unless am very wrong pretty much nobody is using this,
>and we can just kill this without replacement. Anybody knows a user
>of this that I am not aware of?
> 
> 4) Capabilities= support, i.e. the non-ambient and non-bounding-set kind
>of capabilities. They are pretty useless, as fcaps reduce them to
>nothing in pretty much all cases, which is precisely why the
>ambient caps were created. I am pretty sure nothing uses this, as
>it's not realistic to use this at all.
> 
> 5) Here's the controversial one I think: support for booting up
>without /var. We have kludges at quite a few places because we
>cannot access /var early during boot. I am tempted to stop
>supporting this altogether. Of course, this does *not* mean that
>people with split off /var would be left in the cold. It just means
>that they have to mount /var from the initrd, exactly like this is
>already handled from /usr. 
Dunno, this is a very visible change. How big are the benefits?

> 6) The .snapshot unit type. These sounded like a smart idea, I am
>pretty sure though nobody is using them properly, and they are
>pretty hard to use. If anything like this should exist at al, then
>probably as a concept of "transient targets", but not as a separate
>unit type. Anyone knows any real users of this stuff?
Already gone: 36b4a7ba555

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Lennart Poettering]

On Thu, 11.02.16 17:34, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> On Thu, Feb 11, 2016 at 06:06:45PM +0100, Lennart Poettering wrote:
> > Heya!
> > 
> > So I am thinking about some spring cleaning, and would love to remove
> > the following bits from the systemd package:
> > 
> > 1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
> >time Debian was still using that, maybe this changed now?
> > 
> > 2) compat support for libsystemd-login.so and friends (these were
> >merged into a single libsystemd.so a long time ago). We are still
> >building compat libraries to ease the transition, but that was a
> >long time ago, hence I'd really love to see this go. Any distro
> >still using this?
> Fedora ;)
> https://bugzilla.redhat.com/show_bug.cgi?id=1125086
> But looking at https://bugzilla.samba.org/show_bug.cgi?id=10672#c14
> maybe it'd be enough to rebuild samba without the compat headers
> >installed.

As long as it's only one package I am happy to break this I must say...

> 
> > 5) Here's the controversial one I think: support for booting up
> >without /var. We have kludges at quite a few places because we
> >cannot access /var early during boot. I am tempted to stop
> >supporting this altogether. Of course, this does *not* mean that
> >people with split off /var would be left in the cold. It just means
> >that they have to mount /var from the initrd, exactly like this is
> >already handled from /usr. 
>
> Dunno, this is a very visible change. How big are the benefits?

Well, there's no single big benefit, just a lot of small ones
everywhere. We can drop deps from various units, we can do clock
bumping via timestamp files from PID1 and things like that. We could
properly order log message from the PID1 invocation on on systems
lacking an RTC, and so on.

> 
> > 6) The .snapshot unit type. These sounded like a smart idea, I am
> >pretty sure though nobody is using them properly, and they are
> >pretty hard to use. If anything like this should exist at al, then
> >probably as a concept of "transient targets", but not as a separate
> >unit type. Anyone knows any real users of this stuff?
> Already gone: 36b4a7ba555

Fun! I am an idiot!

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Matthias Urlichs]

Hi,

Lennart Poettering:
> 5) Here's the controversial one I think: support for booting up
>without /var.

Meh. I have quite a few multi-boot systems with a common /var/log
partition. Plus, unlike the other "spring cleaning" changes this would
cause a boot failure after update.

Thus: if you must, deprecate this now, but please leave the actual code
alone until next spring.

-- 
-- Matthias Urlichs
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Andrei Borzenkov]

11.02.2016 20:06, Lennart Poettering пишет:
> 
> 5) Here's the controversial one I think: support for booting up
>without /var. We have kludges at quite a few places because we
>cannot access /var early during boot. I am tempted to stop
>supporting this altogether. Of course, this does *not* mean that
>people with split off /var would be left in the cold. It just means
>that they have to mount /var from the initrd, exactly like this is
>already handled from /usr. 
> 

Does it apply to whole /var, to each part of /var or to specific subdirs
in /var? In openSUSE various subtrees under /var are split off in
individual volumes on btrfs, forcing mounting them all in initrd is not
much appealing.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel