On 08/30/2012 07:30 PM, baker.stephen.e@gmail.com wrote:

On August 31, 2012 02:06:56 AM Mathieu R. wrote:

...

Last update (10 minutes ago) asked me if y want switch from libsystemd to core/systemd. I agreed, and on next reboot, networkmanager was not started automaticly from rc.conf. it work well if y start it by hand (/etc/rc.d/networkmanager start).

Does it work if you use systemctl to enable it on boot instead? systemctl enable NetworkManager.service

Mathieu, Are you using initscripts or systemd?

On Fri, 2012-08-31 at 09:30 +0200, Mathieu R. wrote:

2012/8/31 Matthew Monaco :

...

On 08/30/2012 07:30 PM, baker.stephen.e@gmail.com wrote:

...

On August 31, 2012 02:06:56 AM Mathieu R. wrote:

...

Last update (10 minutes ago) asked me if y want switch from libsystemd to core/systemd. I agreed, and on next reboot, networkmanager was not started automaticly from rc.conf. it work well if y start it by hand (/etc/rc.d/networkmanager start).

Does it work if you use systemctl to enable it on boot instead? systemctl enable NetworkManager.service

Mathieu,

Are you using initscripts or systemd?

i had a working answer on forums, there : https://bbs.archlinux.org/viewtopic.php?pid=1154017#p1154017 thank you.

# pacman -Syu :: Replace libsystemd with core/systemd? [Y/n] # grep DAEMONS /etc/rc.conf DAEMONS=(69switch_xorg.conf hwclock syslog-ng !network !netfs crond acpid dbus networkmanager rtirq) I don't understand "Eliminate the daemons one by one from rc.conf. Start with dbus, which systemd handles very well without any action from you at all". How can I upgrade, but keep a running system? "69switch_xorg.conf" e.g. is a script that switch between 2 xorg.conf regarding to the kernel I boot. If I remove all "daemons" from rc.conf, have I then to set up systemd? Can I simply say "no" regarding to :: Replace libsystemd with core/systemd? [Y/n] n :: Replace systemd-tools with core/systemd? [Y/n] n but say yes regarding to Targets (16): cracklib-2.8.19-1 filesystem-2012.8-1 glibc-2.16.0-4 gnutls-3.1.0-1 imagemagick-6.7.9.2-1 initscripts-2012.08.3-2 khrplatform-devel-8.0.4-3 lib32-gdk-pixbuf2-2.26.3-1 lib32-glibc-2.16.0-4 libdrm-2.4.39-1 libegl-8.0.4-3 libgbm-8.0.4-3 libglapi-8.0.4-3 libwebkit3-1.8.3-1 mesa-8.0.4-3 rpcbind-0.2.0-9 ? I can't see any information at http://www.archlinux.org/ or https://www.archlinux.de/. I'm confused. Regards, Ralf

Thank you Tom :) On Fri, 2012-08-31 at 11:14 +0200, Tom Gundersen wrote:

If you do not wish to switch to systemd yet, then no action is required. See [0] for some details.

I'm not switching yet. First I'll test it in VBox, but at the moment I don't have time to do it, I need a stable Arch Linux. So I'll backup my current install and then upgrade, without changing anything and hope it still will work. If not I'll restore Arch from the backup. IIUC the OP got issues regarding to networkmanager, while not switching to systemd. However, no big deal since I don't need to upgrade at the moment. I can use my Arch without an upgrade now and do the upgrade later, when I've got time to switch to systemd. I don't like to switch, but I guess it will make my live easier. Regards, Ralf

On Fri, 2012-08-31 at 11:34 +0200, Tom Gundersen wrote:

On Fri, Aug 31, 2012 at 11:24 AM, Ralf Mardorf wrote:

...

IIUC the OP got issues regarding to networkmanager, while not switching to systemd.

For the people not reading the forums: it seems the problem was with the order of daemons in rc.conf, and should be unrelated to systemd. For people not using systemd, this change should really not have any effect at all (you'll just have some extra unused files around).

And I didn't understand it/misunderstand it. Ok, now I understand and know what to do :). Regards, Ralf

On 31/08/12 20:44, Kevin Chadwick wrote:

...

...

IIUC the OP got issues regarding to networkmanager, while not switching to systemd.

For the people not reading the forums: it seems the problem was with the order of daemons in rc.conf, and should be unrelated to systemd. For people not using systemd, this change should really not have any effect at all (you'll just have some extra unused files around).

While the cause has been explained I think we are missing the Why or is it How.

If dbus was out of order how come it worked under initscripts? Is it because initscripts checks the list and starts dbus early in any case and the init script compatibility over-rid systemds similar behaviour?

He is not using systemd at all... So the upgrade of systemd is a red-herring here. Allan

...

While the cause has been explained I think we are missing the Why or is it How.

If dbus was out of order how come it worked under initscripts?

I have honestly no idea why the setup used to work (it never should have), and what made it stop working (nothing should have changed). Notice that the OP is still using initscripts. My best guess is there was a race and somehow something sped-up or slowed down to make it trigger.

And this is yet another example how initscripts are broken. I had a friend whose GDM was not coming up because it was starting too fast after dbus. As a last resort we rearranged the DAEMONS and moved gdm as the last daemon (after NM etc) and it magically started to work. With systemd you could start gdm as fast as you want and systemd would make sure its dependencies are met, either by starting them first, or buffering the socket/dbus calls. -- damjan

On Fri, Aug 31, 2012 at 03:30:43PM +0200, Ralf Mardorf wrote:

On Fri, 2012-08-31 at 13:51 +0200, Damjan Georgievski wrote:

...

And this is yet another example how initscripts are broken. I had a friend whose GDM was not coming up because it was starting too fast after dbus. As a last resort we rearranged the DAEMONS and moved gdm as the last daemon (after NM etc) and it magically started to work. I use GDM too, but it's not in the DAEMONS list.

[root@archlinux spinymouse]# grep DAEMONS /etc/rc.conf # DAEMONS DAEMONS=(69switch_xorg.conf hwclock syslog-ng !network !netfs crond acpid dbus networkmanager rtirq) [root@archlinux spinymouse]# pacman -Qi gdm Name : gdm Version : 3.4.1-3

*?*

You probably use the inittab method https://wiki.archlinux.org/index.php/Display_Manager#inittab_method

It is disrespectful not to honor that initscripts is something good, even if there should be something better now.

Don't listen, it isn't better, shell is awesome and so are init scripts though a top notch consensus would be good. I can point out multiple errors and wrong assumptions in just the first few paragraphs on the systemd blog link that was posted again recently but I've had enough time wasted on something that I've come to see as likely to fail or get any more distro coverage. I don't think Lennart has much unix admin experience. I'm not saying don't switch, you will get better support for systemd on this list that's for sure. I will give one example. Lennart says come on who connects to sshd more than once a month. I can't believe he's never seen a sshd log with constant pass attempts even though passwords are disabled. Be honest Tom, do you think it is less or more risky timewise for him to switch, right now? -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________

...

I will give one example. Lennart says come on who connects to sshd more than once a month. I can't believe he's never seen a sshd log with constant pass attempts even though passwords are disabled.

You are misunderstanding the sshd example.

How? Systemds method would seem more problematic and wasteful to me if you get connections to it a lot. Home connections even get many ssh connection attempts and in any case it would seem to show he has no experience in administration. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________

On Aug 31, 2012 7:47 PM, "Kevin Chadwick" wrote:

...

...

...

I will give one example. Lennart says come on who connects to sshd

more

...

...

...

than once a month. I can't believe he's never seen a sshd log with constant pass attempts even though passwords are disabled.

You are misunderstanding the sshd example.

How? Systemds method would seem more problematic and wasteful to me if you get connections to it a lot.

The example explicitly only deals with the case where you do not get a lot of connections. E.g. in a private network.

"And even SSH: as long as nobody wants to contact your machine there is no need to run it, as long as it is then started on the first connection. (And admit it, on most machines where sshd might be listening somebody connects to it only every other month or so.)" Your just making stuff up now to cover his back, which questions many of your many baseless responses simply stating I have shown I don't understand systemd, end of discussion. It is far less likely that ssh is used behind a firewall and there is no mention of this, it is a fact that ssh is primarily used to cross the internet where it will be connected to frequently on any connection as long as it is set to the recommended default port.

...

Home connections even get many ssh connection attempts

If you have a pubic IP you'd be better off using the regular service and not the xinet-style one.

Tom

The point is that much of his spec like bringing linux together and assumptions are wrong and significant sacrifices for speed bring tiny speed increases. Here's another assumption. "A central part of a system that starts up and maintains services should be process babysitting: it should watch services. Restart them if they shut down." Wrong, few want this feature and respawn and especially baby sitting is not a central feature of 'services' for an init system. On single web server this may be desired and a user installs a small package to do so that has features systemd hasn't and shouldn't have. In most cases it isn't true and if you have redundant services as most do or a secure service, you don't want the service restarted as it may have been exploited, the restart may even enable the exploit, so another server will take over instead. Right, you've got me to waste more time than I wished, so no more. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________

On Sat, Sep 1, 2012 at 8:46 AM, Kevin Chadwick wrote:

...

On Aug 31, 2012 7:47 PM, "Kevin Chadwick" wrote:

...

...

...

I will give one example. Lennart says come on who connects to sshd

more

...

...

...

than once a month. I can't believe he's never seen a sshd log with constant pass attempts even though passwords are disabled.

You are misunderstanding the sshd example.

How? Systemds method would seem more problematic and wasteful to me if you get connections to it a lot.

The example explicitly only deals with the case where you do not get a lot of connections. E.g. in a private network.

"And even SSH: as long as nobody wants to contact your machine there is no need to run it, as long as it is then started on the first connection. (And admit it, on most machines where sshd might be listening somebody connects to it only every other month or so.)"

Your just making stuff up now to cover his back, which questions many of your many baseless responses simply stating I have shown I don't understand systemd, end of discussion.

It is far less likely that ssh is used behind a firewall and there is no mention of this, it is a fact that ssh is primarily used to cross the internet where it will be connected to frequently on any connection as long as it is set to the recommended default port.

i highly doubt you, Lennart, or anyone else for that matter has any real numbers to support anything being said, so please, spare me. now, IME, both privately and in the numerous IT-based companies i've both worked and/or consulted with ... there are indeed usually MANY servers that happily run sshd all day long, and do not receive connections unless there is a problem. regardless, Lennart's only point was "sshd should only start when someone tries to connect" ... let's not beat around the bush here, mmk? ... and a connection attempt is very different from a connection. if you really want to block the former, then you use something like fwknopd to make the sshd port invisible to everyone except the authorized. i use this on all my servers -- it's fantastic.

...

...

Home connections even get many ssh connection attempts

If you have a pubic IP you'd be better off using the regular service and not the xinet-style one.

The point is that much of his spec like bringing linux together and assumptions are wrong and significant sacrifices for speed bring tiny speed increases.

... tell me, have you actually ran systemd yet? hmm ...

Here's another assumption.

"A central part of a system that starts up and maintains services should be process babysitting: it should watch services. Restart them if they shut down."

Wrong, few want this feature and respawn and especially baby sitting is not a central feature of 'services' for an init system.

ehm, of the whopping 3 or so things sysvinit actually DID for you, wasn't respawn one of them? you seem to want an init that does nothing at all -- and since shell is "like teh coolest thing eva .. eva", i suggest writing one in bash! it's not hard, and like i said in the past, i wrote one for LXC based systems that was ~20-30 lines, FULLY replacing sysvinit (well, i used that until systemd started to work nicely ;-)

On single web server this may be desired and a user installs a small package to do so that has features systemd hasn't and shouldn't have.

*yawn*

In most cases it isn't true and if you have redundant services as most do or a secure service, you don't want the service restarted as it may have been exploited, the restart may even enable the exploit, so another server will take over instead.

# systemctl stop <exploited>.service [and optionally] # systemctl disable <exploited>.service ... problem solved?

Right, you've got me to waste more time than I wished, so no more.

nah friend, you did this to yourself -- no one made you do anything. -- C Anthony

On Mon, Sep 03, 2012 at 11:46:14AM +0100, Kevin Chadwick wrote:

...

On Sat, Sep 1, 2012 at 8:46 AM, Kevin Chadwick wrote:

...

...

On Aug 31, 2012 7:47 PM, "Kevin Chadwick" wrote:

...

...

> I will give one example. Lennart says come on who connects to sshd

more

...

...

> than once a month. I can't believe he's never seen a sshd log with > constant pass attempts even though passwords are disabled.

You are misunderstanding the sshd example.

How? Systemds method would seem more problematic and wasteful to me if you get connections to it a lot.

The example explicitly only deals with the case where you do not get a lot of connections. E.g. in a private network.

"And even SSH: as long as nobody wants to contact your machine there is no need to run it, as long as it is then started on the first connection. (And admit it, on most machines where sshd might be listening somebody connects to it only every other month or so.)"

Your just making stuff up now to cover his back, which questions many of your many baseless responses simply stating I have shown I don't understand systemd, end of discussion.

It is far less likely that ssh is used behind a firewall and there is no mention of this, it is a fact that ssh is primarily used to cross the internet where it will be connected to frequently on any connection as long as it is set to the recommended default port.

i highly doubt you, Lennart, or anyone else for that matter has any real numbers to support anything being said, so please, spare me.

That would be obvious to anyone with any experience. Show me data that says sshd is used more often behind firewalls. Of course it isn't. What data that there are far more remote hosting than local hosting, of course there is, you shouldn't need data to accept this point. Just check your logs. I'd hope that if you run a daemon, you expect someone to connect to it.

I recently worked for a large international compay who provided security appliances to filter web requests,block spam, filter virus', archive email & more but these appaliances use ssh clustering where by your company purchases 4 spam & virus filter from my old employer all 4 of these appliances are linked via ssh so you only need to make changes to 1 of the 4 linked units & these changes are replicated VIA SSH & for those wishing to can connect these appliances to my employers central server farm in US & one can login to a web based admin console & make changes there which again is replicated via ssh. To add to that when a customer reqiures support this is provided via ssh. my ex-employer are market leaders in these appliance and literally have thousands scaretterd accross the globe which i think should prove that ssh is very much in use publicly & behind firewalls!

...

now, IME, both privately and in the numerous IT-based companies i've both worked and/or consulted with ... there are indeed usually MANY servers that happily run sshd all day long, and do not receive connections unless there is a problem.

Are these public facing on the default port as is most cases because in that case you must be looking at auth successes and not failures. Just look up why it is best to use public key and disable passwords. IT-based companies, please do they still suggest ftp for web upload by default.

...

regardless, Lennart's only point was "sshd should only start when someone tries to connect" ... let's not beat around the bush here, mmk?

... and a connection attempt is very different from a connection. if you really want to block the former, then you use something like fwknopd to make the sshd port invisible to everyone except the authorized. i use this on all my servers -- it's fantastic.

Funny how systemd advocates never seem to get the points. I don't want to block anything, that's what sshd does anyway without adding extra less audited crypto. You realise a server running openssl is more vulnerable to exploits than one without, right?

Are you going to miss the point and bring up web code now.

...

...

...

...

Home connections even get many ssh connection attempts

If you have a pubic IP you'd be better off using the regular service and not the xinet-style one.

The point is that much of his spec like bringing linux together and assumptions are wrong and significant sacrifices for speed bring tiny speed increases.

... tell me, have you actually ran systemd yet? hmm ...

Only on Fedora which takes longer to boot than my arch but that's irrelevant. I think the potential of speed increase has quite clearly been determined to be in the < 3 seconds range ignoring the stupid argument of what if something pauses.

...

...

Here's another assumption.

"A central part of a system that starts up and maintains services should be process babysitting: it should watch services. Restart them if they shut down."

Wrong, few want this feature and respawn and especially baby sitting is not a central feature of 'services' for an init system.

ehm, of the whopping 3 or so things sysvinit actually DID for you, wasn't respawn one of them?

That's why I said services. I wouldn't call getty, a service myself and you ignore baby sitting not being a central feature. You could argue a supervise service perhaps, but it's not a central feature.

...

you seem to want an init that does nothing at all -- and since shell is "like teh coolest thing eva .. eva", i suggest writing one in bash! it's not hard, and like i said in the past, i wrote one for LXC based systems that was ~20-30 lines, FULLY replacing sysvinit (well, i used that until systemd started to work nicely ;-)

It was originally DESIGNED to do as little as necessary and that is good design as it must run on every system and maximises UNIX usefullness to all.

...

...

On single web server this may be desired and a user installs a small package to do so that has features systemd hasn't and shouldn't have.

*yawn*

...

In most cases it isn't true and if you have redundant services as most do or a secure service, you don't want the service restarted as it may have been exploited, the restart may even enable the exploit, so another server will take over instead.

# systemctl stop <exploited>.service [and optionally] # systemctl disable <exploited>.service

... problem solved?

Too late, point is unnecessary feature bloat that results in bugs on more systems than need be.

...

...

Right, you've got me to waste more time than I wished, so no more.

nah friend, you did this to yourself -- no one made you do anything.

Trueish

More true as arguing with these simple points shows there is no hope for rational discussion here but many will understand.

-- _______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface'

(Doug McIlroy) _______________________________________________________________________

On Fri, 2012-08-31 at 17:30 +0100, Kevin Chadwick wrote:

Be honest Tom, do you think it is less or more risky timewise for him to switch, right now?

That's a good question. At the moment everything I really need, does work as it should work. If I switch, nothing can become better, but it could be as good as it is now. OTOH are there risks, that something I need won't work anymore? Is systemd ready yet? Please no flame war. I don't use "testing" repositories. I contribute to Linux by testing some software, but I'm not a guinea pig for everything. Startup does work today, will it work after switching to systemd? Is it a safe bet? Regards, Ralf

...

On Fri, 2012-08-31 at 13:51 +0200, Damjan Georgievski wrote:

...

And this is yet another example how initscripts are broken. I had a friend whose GDM was not coming up because it was starting too fast after dbus. As a last resort we rearranged the DAEMONS and moved gdm as the last daemon (after NM etc) and it magically started to work.

Isn't it more likely that dbus and GDM are broken and it should be started last anyway, there's no magic.

...

I use GDM too, but it's not in the DAEMONS list.

[root@archlinux spinymouse]# grep DAEMONS /etc/rc.conf # DAEMONS DAEMONS=(69switch_xorg.conf hwclock syslog-ng !network !netfs crond acpid dbus networkmanager rtirq) [root@archlinux spinymouse]# pacman -Qi gdm Name : gdm Version : 3.4.1-3

*?*

You probably use the inittab method

https://wiki.archlinux.org/index.php/Display_Manager#inittab_method

Will this be an issue for him if he switches to full systemd as it has removed inittab (the one piece of init that all Linux distros had in common). -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________

On Fri, Aug 31, 2012 at 06:58:02PM +0200, Tom Gundersen wrote:

On Aug 31, 2012 6:32 PM, "Kevin Chadwick" wrote:

...

Will this be an issue for him if he switches to full systemd as it has removed inittab

Yes, inittab is ignored. It would be trivial to add support for it via a generator, but I don't know of any reason to. We never really used inittab in Arch.

Just pointing out that I have been using the inittab method since 3 years. It is also mentioned in the arch wiki, and I am sure many people use/used the inittab way.

On Aug 31, 2012 6:31 PM, "Kevin Chadwick" wrote:

...

People are grumbling about this compatibility layer, and I might change/remove it at some point. The reason I still have not ripped it out is that I like the fact that your system will "just work" as before if you add init=/bin/systemd to the kernel command line. Without the compatibility layer you'd have to also enable the relevant services (I guess that's not too much to ask though...).

I think it's asking more than commenting out the DAEMONS line?

I'm not following, what's the question? Tom

On Fri, Aug 31, 2012 at 6:41 PM, Kevin Chadwick wrote:

...

...

...

People are grumbling about this compatibility layer, and I might change/remove it at some point. The reason I still have not ripped it out is that I like the fact that your system will "just work" as before if you add init=/bin/systemd to the kernel command line. Without the compatibility layer you'd have to also enable the relevant services (I guess that's not too much to ask though...).

I think it's asking more than commenting out the DAEMONS line?

I'm not following, what's the question?

Isn't getting rid of the compat layer going to be more work for some (not too much to ask) than those who are grumbling simply commenting out the DAEMONS line?

You know it is not as bad as I thought - I converted two laptops today to full systemd. Both run well after the conversion but I did it in two stages. Here are my notes: Once systemd-sysvinit is installed then initscripts and sysvinit have to be removed first and during the process rc.conf became a pacsave file so the DAEMONS line is no longer at that point after conversion. I hope these notes are helpful. The complete process took 15 minutes in each case! Working from arch systemd wiki Convert rc.conf to systemd compatible form as recommended apart from DAEMON array. Install systemd systemd-arch-units using pacman. Add init=/bin/systemd to end of kernel line in /boot/grub/menu.lst Reboot - initially only console login as it hangs at graphical.target At console hang after boot, hit return to get a login prompt then: Log in as root and do # systemctl enable graphical.target # systemctl enable kdm.service Reboot (by doing systemctl reboot) and get graphical login as normal. Check that all previous daemons from rc.conf now started and if not enable them 1) iptables appears stopped After a question on arch forum it seems that "active(exited)" is the normal status as it is a one-shot service and does not run as a daemon once the rules are loaded and dealt with by the kernel. 2) Seems alsa is legacy via rc.conf - it is running and sound is fine. In second laptop alsa was taken out of the daemon array anyway so not needed 3) cpupower frequency-info shows normal output. 4) For the journal do mkdir /var/log/journal/ and also limit the journalsize to 50M - In /etc/systemd/journald.conf add a line: SystemMaxUse=50M 5) Then needed pacman -R sysvinit initscripts which did a pacsave for /etc/rc.conf and /etc/inittab then pacman -S systemd-sysvcompat The new systemd had already installed when pacman -Syu just before this - 6) Now need to reboot and check daemon load against rc.conf.pacsave DAEMONS=(!hwclock syslog-ng iptables netfs crond sshd cupsd dbus !rpcbind postfix dovecot networkmanager alsa cpupower bluetooth named chrony) Needed: systemctl enable NetworkManager.service systemctl enable cronie.service systemctl enable sshd.service systemctl enable postfix.service systemctl enable dovecot.service systemctl enable named.service systemctl enable chrony.service systemctl enable syslog-ng.service also need: systemctl status iptables.service systemctl enable acpid.service systemctl enable cups.service Now have both syslog-ng in /var/log/messages.log and systemd journal via journalctl Conversion complete. Did the OP do something similar or have different steps? -- mike c