File comment is misleading, says it executes before the 1st runlevel and it doesn’t.
It only starts once systemd has completed everything else. How does one make it run before systemd udev?
TBH, I would just switch to sysvinit like I did on 12.2, but it doesn’t seem to boot at all on 13.1.
It would be easier if you explained what you are trying to achieve. May be it can be done without boot.local …
On Sat, 15 Mar 2014 17:56:01 +0000, finders wrote:
> TBH, I would just switch to sysvinit like I did on 12.2, but it doesn’t
> seem to boot at all on 13.1.
That is because sysvinit is deprecated and no longer supported, AFAIK.
Jim
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
On 2014-03-15 18:56, finders wrote:
>
> File comment is misleading, says it executes before the 1st runlevel and
> it doesn’t.
> It only starts once systemd has completed everything else. How does one
> make it run before systemd udev?
Available files:
/etc/init.d/before.local:
# script with local commands to be executed from init before executing
# any script of a runlevel.
/etc/init.d/after.local:
# script with local commands to be executed from init after all scripts
# of a runlevel have been executed.
/etc/init.d/boot.local:
# script with local commands to be executed from init on system startup
#
# Here you should add things, that should happen directly after booting
# before we're going to the first run level.
/etc/init.d/halt.local:
# script with local commands to be executed from init on system shutdown
#
# Here you should add things, that should happen directly before shuting
# down.
If “boot.local” doesn’t run at the point it says, you should report that
as a bug in Bugzilla. They have to either modify it so that it runs when
it says, or change the comments so that they correctly specify the point
at which it runs.
On the other hand, you can create your own service file so that it runs
before udev.
> TBH, I would just switch to sysvinit like I did on 12.2, but it doesn’t
> seem to boot at all on 13.1.
Mo, you simply can not do that any longer. Only systemd works now,
that’s intentional.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
It runs after “boot” which unfortunately includes a systemd network service.
In sysvinit, network service is separate from boot services, therefore, a script can run after boot, before network is up.
Seems like this is not supported by systemd udev, which brings up the persistent network automatically, on boot.
Even if I set the interface to disabled or manual, it still brings it up on boot. I can remove the driver, but then the user can’t ifup at all.
If I were to create a service file, how do I make sure it runs after udev brings up disk partitions but before it brings up the network?
I’m currently on evergreen 11.4, where it still works just fine, I will start to worry about this somewhere around june.
Can’t say I’m looking forward to that.
On 03/15/2014 04:06 PM, finders wrote:
>
> robin_listas;2630675 Wrote:
>>
>> If “boot.local” doesn’t run at the point it says, you should report that
>> as a bug in Bugzilla. They have to either modify it so that it runs when
>> it says, or change the comments so that they correctly specify the point
>> at which it runs.
>>
>> On the other hand, you can create your own service file so that it runs
>> before udev.
>
> It runs after “boot” which unfortunately includes a systemd network
> service.
> In sysvinit, network service is separate from boot services, therefore,
> a script can run after boot, before network is up.
> Seems like this is not supported by systemd udev, which brings up the
> persistent network automatically, on boot.
> Even if I set the interface to disabled or manual, it still brings it up
> on boot. I can remove the driver, but then the user can’t ifup at all.
> If I were to create a service file, how do I make sure it runs after
> udev brings up disk partitions but before it brings up the network?
>
> robin_listas;2630675 Wrote:
>>
>> Mo, you simply can not do that any longer. Only systemd works now,
>> that’s intentional.
>
> I’m currently on evergreen 11.4, where it still works just fine, I will
> start to worry about this somewhere around june.
> Can’t say I’m looking forward to that.
Service files for systemd are not as difficult to write as SystemV files. When
the time comes, check out /usr/lib/systemd/system/wpa_supplicant.service for an
example of such a file that runs before the network is started.
No, it does not. In 13.1 with ifup interfaces will be started by /etc/init.d/network (or after /etc/init,d/network completes). If you have evidences that it works differently - I’m interested to see them.
Even if I set the interface to disabled or manual, it still brings it up on boot.
It should not happen as long as I can believe the code. Of course, bugs happen, but then you need to open bug report and provide more information.
And you still did not explain what is wrong with the way system works by default …
TBH, I’d rather not go into that, but I can give you some general examples, from this one box. (Home system, not a server)
Note that I do this because you asked me to explain, not because I want support, as I don’t care much what happens to systemd, even if it does get pushed to rhel7.
I never asked for systemd, it just showed up as a single, mandatory replacement for sysvinit, which btw, worked for me just fine, for many years.
Aside from boot scripts failure, and core services which cannot be removed without patching systemd, there’s this:
With systemd, run_parallel=no doesn’t work, hence, it overloads the physical hdd up to the point where I can hear disk heads struggling to cope with it inside the case.
This never happens with sysvinit. Before you ask, its a mechanical wd drive and it works perfectly fine, smartd output is normal.
Since kms in initrd, os always fails to set proper resolution, nouveau output is corrupted, even the installer fails if no kms option is not set.
Also, since kms in initrd, I get nvidia driver warnings, which never show up on older systems like SLED and 11.4 using same vesa vga modes, regardless of driver version.
Next, journald I don’t need, but it’s doing disk writes every couple of seconds anyway, used iotop to find the source of this issue (thanks)
Simple programs like mc, old school nc clone, they depend on libssh now, as does the majority of KDE. (I use ssh on servers, never on home box, why is this?)
Grub2, I don’t need with no uefi, but still defaults. Yast2 system services clearly lacks basic features which were there in 12.2.
Feels almost like someone was in a hurry to implement something which was not properly tested at all. Maybe it’s not regression, what do I know.
So much for my opinion on what’s wrong with defaults, but who cares about one user opinion these days anyway.
I have found a way to migrate this old box to CentOS 5.10, and still keep most functionality, so I won’t have to worry about it for quite some time.
On 2014-03-17 09:06, finders wrote:
>
> arvidjaar;2630731 Wrote:
>> And you still did not explain what is wrong with the way system works by
>> default …
>
> TBH, I’d rather not go into that, but I can give you some general
> examples, from this one box. (Home system, not a server)
> Note that I do this because you asked me to explain, not because I want
> support, as I don’t care much what happens to systemd, even if it does
> get pushed to rhel7.
But a) this is a user support forum, and b) this is an openSUSE forum
(rhel is irrelevant here).
So if you state your real problems, we can try help you (and gladly). We
can do nothing about having systemd or not in openSUSE.
If you want to rant about systemd, well, this is not the right forum.
You have to go to the chit-chat forum instead.
> I never asked for systemd, it just showed up as a single, mandatory
> replacement for sysvinit, which btw, worked for me just fine, for many
> years.
Almost no one asked for systemd, except a large percent of the people
that have to maintain whatever is in current use, and they make the
decisions, not the bases. But it is here, and it is here to stay. If you
use openSUSE, you use systemd, want it or not.
> Aside from boot scripts failure, and core services which cannot be
> removed without patching systemd, there’s this:
You’d have to clarify that.
> With systemd, run_parallel=no doesn’t work, hence, it overloads the
> physical hdd up to the point where I can hear disk heads struggling to
> cope with it inside the case.
Yes, systemd boots everything in parallel as fast as possible. If the
disks can not “cope”, the system waits. Hard disks are designed to work,
so they must work.
> Since kms in initrd, os always fails to set proper resolution, nouveau
> output is corrupted, even the installer fails if no kms option is not
> set.
This has nothing to do with systemd. Actually, those changes were
implemented before systemd was available.
> Also, since kms in initrd, I get nvidia driver warnings, which never
> show up on older systems like SLED and 11.4 using same vesa vga modes,
> regardless of driver version.
Again, this has nothing to do with systemd.
> Next, journald I don’t need, but it’s doing disk writes every couple of
> seconds anyway, used iotop to find the source of this issue (thanks)
man journald.conf:
Storage=
Controls where to store journal data. One of
"volatile", "persistent", "auto" and "none". If
"volatile", journal log data will be stored only
in memory, i.e. below the /run/log/journal
hierarchy (which is created if needed). If
"persistent", data will be stored preferably on
disk, i.e. below the /var/log/journal hierarchy
(which is created if needed), with a fallback to
/run/log/journal (which is created if needed),
during early boot and if the disk is not
writable. "auto" is similar to "persistent" but
the directory /var/log/journal is not created if
needed, so that its existence controls where log
data goes. "none" turns off all storage, all log
data received will be dropped. Forwarding to
other targets, such as the console, the kernel
log buffer or a syslog daemon will still work
however. Defaults to "auto".
In openSUSE, the default settings mean that if “/var/log/journal” does
not exist, the journal is not written to disk. No i/o.
journald is needed to debug problems related to systemd, like why a
service did not start. The volatile setting is good enough and default
for most people.
> Simple programs like mc, old school nc clone, they depend on libssh now,
> as does the majority of KDE. (I use ssh on servers, never on home box,
> why is this?)
Again, this has nothing to do with systemd.
mc uses ssh to connect to other systems, and present you a virtual
filesystem of the other machine on one of the panes. It is a very useful
feature. I use it often to move files to/from my laptop, ie, not a server.
> Grub2, I don’t need with no uefi, but still defaults.
Again, this has nothing to do with systemd.
You can use grub 1 if you like. I do.
> Yast2 system
> services clearly lacks basic features which were there in 12.2.
The module had to be rewritten. And, YaST had to be migrated from the in
house language the used to ruby, which was done precisely on 13.1. This
means the YaST team was so busy doing the migration that no new features
were added to YaST; on the contrary, many were removed.
The hope is that as there are many people that know Ruby (none knew the
language YaST used), there will be new contributors to YaST, and we will
get new modules and additions and corrections.
This said, there are two modules you should look at: “system services”
and “services manager”. You probably looked at “the wrong one”.
> Feels almost like someone was in a hurry to implement something which
> was not properly tested at all. Maybe it’s not regression, what do I
> know.
Well, you know that YOU are the QA team here, don’t you? 
> I have found a way to migrate this old box to CentOS 5.10, and still
> keep most functionality, so I won’t have to worry about it for quite
> some time.
Well, use whatever you like and works for you 
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
In 5 years no one is going to use mechanical drives for booting unless they have some archaic hardware - they’re going the way of the dodo and it can’t happen soon enough. SSDs are now way below 100€ for “large enough to use as a system drive” whilst offering superior performance, data integrity and recoverability in the case of a catastrophic hardware failure.
That’s because much of the time users are people who don’t want things to change even when they are for the better because they are so stuck in their ancient, archaic view of things and cannot see anything outside their own limited box.
SysV has a lot of issues: yes it’s simple and it works but on the other hand it has no redundancy of any kind, no monitoring or restarting of services, no dependency handling… and most of all - it’s bloody slow on a modern computer.
@Carlos : I appreciate the effort, but as I said, I’m not looking for support. Original question has been answered by lwfinger. (thanks)
While it won’t work for me due to parallel boot, I might be able to include a delay, something like networkmanager service has already done.
Also, you quote my post and dismiss the non systemd failures, while you’re well aware I was asked to explain what’s wrong with the way system works by default.
If he had asked specifically about systemd failures, I would just list those.
I don’t buy that, quality HDD can easily last for 10+ years, while SSD fails in couple of months of extensive abuse.
Sure, they may be designed for recovery, but they fail miserably when it comes to longetivity.
You sound like a vendor, so I’ll just quit this pointless conversation, sir long time lurker since 2012.
No. This change isn’t there for better user experience, if you believe that, you’re a fool.
Change for the better is when security hole is patched, introduction of systemd is actually change for the worse.
It’s an intentional push of unfinished feature which desperately needs patches and contributors so it can finally get into production systems.
Again, I don’t buy that story either, and I’m not really interested in debugging something that’s defective by design.