XDM to systemd Conversion (and other units)

Looking through the wiki it seems that there is a known issue of several areas that haven’t been converted over to systemd yet, a prime one being xdm. This would be nice because then you could use systemd to control the display manager. It seems odd to me that openSUSE was one of the first distros to move over to systemd, but it still has a mix of init scripts and systemd. It seems other distros are further along in the conversion process.

Does anyone know the progress on moving display manager control to systemd?

Old-style init scripts are supported by systemd, and you can use systemctl to control the xdm.service. Otherwise openSUSE wouldn’t even boot to a graphical system…

Regarding the xdm service you specifically asked for:
In Factory (and 13.2 therefore) there actually is a systemd-native displaymanager.service already:

So that should answer your question.

If you mean something else, please clarify.

Regarding the mix of sysvinit scripts and systemd units, there’s no need to hurry because systemd does support init scripts as I wrote already.
But AFAIK new packages are only accepted if they have native systemd units. The existing ones will of course be migrated over time as it is feasible.
Although I think most relevant services have been migrated already.
Of course the situation looks a bit better again on Factory/13.2 in comparison to 13.1 regarding this… :wink:

I guess I’ referring to similar to the full way Arch does it. Each display manager has a .service file, so you enable/disable them via systemctl rather than having to edit a separate file under sysconfig or via YAST.

So, to switch between KDM and LigthDM, you would:

systemctl disable kdm.service
systemctl enable lightdm.service

And unless it’s out’s date, the wiki listed I think 6 main services that haven’t been converted over fully yet, and some seem pretty fundamental to the system. Of course, it could be outdated as I said, or I could be missing something. I don’t really know much about init.

And man, Wolfi, you’re ALL over these forums. :slight_smile: I think you’re the one answering most every question.

And how would that be easier than just changing the displaymanager in /etc/sysconfig/displaymanager (either with a text editor or YaST)? :wink:
The advantage of that is also that there will be a fallback if the selected displaymanager cannot be started for some reason.

And what happens on Arch if you forget to disable kdm.service in your example?

I don’t think there are any plans to change that to Arch’s way, and personally I don’t see a point either.

And unless it’s out’s date, the wiki listed I think 6 main services that haven’t been converted over fully yet, and some seem pretty fundamental to the system. Of course, it could be outdated as I said, or I could be missing something. I don’t really know much about init.

Could you point me to that Wiki?
Or at least list those 6 “main” services?

As I said, they might have been migrated in Factory already.
E.g. sshd and mysql, both of which only have sysvinit scripts on 13.1, ship with native systemd units in Factory.
But again, still having sysvinit scripts is not really a problem.

The point is consistency. If openSUSE is switching to use systemd, why not actually use it, rather than using half of it, and half of the old init system with small fixes to make it systemd compatible. It just doesn’t make sense. I’m not really an Arch user, but converting everything over seems more efficient and consistent (or convert nothing over). Why should one style of configuration be used for one system setting and another for another type (especially when it’s already partially controlled by systemd in the case of xdm)? Why should people have to remember which system component can be changed via systemd and which still has to edit config files?

That’s just confusing, especially when there isn’t a lot of documentation out. I was previously using Ubuntu more, which had a gconf/dconf setting for the display manager. On openSUSE, I figured it would be all systemd, so I tried those commands, but had to find out why when I installed a new DM it wasn’t working. Only reference in the openSUSE wiki I could find was on the KDM page where it told how to enable KDM (which of course, led to the place to change it to any DM).

And I have no idea what happens if you forget to disable the previous display manager. I might guess you don’t need to, as since the display manager is provided via a symlink to the desired DM, it would probably just overwrite the symlink and be fine on the next boot. I imagine disabling and enabling a different makes it still work if you just log out rather than reboot.

https://en.opensuse.org/openSUSE:Systemd_status

  • apparmor
  • cycle
  • ipconfig
  • nfs
  • ntp
  • xdm

On 2014-09-24 23:36, TeutonJon78 wrote:

>> I don’t think there are any plans to change that to Arch’s way, and
>> personally I don’t see a point either.
>
> The point is consistency. If openSUSE is switching to use systemd, why
> not actually use it, rather than using half of it, and half of the old
> init system with small fixes to make it systemd compatible. It just
> doesn’t make sense. I’m not really an Arch user, but converting
> everything over seems more effecient and consistent (or convert nothing
> over). Why should one style of configuration be used for one system

Because it is more consistent with *suse usage. *suse users are less
surprised by keeping the configuration where it is.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

On 2014-09-24 23:36, TeutonJon78 wrote:
>
> wolfi323;2666195 Wrote:
>> And how would that be easier than just changing the displaymanager in
>> /etc/sysconfig/displaymanager (either with a text editor or YaST)? :wink:
>> The advantage of that is also that there will be a fallback if the
>> selected displaymanager cannot be started for some reason.
>>
>> And what happens on Arch if you forget to disable kdm.service in your
>> example?

The *suse way also has a caveat: if you change the setting, while it is
running, and then you try to restart it, you get a problem: stopping the
service tries to stop the new one, which is not running, so the old one
is left running. Then it tries to start the new one, colliding with the
old one.

(I have not tried to do this in a long time, though)

Besides that, openSUSE 13.1 has an old style rckdm script, since ever,
but not one for LigthDM.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

To me, the point is that old adage:

  • If it ain’t broke, don’t fix it.

Those are horrible reasons. By that logic, openSUSE should have never even switched to systemd (especially since it was one the first). The old init was working. Same logic for taking in any new piece of software. Why make Yast2 then?

Things evolve and change. Since SUSE moved to systemd, why not finish the move and actually completely use it? I’d say the lack of consistency is harder to learn than having people just be able to say “Oh, I can’t find that part, it must have moved to systemd along with everything else system related”.

On 2014-09-25 04:06, TeutonJon78 wrote:

> Things evolve and change. Since SUSE moved to systemd, why not finish
> the move and actually completely use it? I’d say the lack of consistency

It is not lack of consistency. It is consistency with the SUSE way of
doing things.

We do not have to keep consistency with others, but with ourselves.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

On 09/24/2014 04:36 PM, TeutonJon78 wrote:
>
…snip…
You are making huge assumptions about what is right and what is wrong.

However, if you feel another distribution has it right and openSUSE has it
wrong… that’s ok. But I don’t think you can’t really condemn a particular
distribution’s approach over another. But we’re all learning… and that’s ok
as well. Maybe openSUSE will learn something from those distributions that get
everything right? (but maybe, must maybe, other distributions will learn from
openSUSE… miracles happen…)

True, I remember that as well.
But I haven’t tried it in a long time either.

But the same would happen when you have a separate systemd unit for each one.
E.g. if you run “systemctl start lightdm” when kdm is already running, kdm will not be quit I suppose.
You would have to manually stop the old one with “systemctl stop kdm” first.

Besides that, openSUSE 13.1 has an old style rckdm script, since ever,
but not one for LigthDM.

Yes, it has rckdm, but that’s just a symlink:

wolfi@amiga:~> ls -l /usr/sbin/rckdm 
lrwxrwxrwx 1 root root 5 19. Sep 11:24 /usr/sbin/rckdm -> rcxdm
wolfi@amiga:~> ls -l /usr/sbin/rcxdm 
lrwxrwxrwx 1 root root 15 27. Aug 17:16 /usr/sbin/rcxdm -> /etc/init.d/xdm
wolfi@amiga:~> 

So when you run rckdm, you actually run /etc/init.d/xdm.
This is on 13.1 of course.
On Factory /usr/sbin/rcxdm just calls /usr/sbin/rcdisplay-manager, which is linked to /usr/sbin/service which redirects to systemctl.

But respecting certain config files in /etc/sysconfig/ (or wherever) has absolutely nothing to do with using systemd or sysvinit.

Other services (systemd native) also do this on openSUSE, like Apache or lm_sensors.
And importing such a config file is actually natively supported by systemd.

I do agree with what others posted here. (open)SUSE has to keep some compatibility to itself.
It would be a disaster if half of your configuration is not respected any more after an upgrade to the next (open)SUSE version.

https://en.opensuse.org/openSUSE:Systemd_status

  • apparmor
  • cycle
  • ipconfig
  • nfs
  • ntp
  • xdm

Well, personally I wouldn’t consider that to be the 6 main services. 4 of them are not even enabled on my system… :wink:
But that’s how the situation is on Factory/13.2:

  • ntp has a native systemd unit
  • nfs and nfsserver are still old-style init scripts
  • apparmor has not been migrated yet, I remember reading about problems some time ago because the way rcapparmor works is not really compatible with systemd
  • if they mean bootcycle with “cycle”, that seems obsolete anyway, as it only supports grub legacy AFAICS
  • What has ipconfig to do with sysvinit/systemd? If that’s /etc/init.d/network, i.e. the old-style ifup networking, that’s not used any more at all and has been replaced by wicked in Factory/13.2 which does have native systemd units.

So yes, that page is not fully up-to-date regarding this. But as I see it, this list there was never intended to show the current/up-to-date status.
And a user shouldn’t really have to care about this anyway. You can enable/disable/start/stop old-style init scripts in the same way as native systemd units, i.e. with systemctl.

You keep mentioning the SUSE way. Care to provide a link? I’ve never even heard of this. The only “way” I’ve heard of is the Arch way, because they seem to be rather … particular … about certain things.

The only assumption I’m making is that when there is a major system architecture overhaul, it should be complete, rather than piecemeal and leaving different parts under different control when they COULD all be the same.

I don’t particularly like Arch, I think they make things arbitrarily difficult. openSUSE is my current distro of choice, and I’m trying to understand why they doing the init switchover only partially. Just making systemd wrappers for old scripts when they could be fully converted, seems like a wrong way to go for the long term.

On 2014-09-25 09:36, TeutonJon78 wrote:

> You keep mentioning the SUSE way. Care to provide a link?

Nope. Just trust me on it. :wink:


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

“I told you so” is not a valid technical answer, which is what I asked for throughout this thread, not dogma. Just because it’s done a certain way, doesn’t make it valid or right. This is a technical product, and should have technical reasons.

So far, only Wolfi has had anything resembling a technical answer.

On 2014-09-25 20:16, TeutonJon78 wrote:
>
> robin_listas;2666361 Wrote:
>> On 2014-09-25 09:36, TeutonJon78 wrote:
>>
>>> You keep mentioning the SUSE way. Care to provide a link?
>>
>> Nope. Just trust me on it. :wink:

> “I told you so” is not a valid technical answer, which is what I asked
> for throughout this thread, not dogma. Just because it’s done a certain
> way, doesn’t make it valid or right. This is a technical product, and
> should have technical reasons.

I can not point you to a document confirming what I said above. But, I
have been working with openSUSE many years. As an old hand, I know many
things, and I have forgotten more.

So, if I tell you that there is such a thing as “the SUSE way”, it is
because I really know.

You can choose to believe me or not. Up to you.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)