LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 02-11-2014, 04:11 PM   #256
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,912

Rep: Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513

Quote:
Originally Posted by ReaperX7 View Post
Passing stuff back to the BSD scripts might be a solution if we can minimize how many scripts systemd uses on it's own before the hand off...

rc.local!!!! Why didn't I see it earlier... Think about it. Instead of mitigating everything to systemd service handlers that can be started by systemd, leave only the bare minimum for systemd and symlink a modified rc.M to the systemd friendly rc.local with everything else to be loaded traditionally. Of course you'd have to remake the local script to wait until rc.M is finished, but if it could be done, it'd solve the whole of the problem.
Maybe... but you are forgetting that systemd replaces init. It mounts the filesystems. It starts dbus. It starts the logging.

Now, not using ANY systemd configurations except rc.local would work (it would still be mounting filesystems as that is built in). but remember, there are no levels anymore.

By default, rc.local is SUPPOSED to be started AFTER the network is running... but that could be changed. The dependency list would have to be modified (personally, I think it would be more reliable) by having a specific target that would guarantee that whatever systemd does, is completed BEFORE rc.local is started. Then put a simple shell script version if the sysVinit startup in there (my Slackware VM isn't running at the moment, but I think it already has one). That way things could be slowly migrated. There will still be a lot of difficulty in debugging the migrated services though - each service added causes a change to most of other services due to scheduling alterations and that can introduce/identify additional overlooked dependencies.

I have had to disable NetworkManager (it just doesn't handle things very well for me) and enabled the network.service (which runs the normal network startup scripts for Fedora). rc.local still depends on the network, but at least my network is stable first.

As an alternate thought - it doesn't have to be called rc.local. Call the service target rc-M.service. Then make rc.local depend on rc-M (After=rc-M). That way you still get to isolate rc.local from rc.M done by systemd. Now the rc-M.service would need the After=remount-rootfs (I believe that is the minimum that systemd has to have), but you would have to think about it. things like procfs, devfs, udev, journald, still have to be processed VERY early in the boot process.

There is also the things about the shutdown order that has to be thought out too.

Last edited by jpollard; 02-11-2014 at 04:30 PM.
 
2 members found this post helpful.
Old 02-11-2014, 08:49 PM   #257
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-15.0 Multilib
Posts: 6,558
Blog Entries: 15

Rep: Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098
Exactly, and good idea jpollard adding an rc-M.service file idea.

It's more or less a rehashing of the same concept that was used to add sysvinit support to bsdinit.

I only wish we could restore the runlevels to systemd. It's beneficial to have diagnostic modes available and low level administrator modes for system maintenance.
 
Old 02-12-2014, 02:52 AM   #258
bartgymnast
Member
 
Registered: Feb 2003
Location: Almere, Netherlands
Distribution: slack 7.1 till latest and -current, LFS
Posts: 368

Original Poster
Rep: Reputation: 165Reputation: 165
ReaperX7, those modes are still there
they are just not named by their number anymore
its rescue (runlevel 1), multi-user (runlevel 3), grahpical (runlevel 4), etc,

for having a rc-M.service file I don not see the use of it at all.
With the latest systemd it should work normally.
If a program that depends on mysql, fails to start, it is an issue of mysql
If mysql has been compiled with systemd support, than mysql reports back to systemd that it is ready (thats why systemd is a service manager)
 
Old 02-12-2014, 04:35 AM   #259
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-15.0 Multilib
Posts: 6,558
Blog Entries: 15

Rep: Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098
The point of rc-M is better safe than sorry. Even if it may work right there should be a fail-safe fallback that can be enabled at will to ensure things do work not just right, but correctly.

It's the same concept of the rc.sysvinit executed at the end of Slackware's rc startup scripts to load sysvinit scripts in compatibility mode.

Having rc-M.service would still allow for non-systemd Slackware startup scripts to load in a legacy mode, or even serve as a backup in case the normal service files become problematic, or as even as a curious alternative.
 
Old 02-12-2014, 04:58 AM   #260
bartgymnast
Member
 
Registered: Feb 2003
Location: Almere, Netherlands
Distribution: slack 7.1 till latest and -current, LFS
Posts: 368

Original Poster
Rep: Reputation: 165Reputation: 165
but you can write service scripts accordingly.

for example 2 different mysql.service scripts:

Code:
[Unit]
Description=MySQL Server
After=network.target

[Service]
ExecStart=/usr/bin/mysqld --defaults-file=/etc/mysql/my.cnf --datadir=/var/lib/mysql --socket=/var/run/mysqld/mysqld.sock
User=mysql
Group=mysql
WorkingDirectory=/usr

[Install]
WantedBy=multi-user.target
or if you want to start it tradionally from /etc/rc.d

Code:
[Unit]
Description=MySQL Server
After=network.target

[Service]
Type=forking
ExecStart=/etc/rc.d/mysqld start
ExecStop=/etc/rc.d/mysqld stop

[Install]
WantedBy=multi-user.target
 
Old 02-12-2014, 05:32 AM   #261
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,912

Rep: Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513
All that is very nice...

Except that if mysqld is not modified (like every service really needs to be modified), systemd ASSUMES it is ready as soon as the process starts.

It is what makes it incompatible with SysVinit.
 
Old 02-12-2014, 06:02 AM   #262
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-15.0 Multilib
Posts: 6,558
Blog Entries: 15

Rep: Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098
One of the long standing issues all parallel daemon service loaders including OpenRC, RunIt, s6, and systemd have had to contend with is if one part of the system starts before another part is ready, it breaks things to the point that these init systems batch load services in hybridized linear-parallel modes or make parallel loading entirely optional.

This does require lots of modifications to packages and startup scripts alike.

Last edited by ReaperX7; 02-12-2014 at 06:04 AM.
 
Old 02-12-2014, 06:23 AM   #263
moisespedro
Senior Member
 
Registered: Nov 2013
Location: Brazil
Distribution: Slackware
Posts: 1,223

Rep: Reputation: 195Reputation: 195
Quote:
Originally Posted by TobiSGD View Post
Guys, you all have been warned several times now. Do I really have to be the bad moderator and give you people a break from posting on LQ? Is systemd really that much a pain for you that it is impossible for you to keep this thread on topic? It seems to me that you all are grown up and reasonable persons, why is it so hard not to fall back in your general discussions about Red Hat/systemd/whatever if those discussions clearly are not the topic and there were already several warnings from different moderators?
I think it is perfectly reasonable to have a discussion like this one on a thread about porting systemd
I learnt a lot with it
 
2 members found this post helpful.
Old 02-12-2014, 08:47 AM   #264
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 8,559

Rep: Reputation: 8111Reputation: 8111Reputation: 8111Reputation: 8111Reputation: 8111Reputation: 8111Reputation: 8111Reputation: 8111Reputation: 8111Reputation: 8111Reputation: 8111
Quote:
Originally Posted by moisespedro View Post
I think it is perfectly reasonable to have a discussion like this one on a thread about porting systemd
I learnt a lot with it
I disagree, and I was quite annoyed with all the attempts to derail the purpose of the thread. We already have "systemd bashing" threads on this forum, in which I enjoy participating (I am not a supporter of systemd) but Bart's thread is about getting systemd to work on Slackware, and that is a commendable goal in itself.
Technical discussion on how to implement systemd on Slackware is OK, but politically inspired posts do not belong here.

My two cents.

Eric
 
7 members found this post helpful.
Old 02-12-2014, 09:52 AM   #265
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,912

Rep: Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513
Quote:
Originally Posted by ReaperX7 View Post
One of the long standing issues all parallel daemon service loaders including OpenRC, RunIt, s6, and systemd have had to contend with is if one part of the system starts before another part is ready, it breaks things to the point that these init systems batch load services in hybridized linear-parallel modes or make parallel loading entirely optional.
Yes - and that "devolves" into what the original inittab was for, and did very well.
Quote:

This does require lots of modifications to packages and startup scripts alike.
yes. And trying to avoid that is what systemd doesn't do.

I did have a thought about it though.

If a fuse based mount for /run were done, and the parallel init would use it - THEN, the normal scripts COULD be done, and monitoring the service process could ALSO be done. The filesystem would only hold things like the "xxx.pid" files, which only hold the pid of the service. This would identify to systemd (or equivalent) what process should be monitored. Second, it fixes the notification requirement as the pid file cannot be recorded until AFTER the process forks the daemonized service (in which case it should be ready for requests...). Putting that recording there would appear to solve the "ready" requirements, as well as solve the startup requirements (the PID of the setup process would be known as systemd is the one that forked it). If the service didn't require any "ready" (or monitoring was undesired) then none would be provided.

For complex services that use multiple processes (the one that comes to mind is tying NIS/LDAP + other naming services together in one startup, but I'm sure there are others) a naming convention could be used: startup_script_id.daemon_id.pid, thus the monitoring process would have the connection between the startup script name, the specific daemon service, and the pid for that service. If it needed to be restarted, then the script (which is easier to modify than the service) could be invoked with restart parameters pointing to the specific one to do (or it could just look in the /run directory for the pid file that should have been removed when the monitored process exited).

It would seem to eliminate the need for modifications to the service.

Last edited by jpollard; 02-12-2014 at 10:02 AM.
 
2 members found this post helpful.
Old 02-12-2014, 12:02 PM   #266
harryhaller
Member
 
Registered: Sep 2004
Distribution: Slackware-14.2
Posts: 468

Rep: Reputation: Disabled
Quote:
Originally Posted by bartgymnast View Post
but you can write service scripts accordingly.

for example 2 different mysql.service scripts:

Code:
[Unit]
Description=MySQL Server
After=network.target

[Service]
ExecStart=/usr/bin/mysqld --defaults-file=/etc/mysql/my.cnf --datadir=/var/lib/mysql --socket=/var/run/mysqld/mysqld.sock
User=mysql
Group=mysql
WorkingDirectory=/usr

[Install]
WantedBy=multi-user.target
Those are not "scripts" - they are Microsoft® .ini format configuration files.

My goodness! Who would have ever believed that Microsoft® ".ini" format would be chosen for configuring GNU/Linux systems?
 
Old 02-12-2014, 12:30 PM   #267
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 2,727

Rep: Reputation: 1247Reputation: 1247Reputation: 1247Reputation: 1247Reputation: 1247Reputation: 1247Reputation: 1247Reputation: 1247Reputation: 1247
Quote:
Originally Posted by harryhaller View Post
Those are not "scripts" - they are Microsoft® .ini format configuration files.

My goodness! Who would have ever believed that Microsoft® ".ini" format would be chosen for configuring GNU/Linux systems?
Guess what format use, from ages, the ol'good configuration files like /etc/httpd/php.ini or /etc/samba/smb.conf?

The fact that you are incredible amazed by "that so shocking discovery" tell very much about your (Slackware) Linux knowledge level...

Last edited by Darth Vader; 02-12-2014 at 12:36 PM.
 
Old 02-12-2014, 12:34 PM   #268
commandlinegamer
Member
 
Registered: Dec 2007
Posts: 163

Rep: Reputation: 51
Quote:
Originally Posted by harryhaller View Post
Those are not "scripts" - they are Microsoft® .ini format configuration files.

My goodness! Who would have ever believed that Microsoft® ".ini" format would be chosen for configuring GNU/Linux systems?
To be perfectly fair, that type of configuration file (and yes, I would agree it's not a script) has been used in other UNIX/Linux applications, the first example that springs to mind being Samba.

Last edited by commandlinegamer; 02-12-2014 at 12:36 PM.
 
Old 02-12-2014, 01:35 PM   #269
harryhaller
Member
 
Registered: Sep 2004
Distribution: Slackware-14.2
Posts: 468

Rep: Reputation: Disabled
Quote:
Originally Posted by Darth Vader View Post
Guess what format use, from ages, the ol'good configuration files like /etc/httpd/php.ini or /etc/samba/smb.conf?

The fact that you are incredible amazed by "that so shocking discovery" tell very much about your (Slackware) Linux knowledge level...
Yes. Now you know that I don't run a server or samba.

But it doesn't change the substance of my comment - and why do php.ini and samba.conf use the Microsoft® ini format?

An odd, but revealing, choice.
 
Old 02-12-2014, 03:12 PM   #270
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-15.0 Multilib
Posts: 6,558
Blog Entries: 15

Rep: Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098Reputation: 2098
.ini is actually fairly universal like .conf is. It's all a matter if what file format you wish to choose from. Yes .ini is more commonly used on Microsoft systems like MSDOS and Windows, and Microsoft-like systems like Wine and ReactOS, but .conf is equally used by projects on those systems as well.

There are various initialization and configuration formats in existence in usage with UNIX and UNIX-like systems, so you're bound to come across most of them at any given time.

However, it is intriguing that .ini stylization was chosen for systemd. I wonder why?
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 02:18 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration