SysVinit 2.90 Released With Fixes & Better Support For Newer Compilers

[oiaohm]

It isnt a watchdog on pid 1 it's invoked by init. Big difference. i misssd the typing with the tablet.if systemd woild run as seperate process as i said earlier then it would msrginally be better.

When I say stub. Everything that would normally go to PID1 is in fact redirect to SMF. Zombie clean up, message to PID1 .... Basically its a slide of hand. SMF under solaris was first planed to be PID1. Big paying contract people complained and they made a stub that effectively there was a process at PID1 but it basically does nothing. PID1 on solaris is just start SMF and redirect everything to it. SMF then starts all services and monitors them and responed to all messages you would think are going to PID1. SMF PID number is made kernel panic as well as PID1. So you know have two PID running that can crash the system. So effectively no different to if it had been left as PID1 in the first place.

Really a stub on PID1 that just redirects everything and then assigned to what it loads kernel painic if what I just loaded failed is no improvement. Its just a change that makes people feel good. SMF vs systemd no much difference. Not being PID1 would make a difference if this mean that SMF could be restarted by PID1 if it crashed or the like but that is not the case. It would be nice if PID1 was a watchdog on systemd and able to restart it if it locked up this would be progress.

Basically you don't want systemd developers coping the under handed stunt the solaris developers did.

[Bsdisbetter]

https://docs.oracle.com/cd/E23824_01...451/dzhaq.html

Nothing like being wrong. SMF is running in background watchdoging services and will even email you if they fail. Really SMF scope is basically the same as systemd PID1 like it or not. Just you don't see it when you trace PID1 because PID1 is a stub. Yes make a few zombies and watch the solaris PID 1 not clean that up. In fact when monitoring SMF you see that it cleans it up. Systemd could look the same if someone decide to be underhanded and add a feature to kernel to redirect zombie pick up and made a stub PID1 that job is basically just start systemd as what solaris PID1 is these days for SMF,

It isnt a watchdog on pid 1 it's invoked by init. Big difference. i misssd the typing with the tablet.if systemd woild run as seperate process as i said earlier then it would msrginally be better.

[oiaohm]

Those traces were 30 sec but merely show the extent of systemd's scope. smf is akin to service on linux with more granularity. It isnt a watchdog for services.

https://docs.oracle.com/cd/E23824_01...451/dzhaq.html

Nothing like being wrong. SMF is running in background watchdoging services and will even email you if they fail. Really SMF scope is basically the same as systemd PID1 like it or not. Just you don't see it when you trace PID1 because PID1 is a stub. Yes make a few zombies and watch the solaris PID 1 not clean that up. In fact when monitoring SMF you see that it cleans it up. Systemd could look the same if someone decide to be underhanded and add a feature to kernel to redirect zombie pick up and made a stub PID1 that job is basically just start systemd as what solaris PID1 is these days for SMF,

[Bsdisbetter]

Those traces are kind of deceptive. If you perform a trace on solaris Service Management Facility(SMF) you will see it is just as active as systemd. To make unix happy solaris developers made a stub for PID1 that basically passes everything over to SMF including zombie process cleanup. So you traced nothing more than a stub on solaris that is why it so quite. So SMF under solaris ends up doing as much as systemd does with the same fatal issue if it crashes.

Yes is a common mistake to perform trace on solaris init and say hey systemd is more active in PID1 and miss that if SMF dies system dies under solaris everything dies and its hidding on a different PID number and SMF doing all the roles that systemd is doing using zones instead of cgroups so just as active.



Its not that black and white.

https://kernelnewbies.org/KernelProjects/usermode-helper-enhancements

Linux kernel does from it drivers request particular processing in userspace. There is code that comes with the kernel.org that has to be built and run in userspace for everything to behave. https://git.kernel.org/pub/scm/utils...git/tree/tools << like this is for modules.

So there are choices not to make init and other parts kernel.org projects. Even in the BSD there are some quite insane ones. Yes major of bsd has agree to central management. History has that coming from the BSD kernel and spread outwards. Torvalds has not spread that control out and has depended on faith. At the start of open source BSD it was a lot more fragmented with a lot more parts not listening to the central management.

Those traces were 30 sec but merely show the extent of systemd's scope. smf is akin to service on linux with more granularity. It isnt a watchdog for services.
i disagree also with the view of bsd. Right from the fork of 386bsd the freebsd team were using kernel and base. Whether its running like a well oiled machine is irrelevant. The fact it's a kernel & base means crap like systemd can't just become defacto everything. Sure freebsd could do sonething similar but i severely doubt it given their views on it.= & adherence to simplicity over dogma.
i understand the separation of user & kernel but this 'excuse' diesn't change the fact userland is basically out of the control of the kernel.

[oiaohm]

DAH. An init is something that starts the system and shuts it down, collecting zombies as they appear. Instead this 'service' does
everything (or at least it will and is progressing to that end). It hijacks the init process in order to scope creep its way into everything.

I can trace Solaris init:
pollsys(0x0806C040, 1, 0xF9DAD9F8, 0x00000000) (sleeping...)
that's it.

I can trace systemd init (from a Centos VM):

epoll_wait(4, [{EPOLLIN, {u32=2821443216, u64=93950936075920}}], 160, -1) = 1
clock_gettime(CLOCK_BOOTTIME, {763, 503855089}) = 0
recvmsg(23, {msg_name(0)=NULL, msg_iov(1)=[{"WATCHDOG=1", 4096}], msg_controllen=32, [{cmsg_len=28, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS, {pid=455, uid=0, gid=0}}], msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 10
open("/proc/455/cgroup", O_RDONLY|O_CLOEXEC) = 20
fstat(20, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1c57330000
read(20, "11:freezer:/\n10:hugetlb:/\n9:blki"..., 1024) = 259
close(20) = 0
munmap(0x7f1c57330000, 4096) = 0
timerfd_settime(13, TFD_TIMER_ABSTIME, {it_interval={0, 0}, it_value={900, 502811000}}, NULL) = 0
epoll_wait(4, [{EPOLLIN, {u32=2821443216, u64=93950936075920}}], 160, -1) = 1
clock_gettime(CLOCK_BOOTTIME, {823, 503763174}) = 0
recvmsg(23, {msg_name(0)=NULL, msg_iov(1)=[{"WATCHDOG=1", 4096}], msg_controllen=32, [{cmsg_len=28, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS, {pid=672, uid=0, gid=0}}], msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 10
open("/proc/672/cgroup", O_RDONLY|O_CLOEXEC) = 20
fstat(20, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1c57330000
read(20, "11:freezer:/\n10:hugetlb:/\n9:blki"..., 1024) = 253
close(20) = 0
munmap(0x7f1c57330000, 4096) = 0
timerfd_settime(13, TFD_TIMER_ABSTIME, {it_interval={0, 0}, it_value={943, 502811000}}, NULL) = 0
epoll_wait(4, [{EPOLLIN, {u32=2821443216, u64=93950936075920}}], 160, -1) = 1
clock_gettime(CLOCK_BOOTTIME, {823, 505130694}) = 0
recvmsg(23, {msg_name(0)=NULL, msg_iov(1)=[{"WATCHDOG=1", 4096}], msg_controllen=32, [{cmsg_len=28, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS, {pid=455, uid=0, gid=0}}], msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 10
open("/proc/455/cgroup", O_RDONLY|O_CLOEXEC) = 20
fstat(20, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1c57330000
read(20, "11:freezer:/\n10:hugetlb:/\n9:blki"..., 1024) = 259
close(20) = 0
munmap(0x7f1c57330000, 4096) = 0

(and on and on it goes)

Those traces are kind of deceptive. If you perform a trace on solaris Service Management Facility(SMF) you will see it is just as active as systemd. To make unix happy solaris developers made a stub for PID1 that basically passes everything over to SMF including zombie process cleanup. So you traced nothing more than a stub on solaris that is why it so quite. So SMF under solaris ends up doing as much as systemd does with the same fatal issue if it crashes.

Yes is a common mistake to perform trace on solaris init and say hey systemd is more active in PID1 and miss that if SMF dies system dies under solaris everything dies and its hidding on a different PID number and SMF doing all the roles that systemd is doing using zones instead of cgroups so just as active.

This is more a sympton of Torvald's control of Linux. He only seems to concern himself with the kernel and its processing environment. There is no central figure (except perhaps RHL) driving or seeking to control. Compare this to another FOSS *BSD, where the control of kernel and base is done by one group within that type of BSD whether it be openbsd, freebsd or netbsd. These are steered and co-ordinated much like commercial OSs like Solaris.

You can take FreeBSD and turn it into GhostBSD but it still will always have that control of user and kernel space via FreeBSD.

Its not that black and white.

https://kernelnewbies.org/KernelProjects/usermode-helper-enhancements

Linux kernel does from it drivers request particular processing in userspace. There is code that comes with the kernel.org that has to be built and run in userspace for everything to behave. https://git.kernel.org/pub/scm/utils...git/tree/tools << like this is for modules.

So there are choices not to make init and other parts kernel.org projects. Even in the BSD there are some quite insane ones. Yes major of bsd has agree to central management. History has that coming from the BSD kernel and spread outwards. Torvalds has not spread that control out and has depended on faith. At the start of open source BSD it was a lot more fragmented with a lot more parts not listening to the central management.

[Bsdisbetter]

Please note the Linux kernel has left a lot of things to userspace over the years that really should be handled by something maintained by kernel developers. Its like wpasupplement vs iwd one is designed by third party and one is designed by someone who understand what the heck is going on inside the kernel. Yes there have been quite a few things left to init systems as well that most likely should never had been.

This is more a sympton of Torvald's control of Linux. He only seems to concern himself with the kernel and its processing environment. There is no central figure (except perhaps RHL) driving or seeking to control. Compare this to another FOSS *BSD, where the control of kernel and base is done by one group within that type of BSD whether it be openbsd, freebsd or netbsd. These are steered and co-ordinated much like commercial OSs like Solaris.

You can take FreeBSD and turn it into GhostBSD but it still will always have that control of user and kernel space via FreeBSD.

[Bsdisbetter]

It's an init, it's supposed to use PID1.

DAH. An init is something that starts the system and shuts it down, collecting zombies as they appear. Instead this 'service' does
everything (or at least it will and is progressing to that end). It hijacks the init process in order to scope creep its way into everything.

I can trace Solaris init:
pollsys(0x0806C040, 1, 0xF9DAD9F8, 0x00000000) (sleeping...)
that's it.

I can trace systemd init (from a Centos VM):

epoll_wait(4, [{EPOLLIN, {u32=2821443216, u64=93950936075920}}], 160, -1) = 1
clock_gettime(CLOCK_BOOTTIME, {763, 503855089}) = 0
recvmsg(23, {msg_name(0)=NULL, msg_iov(1)=[{"WATCHDOG=1", 4096}], msg_controllen=32, [{cmsg_len=28, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS, {pid=455, uid=0, gid=0}}], msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 10
open("/proc/455/cgroup", O_RDONLY|O_CLOEXEC) = 20
fstat(20, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1c57330000
read(20, "11:freezer:/\n10:hugetlb:/\n9:blki"..., 1024) = 259
close(20) = 0
munmap(0x7f1c57330000, 4096) = 0
timerfd_settime(13, TFD_TIMER_ABSTIME, {it_interval={0, 0}, it_value={900, 502811000}}, NULL) = 0
epoll_wait(4, [{EPOLLIN, {u32=2821443216, u64=93950936075920}}], 160, -1) = 1
clock_gettime(CLOCK_BOOTTIME, {823, 503763174}) = 0
recvmsg(23, {msg_name(0)=NULL, msg_iov(1)=[{"WATCHDOG=1", 4096}], msg_controllen=32, [{cmsg_len=28, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS, {pid=672, uid=0, gid=0}}], msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 10
open("/proc/672/cgroup", O_RDONLY|O_CLOEXEC) = 20
fstat(20, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1c57330000
read(20, "11:freezer:/\n10:hugetlb:/\n9:blki"..., 1024) = 253
close(20) = 0
munmap(0x7f1c57330000, 4096) = 0
timerfd_settime(13, TFD_TIMER_ABSTIME, {it_interval={0, 0}, it_value={943, 502811000}}, NULL) = 0
epoll_wait(4, [{EPOLLIN, {u32=2821443216, u64=93950936075920}}], 160, -1) = 1
clock_gettime(CLOCK_BOOTTIME, {823, 505130694}) = 0
recvmsg(23, {msg_name(0)=NULL, msg_iov(1)=[{"WATCHDOG=1", 4096}], msg_controllen=32, [{cmsg_len=28, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS, {pid=455, uid=0, gid=0}}], msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 10
open("/proc/455/cgroup", O_RDONLY|O_CLOEXEC) = 20
fstat(20, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1c57330000
read(20, "11:freezer:/\n10:hugetlb:/\n9:blki"..., 1024) = 259
close(20) = 0
munmap(0x7f1c57330000, 4096) = 0

(and on and on it goes)

It takes around 3 minutes to find that info.

That's your preception, it isn't my reality. Anyone can pluck unsubstantiated figures from their head.
First you have to find the command that is now magically in control of cores and find the options to extract it and where it will go.
Now you are finally back to the point where a normal Unix system was of dumping the core to your working directory or tmp.
Not only that, if you don't do it before the next crash, you lose it. A sick joke.

Are you trolling? just writing "journalctl" dumps all the events on stdin, from there you can hack around to filter the output with pipes to grep and awk just like you did with older syslog.

No Mr Passive Aggressive.
One assumes, wrongly, that redhat linux (and all its minions) is actually using standard commands. Wrong. It uses a special command to handle syslog because it now hides it in binary form. Go figure. A layer of obfuscation upon an otherwise uncomplex system.
So, when the syslog is inundated with log entries from a boisterous set of daemons, its watchdog timer barfs, kills it and we lose the logs in the buffer. Wonderful. When the binary log becomes corrupted, we just 'deal with it'? I'm not sure what your security team would think of this, but ours has a very dim view of it. I have never encountered a corrupt syslog text file in all my years of unix use.
I encountered this within a week of testing RHL using systemd. Now, that's progress.

Main difference is that you can use journalctl arguments to filter stuff instead, which is faster, much faster if you have a ton of logs.

If you have tons of logs (actually you're wrong, it's log entries, there's only one active file), chances are they're either corrupted or incomplete or both.
It also attempts to fix a problem that doesn't exist. It's scope creep for the sake of scope creep. It's a symptom of a wider problem with Linux where there's no control of anything apart from the kernel. Any other OS, from BSD to AIX is tightly controlled for the kernel and base. This rubbish called systemd is just another part in that damning process, but, ahah, it seems RHL is now assuming the mantle even more of steering linux in the direction it wants. Enjoy the ride.

Even using a distro like Devuan or MX-17 will eventually become problematic as scope creep from the behemoth known as systemd engulfs everything from the kernel and up (and if I read correctly, they even have their eyes on the kernel with kdbus and 'debug' (LOL) )

I asked because it's something trivial to me, maybe you were talking about something else.

change ForwardToSyslog= to "yes" in /etc/systemd/journald.conf, then systemctl restart systemd-journald

Perhaps you'd like to quote the section of the manual where this is pointed out? And that is another aspect of the systemd mess, the poor to horrible man pages. Perhaps that's another pre-requisite of using systemd, having a internet connection so you can spend lots of time searching for answers to questions you shouldn't have to ask in the first place.

If you want to use systemd, then I have no problem with it. Go for it, be happy. If you solely use linux, then go for it. I would not touch it with a ten foot pole. It attempts to dictate as if it's a standard committee and we need compliance to function in that sphere. It tells us how to daemonise code, it tells us to not allow user processes ex-logout, it tells us it has a better syslog and core dump management where the old one works fine. (I'm not even going to go into login control, device control, dns etc etc).

If it left itself as an init program, with its unit files etc, then it would be an acceptable replacement for sysv init but it hasn't and it won't and that's the reason our organisation has removed RHL (and all its cronies) from its supported architecture leaving Solaris, BSD and HP/UX as sane alternatives which although different share one thing, their attempt to be sysV and BSD compliant.

Systemd just isolates gnu/linux distros even more as they, in our case, cannot integrate with existing systems. If your organisation is pure Linux, it's probably not a problem (at least not mine in any case).

But, hey, if that's what you want, good luck to being dictated to by RHL.

Please don't state it's great because a lot of distros use it, herd mentality accounts for most of the adoption, I would contend.

The End.

[Weasel]

Well I'm not hating on all of systemd. I know a lot of people hate binary logs, but I don't. (I know, bash me!) I do hate megabyte-sized logs though.

[oiaohm]

So, not so much about systemd (the software) itself but rather the guy working on it. Problem is, such attitude should not be tolerated on such critical piece of software that is able to take down the entire system.

A person with a bad attitude is better than no one. I have submit quite a few different sysvinit related bugs over the years. I was annoyed at one point to find out sysvinit had 0 people taking care of it. At least with systemd with Lennart you do get answer you might need to argue as I did to get a fail to root fix and argue involved created 3 different bugs but the fault in end was fixed inside month. This is way better than no one.

Lot of the project merged into systemd either had no maintainers at all or had 1 part time maintainer who could give less than a day a month to the project.

From my point of view Lennart is not bad enough for people doing commercial stuff to find the money to pay someone to fork systemd and fight over who should be maintaining.

Please note the Linux kernel has left a lot of things to userspace over the years that really should be handled by something maintained by kernel developers. Its like wpasupplement vs iwd one is designed by third party and one is designed by someone who understand what the heck is going on inside the kernel. Yes there have been quite a few things left to init systems as well that most likely should never had been.

[Weasel]

Just leaving some things here...

Linus: "I no longer feel like I can trust 'init' to do the sane thing"

And this:

Ted Ts'o, the Linux ext2/3/4 filesystem developer, posted this two days ago at G+ as well. Interesting discussion, particularly about 1) systemd's bad programming taste and complexity, and 2) Lennart Poettering's inability to admit when he is wrong.

"For me a lot of "good taste" is about adding complexity when it's needed, and avoiding it when it's not needed. And if you do have complexity, making sure you have the tools so you can debug things when they break. And for me one of the things that I don't like about systemd is that it has added a lot of complexity, and when it breaks, trying to debug it can be almost impossible."

Also:

"Heck, I don't even I want to file bug reports, just so I can get abusive messages from Lennart. At least when Linus flames me, it's because I did something wrong which hurts users and which I d*mned well should have known better, given my years of experience in the community. Lennart just flames you because you're wrong, and he's right. By definition."

And:

"The high bit, in my opinion, is "not being able to admit you are wrong". If someone (such as Lennart) is always right, then it's impossible to have a technical discussion in a post-mortem to avoid similar problems in the future. In a company, if there are personnel issues like that, you can escalate to the person's manager, or use other mechanisms. In the open source world, all you can do is route around the damage. Whether you call the inability for someone to admit that he or she has contributed to the problem a "lie" or just that they were "mistaken" is really beside the point as far as I'm concerned."

https://plus.google.com/+TheodoreTso/posts/EJrEuxjR65J

So, not so much about systemd (the software) itself but rather the guy working on it. Problem is, such attitude should not be tolerated on such critical piece of software that is able to take down the entire system.