Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Towards a better, more modern init
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Unsupported Software
View previous topic :: View next topic  
Author Message
Shamus397
Apprentice
Apprentice


Joined: 03 Apr 2005
Posts: 218
Location: Ur-th

PostPosted: Sat Dec 06, 2014 5:18 pm    Post subject: Towards a better, more modern init Reply with quote

Rationale

In recent times it seems that much kvetching and hand-wringing has been going on about how horrible Sys V init is, and how we must all replace it immediately with something that ostensibly started as a replacement for it, but in the interim, has now been revealed as the the thin edge of the wedge of a bid to convert what we all know and love as Linux into a vertically integrated, opaque, and byzantine bag of unproven daemons and other assorted bits and bobs. To me, and, it would seem, lots of other people, this is a wrongheaded approach to the problem.

There have been attempts to fix this by using other init systems (such a runit, monit, s6, and what have you), but none of them play nice with the infrastructure that is already built into Gentoo—namely, OpenRC. I find it amazing to this day that OpenRC hasn't gotten more widely used outside of Gentoo (and, dare I say it? Funtoo) because it really is a nice piece of software that solved things like dependency resolution many years before certain self-declared geniuses came along to 'solve' the problem for us.

So anyway, this is not meant to be a political screed against certain would-be Men Who Would Be Kings, but a working example of code that will (hopefully) help move things forward. The reason why I am doing this is manifold. First of all, quite a few people get upset about people talking about what to do without actually doing anything about it; to them, talk without code is useless and I have belatedly come to find myself in agreement. Secondly, it seems that nobody else was stepping up to the plate—at least not in a manner that made sense to me. I am not denigrating the work that others have put into making runit work with OpenRC, this is great stuff. But to me it seems that this effort is doomed, mainly because there is overlap in the domains that those two projects encompass and it would require a lot more effort than it is worth to bend OpenRC to fit the runit mold.

A New Init

So, with all that said, I have taken my inspiration from Felipe Contreras's blog post Demystifying the init system (PID 1). I highly recommend reading it. If you feel compelled to try it out, you will notice a few things. For one, it brings the system up and takes it down very quickly. Another is that it doesn't really work under Gentoo very well without modifying a few things, as it seems it was written for Arch Linux.

And this is where things get interesting. Since Arch doesn't have OpenRC, Felipe's init has to do a lot of housekeeping just to get the system to boot at all into a usable state. But since we have OpenRC on Gentoo, we can throw out a lot of the code that he has dedicated to these tasks. As a result, our init is even smaller! Believe it or not, the script listed down below of less than two hundred lines is all that is needed to have a functional init.

So the goals of this project are fairly modest. They are:
  • Be a drop in replacement for Sys V init
  • Integrate well with OpenRC
  • Have a small attack surface
  • Be able to add things like process supervision, socket activation for those that want it

To be perfectly honest, much is made of that last bullet point as if it were this all important thing that everyone must have now. And the nice thing about this approach is that we can accomodate such things fairly easily without having to break everything that came before. That said, there is a school of thought that thinks that what Sys V init does (and therefore, what you see down below) is too much (found here), but I think that view is perhaps a bit extreme.

That said, I do think that putting the kitchen sink into init is a bad approach, and as such, what we have below is fairly limited in scope. As a drop in replacement for Sys V init, all it does is bring up the system, bring it down, and respawn agettys if they die. It can be fairly easily extended to do other things, like reading /etc/inittab in order to know what processes need to be respawned.

Please note that while this init is written in Ruby, it is intended to ultimately be rewritten in C. It is very easy to test out and try new ideas in its Ruby form and that's why it is done this way. If you want to try your hand at extending/changing this script, be aware of this: if you make a mistake in the script, you can easily make your system unbootable, so make a backup of the script before changing it. If you do make your system unbootable, it will be fairly easy to boot from a rescue CD and copy your backup back to /sbin/init to get things going again.

I Don't Care About Any Of That, How Do I Use It?

Since this is a work in progress, and still in the fleshing-it-out stage, it is written in Ruby—just like Felipe's. THIS IS NOT THE FINAL CODE; THE FINAL CODE WILL BE WRITTEN IN C!

To use this as your init, you need to have Ruby installed on your system, and preferably, the 2.1 series:

Code:
# RUBY_TARGETS=ruby21 emerge ruby

Move your current init out of the way:

Code:
# mv -v /sbin/init /sbin/init.sysv

Copy the script below and place it in a text file named /sbin/init:

Code:
#!/usr/bin/ruby

require 'socket'


def do_cmd(*cmd)
  ctl = UNIXSocket.open('/run/initctl')
  ctl.puts(cmd.join(' '))
  puts(ctl.readline.chomp)
  exit
end


# If we're not PID 1, parse & send commands to /run/initctl

if $$ != 1
  case ARGV[0]
  when 'poweroff', 'restart', 'halt'
    do_cmd(ARGV[0].to_sym)
  when 'status'
    do_cmd(ARGV.shift.to_sym, *ARGV)
  when 'test'
    map = { poweroff: 0x4321fedc, restart: 0x01234567, halt: 0xcdef0123 }
    # 169 == SYS_reboot
    syscall(169, 0xfee1dead, 0x20112000, map[:poweroff])
  else
    puts('I know the following commands: poweroff, restart, halt, status, test')
    exit 1
  end
end


# These are hashes

$daemons = {}
$daemonCmds = {}

# Needed to prevent respawning children during a reboot...

$shuttingDown = false

# Here we do some process monitoring...

Signal.trap(:SIGCHLD) do
  loop do
    begin
      pid = Process.wait(-1, Process::WNOHANG)
      key = $daemons.key(pid)

      if key
        cmd = $daemonCmds[key]
        $daemons.delete(key)
        $daemonCmds.delete(key)

        # Respawn any processes that exit...
        if key != 'openrc' && !$shuttingDown
          launch(key, cmd)
        end
      end

      break if pid == nil
    rescue Errno::ECHILD
      break
    end
  end
end


def launch(id, cmd)
  puts('Starting %s...' % id)
  pid = fork do
    Process.setsid()
    exec(*cmd)
  end
  $daemons[id] = pid
  $daemonCmds[id] = cmd
end


def init

  launch('openrc', %w[/sbin/rc sysinit])
  Process.wait($daemons['openrc'])

  launch('openrc', %w[/sbin/rc boot])
  Process.wait($daemons['openrc'])

  launch('openrc', %w[/sbin/rc default])
  Process.wait($daemons['openrc'])

end


def shutdown

  $shuttingDown = true
  launch('openrc', %w[/sbin/rc reboot])
  Process.wait($daemons['openrc'])

  sys_sync()

end


init

ARGV.each do |e|
  case e
  when 'emergency'
    $emergency = true
  end
end

if $emergency
  launch('agetty1', %w[/sbin/agetty tty1 --noclear --autologin root])
else
  # Launch TTYs...
  (1..5).each do |n|
    launch("agetty#{n}", %W[/sbin/agetty tty#{n} --noclear])
  end
end


# This shows the one of the hazards of coding this in Ruby...

def sys_reboot(cmd)
  # LINUX_REBOOT_CMD_POWER_OFF == 0x4321FEDC
  # LINUX_REBOOT_CMD_RESTART   == 0x01234567
  # LINUX_REBOOT_CMD_HALT      == 0xCDEF0123
  map = { poweroff: 0x4321fedc, restart: 0x01234567, halt: 0xcdef0123 }
  # 169 == SYS_reboot
  # LINUX_REBOOT_MAGIC1  == 0xfee1dead
  # LINUX_REBOOT_MAGIC2C == 0x20112000
  syscall(169, 0xfee1dead, 0x20112000, map[cmd])
end


def sys_sync
  # 162 == SYS_sync
  syscall(162)
end


begin
  server = UNIXServer.open('/run/initctl')
rescue Errno::EADDRINUSE
  File.delete('/run/initctl')
  retry
end

loop do
  ctl = server.accept
  args = ctl.readline.chomp.split
  cmd = args.shift.to_sym
  case cmd
  when :poweroff, :restart, :halt
    shutdown
    sys_reboot(cmd)
  when :status
#    ctl.puts($daemons[args.first] ? 'ok' : 'dead')
    # This is NFG. It only shows on the main console, not on the socket, so
    # you get nothing if you're ssh'ed in...
    $daemons.each { |key, value| puts(key + ': ' + (value ? '[OK]' : '[!!]') + ' (' + value.to_s + ')') }
    ctl.puts
  end
end

Finally, mark the text file you just created as executable:

Code:
# chmod ugo+x /sbin/init


You can now reboot your system. There are still things missing to make it a drop in replacement to Sys V init, but the basics are there.

Conclusion

This is a work in progress; I welcome any constructive comments and/or code. Please stay on topic in this thread, there are already plenty of other threads for discussion of things that are not relevant to this thread. Thanks! :)
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Sat Dec 06, 2014 6:22 pm    Post subject: Reply with quote

Nice job.

I do like the link to Felipe's blog and this line.
Quote:
Personally when I hear somebody saying “Oh! but OpenRC doesn’t have socket activation, we need systemd!”, I just roll my eyes.

_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
tclover
Guru
Guru


Joined: 10 Apr 2011
Posts: 516

PostPosted: Sun Dec 07, 2014 3:11 pm    Post subject: Almost lost... not yet! Reply with quote

Nice to see someone standing to _do_ something rather than continual _empty_ talk.

Now, I almost was going to say lost on Ruby... but the code is actually readable from
someone who never took a look on a Ruby script.

Looks sane enough to me. I will certainly give a hand or _both_ for writing usable C
code and will gladly test along the way.

Side Note: I don't care about possible breakages along the way because I use an
initramfs (--something on my sig--) which have a rescue shell that can be certainly
used to `mv /sbin/init{.bak,}' when need be. Now, I'd rather avoid kernel panics
with a broken init. KVM should be of a great help here before real world tests.

I am not that compelled to test that script for now. Am I wrong? Waiting for for the
actual real thing.
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/
Back to top
View user's profile Send private message
bstaletic
Apprentice
Apprentice


Joined: 05 Apr 2014
Posts: 233

PostPosted: Sun Dec 07, 2014 3:50 pm    Post subject: Reply with quote

Interesting read, but what are the benefits over openrc?
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Sun Dec 07, 2014 3:55 pm    Post subject: Reply with quote

bstaletic wrote:
Interesting read, but what are the benefits over openrc?

bstaletic ... its not a replacement for openrc, in fact its designed to work in conjunction with it. All that is being replaced is /sbin/init from sysvinit (hence /etc/inittab is nolonger used ... and so the call to rc and getty).

best ... khay
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6920

PostPosted: Sun Dec 07, 2014 4:22 pm    Post subject: Re: Towards a better, more modern init Reply with quote

Shamus397 wrote:
So the goals of this project are fairly modest. They are:
  • Be a drop in replacement for Sys V init
[...]

I'd been thinking about making one of those... but you're actually doing it which is better. Best of luck to you, and everyone else who gets involved with this.
Back to top
View user's profile Send private message
tclover
Guru
Guru


Joined: 10 Apr 2011
Posts: 516

PostPosted: Sun Dec 07, 2014 4:50 pm    Post subject: Question to the OP Reply with quote

@Shamus....

Where is your working code? I mean do you host it anywhere? A fork on github with
your OpenRC transmutation would certainly not hurt.

Anyway, I'm waiting... for actual C code and/or repository to look at.
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/
Back to top
View user's profile Send private message
Shamus397
Apprentice
Apprentice


Joined: 03 Apr 2005
Posts: 218
Location: Ur-th

PostPosted: Mon Dec 08, 2014 1:13 pm    Post subject: Reply with quote

@tclover: What I posted in #1 is the latest, and I would definitely give it a try--I want to know that it's working correctly for more than just me. :) That said, I'll be setting up a repository and will post here when it's on-line.
Back to top
View user's profile Send private message
Shamus397
Apprentice
Apprentice


Joined: 03 Apr 2005
Posts: 218
Location: Ur-th

PostPosted: Tue Dec 09, 2014 3:19 pm    Post subject: Reply with quote

OK, the repository is located at http://shamusworld.gotdns.org/git/init-ng . There's very little in there ATM, and will likely stay small as the only things that will be added are a makefile, a C source file, and possibly an ebuild. :)
Back to top
View user's profile Send private message
jirutka
n00b
n00b


Joined: 17 Feb 2013
Posts: 10

PostPosted: Tue Dec 09, 2014 3:32 pm    Post subject: Reply with quote

Shamus397 wrote:
OK, the repository is located at http://shamusworld.gotdns.org/git/init-ng . There's very little in there ATM, and will likely stay small as the only things that will be added are a makefile, a C source file, and possibly an ebuild. :)


Could you please put it on GitHub (at least a mirror), so we can easily collaborate and watch what’s happening?
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Tue Dec 09, 2014 6:28 pm    Post subject: Reply with quote

Cool, it's probably better to have one post for this than spread it over multiple threads as has happened.

In that light I'm following up to a discussion about sysvinit here, instead of where it started (which is about politics.) We were talking about cleaning up the shutdown process, which got us onto /dev/initctl.

Further to that, we can't use USR1 and USR2 (just to dismiss that part); man telinit says:
Code:
SIGUSR1
 On  receipt  of  this  signals,  init closes and re-opens its control fifo, /dev/initctl.
 Useful for bootscripts when /dev is remounted.
along with:
Code:
SIGHUP
 Has the same effect as telinit q.

SIGINT
 Normally the kernel sends this signal to init when CTRL-ALT-DEL is pressed.
 It activates  the  ctrlaltdel action.

SIGWINCH
  The kernel sends this signal when the KeyboardSignal key is hit.
  It activates the kbrequest action

Looking at source for init.c it's using USR2 as an alias for SIGPWR when not on the system. Linux does have it, but in any case we're better off modernising on RT signals. They're much better in any case. We do still have all the job-control signals, if we want them, for simple stuff like shutdown or reboot (default timeout). To send the signal in the first place, a process has to be privileged.

The manpage tells us:
Code:
Init listens on a fifo in /dev, /dev/initctl, for messages.  Telinit uses this to communicate with init.
 The interface is not very well documented or finished. Those interested should study the  initreq.h  file
 in the src/ subdirectory of the init source code tar archive.

Take a look at initreq.h as well, but really the code in src/init.c is the documentation. Commands on the pipe are exactly 3 chars (line 345) and they're laid out at line 177, with the user-level actions above that:
Code:
/* NOTE this is GPL code -- we are extracting this part to document the protocol */
/* ascii values for the `action' field. */
struct actions {
char *name;
int act;
} actions[] = {
{ "respawn", RESPAWN },
{ "wait", WAIT },
{ "once", ONCE },
{ "boot", BOOT },
{ "bootwait", BOOTWAIT },
{ "powerfail", POWERFAIL },
{ "powerfailnow",POWERFAILNOW },
{ "powerwait", POWERWAIT },
{ "powerokwait", POWEROKWAIT },
{ "ctrlaltdel", CTRLALTDEL },
{ "off", OFF },
{ "ondemand", ONDEMAND },
{ "initdefault", INITDEFAULT },
{ "sysinit", SYSINIT },
{ "kbrequest", KBREQUEST },
{ NULL, 0   },
};
/*
* State parser token table (see receive_state)
*/
struct {
char name[4];
int cmd;
} cmds[] = {
{ "VER", C_VER },
{ "END", C_END },
{ "REC", C_REC },
{ "EOR", C_EOR },
{ "LEV", C_LEV },
{ "FL ", C_FLAG },
{ "AC ", C_ACTION },
{ "CMD", C_PROCESS },
{ "PID", C_PID },
{ "EXS", C_EXS },
{ "-RL", D_RUNLEVEL },
{ "-TL", D_THISLEVEL },
{ "-PL", D_PREVLEVEL },
{ "-SI", D_GOTSIGN },
{ "-WR", D_WROTE_WTMP_REBOOT},
{ "-WU", D_WROTE_UTMP_REBOOT},
{ "-ST", D_SLTIME },
{ "-DB", D_DIDBOOT },
{ "-LW", D_WROTE_WTMP_RLEVEL},
{ "-LU", D_WROTE_UTMP_RLEVEL},
{ "", 0   }
};
struct {
char *name;
int mask;
} flags[]={
{"RU",RUNNING},
{"DE",DEMAND},
{"XD",XECUTED},
{"WT",WAITING},
{NULL,0}
};
I'm not sure how the POWER FAIL,FAILNOW,WAIT,OKWAIT bits go.

Dig in and tell us what you think. :-)

I'm glad this came up again on IRC, or I'd never even have chased it down from /etc/init.d/xdm to man telinit (which I should have been looking at before, ofc) to its mention of initreq.h. Speaking of which, let's document that part here and now, for the purposes of this discussion, as well:
Code:
# This is here to serve as a note to myself, and future developers.
#
# Any Display manager (gdm,kdm,xdm) has the following problem:  if
# it is started before any getty, and no vt is specified, it will
# usually run on vt2.  When the getty on vt2 then starts, and the
# DM is already started, the getty will take control of the keyboard,
# leaving us with a "dead" keyboard.
#
# Resolution: add the following line to /etc/inittab
#
#  x:a:once:/etc/X11/startDM.sh
#
# and have /etc/X11/startDM.sh start the DM in daemon mode if
# a lock is present (with the info of what DM should be started),
# else just fall through.
#
# How this basically works, is the "a" runlevel is a additional
# runlevel that you can use to fork processes with init, but the
# runlevel never gets changed to this runlevel.  Along with the "a"
# runlevel, the "once" key word means that startDM.sh will only be
# run when we specify it to run, thus eliminating respawning
# startDM.sh when "xdm" is not added to the default runlevel, as was
# done previously.
#
# This script then just calls "telinit a", and init will run
# /etc/X11/startDM.sh after the current runlevel completes (this
# script should only be added to the actual runlevel the user is
# using).
#
# Martin Schlemmer
# aka Azarah
# 04 March 2002
There are also 'b' and 'c'; clearly the above had come up before. kbrequest also looks relevant.

It would certainly be simple enough to tweak and add things as we need (eg suspend and hibernate, if plausible), though equally it would be nice to ditch stuff if we can. In any event we must be careful both not to remove anything that someone else might rely on, only things we use internally, and further not to fall into the same trap of adding complexity in pid1, instead of pid2 and associated infrastructure.

I'm glad you guys are doing the minimal prototyping part, but ultimately I'm happy with sysvinit, since I don't think pid1 is where the fun is at. The most I'd want to do is cleanup the shutdown/suspend part so that shutdown.c works for runit as well as sysvinit, running on the same box, with the same code, as alternatives. And ofc anyone else who wants to play nicely. :-)

I find the code perfectly legible, myself, though init.c could use some minimal refactoring, in line with the comments. hddown.c for example is nice and clear to my eyes. (Apparently runit-init is missing hddown.c equivalent, which is needed for some lvm/mdraid setups, and "hddown.c is internally used from /sbin/halt when it's called by init in a special way iirc".)

Although you might want to split the file for differing systems, this doesn't rely on trickery from the build-system. Similarly init.c is self-contained, in the way it is telinit as well. So while they're separate processes, they have exactly the same code, so there's never any maintenance sync-issue.

You might not want that in the wider world, but it's nice at the init level, imo.

Note I'm not saying you want to reimplement the /dev/initctl protocol; just that it's important to know what needs to be supported. (and it seems better to document this stuff in your thread on a "modern" replacement.) As I said, I'd rather not have all that in pid1, same as you; it certainly shouldn't require versioning of the data-protocol, as anything that complex belongs in true userland.
Back to top
View user's profile Send private message
ShanaXXII
Apprentice
Apprentice


Joined: 29 Jun 2014
Posts: 283
Location: Canada

PostPosted: Tue Dec 09, 2014 7:32 pm    Post subject: Reply with quote

Great job! (:
I will also try/test it. (:

Hope this turns to something big.
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6920

PostPosted: Wed Dec 10, 2014 3:27 pm    Post subject: Reply with quote

Shamus397 wrote:
OK, the repository is located at http://shamusworld.gotdns.org/git/init-ng . There's very little in there ATM, and will likely stay small as the only things that will be added are a makefile, a C source file, and possibly an ebuild. :)

That's going to get confusing.

Edit: the site has died since I posted this, so I guess that answers that. For reference: https://web.archive.org/web/20150312202631/http://initng.org/trac


Last edited by Ant P. on Mon Apr 03, 2017 5:54 pm; edited 1 time in total
Back to top
View user's profile Send private message
Shamus397
Apprentice
Apprentice


Joined: 03 Apr 2005
Posts: 218
Location: Ur-th

PostPosted: Wed Dec 10, 2014 8:59 pm    Post subject: Reply with quote

@Ant P.: The funny thing is that I searched for 'init-ng' and it came back with nothing. Same thing looking through portage as well (nothing there).

Judging by the bug tracker, it looks like it hasn't seen an update in about four years or so. I suppose if it's too confusing (initng vs. init-ng) I can come up with another name. ;)

@jirutka: It's already a Git repository, and I can see no reason why I should host it on GitHub. Anyone can clone it, and can contribute patches back (and some already have). :)

@SteveL: Thanks, will look at it.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Thu Dec 11, 2014 12:59 pm    Post subject: Reply with quote

Found this yesterday, a relatively lucid write-up of what logind is doing.

Comparing the two setups: logind and VT (with X) I actually prefer the latter, without a central bottleneck pretending it's the kernel (which is the problem with dbus as well.)

The latter is from the previous post. Both posts are useful in that they actually diagram what is happening, whichever you prefer.

It seems like what they're talking about is part of the X DM at the moment, at least logically. Whether it's actually needed is another matter, as is whether the use-cases where it is needed are best done like this, or indeed merit changing every other use-case around for the niche; which as usual, is hardly a major problem for the vast majority of desktop and laptop users.

It's a bit like the whole "fast-user switching" nonsense, which was more a concern of organisational users, who one presumes have admins, than SOHO users (and that was shown to be a bust.) Again we have another diversion that has nothing to do with the personal-computing sphere, certainly not with the trend toward small, personal devices; used to justify idiotic changes across the board.

Personally I'd rather just go back to PAM and a desktop that works without major disruption every few weeks.
Back to top
View user's profile Send private message
tclover
Guru
Guru


Joined: 10 Apr 2011
Posts: 516

PostPosted: Fri Dec 12, 2014 3:09 pm    Post subject: Features+ Reply with quote

@stevL; CC: Shamus...

I gues socket activation is a nice *modern* feature to consider even if I don't see any real
benefit ASAP for a standard desktop/laptop user. However, I do get what could be achieved
with it... delaying service activation until needed. I guess, systems with dozen of init services
could benefit from it. Nice to have...

The other _fake_ awesome SystemD cgroup feature... I don't see any benefit regarding
adding unecessary stuff/overhead in PID1. And then, OpenRC take care of mounting cgroup
VFS and libcgroup is there to make any bell & whistle if need be when not using OpenRC.
So no need to waste any second on this as it's just a _fake_ feature of SystemD.

Regarding logind, I would not mind to have the session/seat feature without DBus merged
in a Display Manager (like xdm) (as an option?). But that's another story which shouldn't be
considered as part of a PID 1 extension.
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/
Back to top
View user's profile Send private message
tranquilcool
Veteran
Veteran


Joined: 25 Mar 2005
Posts: 1179

PostPosted: Fri Dec 12, 2014 6:52 pm    Post subject: Reply with quote

tried and it booted my system alright.
the downside is that it doesn't reboot or shutdown.
it complains about no /dev/initctl.
_________________
this is a strange strange world.
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Sat Dec 13, 2014 1:05 pm    Post subject: Reply with quote

As root "mknod -m 600 /dev/initctl p" will create it.

Not sure why it's not already created.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
Shamus397
Apprentice
Apprentice


Joined: 03 Apr 2005
Posts: 218
Location: Ur-th

PostPosted: Sat Dec 13, 2014 2:29 pm    Post subject: Reply with quote

@tranquilcool: Thanks for the report. That's really strange, there is no /dev/initctl on any of my testing rigs--it tries to open its socket at /run/initctl. Could it be there's no /run directory on your system? Could you paste the exact message you're getting? Are you able to run init by itself as root on the command line (after successfully booting, of course)? :)
Back to top
View user's profile Send private message
tranquilcool
Veteran
Veteran


Joined: 25 Mar 2005
Posts: 1179

PostPosted: Sat Dec 13, 2014 4:41 pm    Post subject: Reply with quote

Shamus397 wrote:
@tranquilcool: Thanks for the report. That's really strange, there is no /dev/initctl on any of my testing rigs--it tries to open its socket at /run/initctl. Could it be there's no /run directory on your system? Could you paste the exact message you're getting? Are you able to run init by itself as root on the command line (after successfully booting, of course)? :)


Thanks for your reply.
I can run init restart by itself, then kernel
panics. As soon as i get to my pc, i'll post
the exact message. Yes i have /run.
_________________
this is a strange strange world.
Back to top
View user's profile Send private message
Shamus397
Apprentice
Apprentice


Joined: 03 Apr 2005
Posts: 218
Location: Ur-th

PostPosted: Mon Dec 22, 2014 3:46 pm    Post subject: Reply with quote

OK, so to have reliable supervision of processes started by OpenRC, it will be necessary to patch start-stop-daemon to pitch the PID to init. Once I have this working, I'll post an update here. :)
Back to top
View user's profile Send private message
tclover
Guru
Guru


Joined: 10 Apr 2011
Posts: 516

PostPosted: Mon Dec 22, 2014 6:00 pm    Post subject: Reply with quote

Shamus397 wrote:
OK, so to have reliable supervision of processes started by OpenRC, it will be necessary to patch start-stop-daemon to pitch the PID to init. Once I have this working, I'll post an update here. :)


See the discussion on init pointed by steveL for more info. A better approach would be to add process supervision backends into OpenRC besides ssd (start-stop-daemon). (This is what I pointed to that discussion with s6/runit supervision suite possibility.) Unfortunately, I don't know much about OpenRC internal... so I've took a quick look into ssd source file... well, I guess backends in the lines of ssd (a single source/header file) to call a a specific backend wouldn't hurt instead of trying to patch ssd itself. Having @backend@ instead of plain ssd in init-script would make it easy to install init-scripts with a specified backend. Well, remain backend specific options (pidfile and such) to deal with. Maybe using env variables like SSD_ARGS would be necessary.

I have to dig a little into OpenRC source files to be able to help a little about this.
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sat Dec 27, 2014 1:00 pm    Post subject: Re: Features+ Reply with quote

tclover wrote:
I gues socket activation is a nice *modern* feature to consider even if I don't see any real
benefit ASAP for a standard desktop/laptop user. However, I do get what could be achieved
with it... delaying service activation until needed. I guess, systems with dozen of init services
could benefit from it. Nice to have...

Well the latter is why inetd was invented. The trouble with it in systemd is that it is used instead of dependencies. The idea appeals to a programmer who hasn't done their research, since it seems to indicate a "clever" shortcut, by which they don't "need" to worry about proper dependency resolution, which is pretty old-hat.
Quote:
The other _fake_ awesome SystemD cgroup feature... I don't see any benefit regarding
adding unecessary stuff/overhead in PID1. And then, OpenRC take care of mounting cgroup
VFS and libcgroup is there to make any bell & whistle if need be when not using OpenRC.
So no need to waste any second on this as it's just a _fake_ feature of SystemD.

Yeah, though libcgroup, if it's that other initscript we had in openrc, was a bit of a bust, afair; that's why we just went ahead and did our own minimal shell handlers. Anything configuration-wise really is down to the admin, and in that scenario it's better to let them just do w/e they want, afaic. By definition we're not around when the software is run.
Quote:
Regarding logind, I would not mind to have the session/seat feature without DBus merged
in a Display Manager (like xdm) (as an option?).

Well that's not that hard, in that all it's really about is labelling USB devices according to the hub they're attached to, and then picking up on that in Xorg conf. I'd still question whether it's really needed for the personal-computing era, but w/e floats your boat.
Quote:
But that's another story which shouldn't be considered as part of a PID 1 extension.

This is the bit I really wanted to quibble with (well it is Xmas, quibbling is practically de rigeur..;) If we're doing this correctly, it's not about PID 1 at all. It's about PID 2 and what it starts up, and how; especially whether it stays around to monitor whatever it's started up.

"Leave PID 1 alone" should be our mantra, afaic. The only changes I'd be comfortable with in sysvinit are to make it a bit simpler (not to extend it) so that it can be used with runit or s6 just as well as openrc, or anything else.
Back to top
View user's profile Send private message
Shamus397
Apprentice
Apprentice


Joined: 03 Apr 2005
Posts: 218
Location: Ur-th

PostPosted: Sat Dec 27, 2014 5:24 pm    Post subject: Reply with quote

Well, it seems to me that people want to make it more difficult/complex than it needs to be. I mean, bog standard Sys V init already does process management out-of-box (the "respawn" lines in your inittab). Hacking a small piece of code into start-stop-daemon is relatively easy, and it would still allow init-ng to leverage OpenRC, which is the correct approach IMO.

It probably wouldn't be that much work to create a PID 2 helper if the manager code got to be too hairy for PID 1, but at the moment, it doesn't look that way to me. :)
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sun Dec 28, 2014 8:44 pm    Post subject: Reply with quote

Shamus397 wrote:
Well, it seems to me that people want to make it more difficult/complex than it needs to be. I mean, bog standard Sys V init already does process management out-of-box (the "respawn" lines in your inittab).

That's exactly what I'm trying to say, too.
Quote:
Hacking a small piece of code into start-stop-daemon is relatively easy, and it would still allow init-ng to leverage OpenRC, which is the correct approach IMO.

Agreed here too; though I don't agree pid1 has got anything to do with it at all, since all of this is after pid1 has started up whatever we want, including openrc itself.
Quote:
It probably wouldn't be that much work to create a PID 2 helper if the manager code got to be too hairy for PID 1, but at the moment, it doesn't look that way to me. :)

Ah so you're saying let's have more "manager" code in pid1? Careful: this way systemd lies. ;)
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Unsupported Software All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum