Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
s6
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
rain1
n00b
n00b


Joined: 13 Apr 2018
Posts: 8

PostPosted: Sat Apr 14, 2018 3:18 pm    Post subject: s6 Reply with quote

Hello. I am interested in s6 as init/pid 1. I have installed gentoo in a qemu virtual machine to experiment with. So far I have added a grub menu which lets me boot without initramfs into stage 1 execline init script, then it hands off to the stage 2 and starts loading up the compiled database of services. It's not booting all the way yet but it's a start. I have been studying the follow sources to try to get it working:



Anyway I just wanted to make a thread on this topic, i'll update when I have more information. and hopefully see if anybody else is interested in it.

Update: Now that I have agetty set up, I can actually boot gentoo and get into a shell: https://i.imgur.com/1ENLuGB.png Good start.


Last edited by rain1 on Mon Jun 18, 2018 12:59 am; edited 2 times in total
Back to top
View user's profile Send private message
Dr.Willy
Guru
Guru


Joined: 15 Jul 2007
Posts: 547
Location: NRW, Germany

PostPosted: Wed Apr 18, 2018 7:33 pm    Post subject: Reply with quote

I have a s6+openrc configuration set up. I've been meaning to replace openrc with s6-rc, however so far that hasn't really amounted to anything presentable.
Back to top
View user's profile Send private message
rain1
n00b
n00b


Joined: 13 Apr 2018
Posts: 8

PostPosted: Thu Apr 19, 2018 9:46 pm    Post subject: Reply with quote

Dr.Willy wrote:
I have a s6+openrc configuration set up. I've been meaning to replace openrc with s6-rc, however so far that hasn't really amounted to anything presentable.


Awesome! Anything you could share would be a great help.
Back to top
View user's profile Send private message
rain1
n00b
n00b


Joined: 13 Apr 2018
Posts: 8

PostPosted: Sun Jun 17, 2018 9:36 pm    Post subject: Reply with quote

Here are some notes from today's session. I started with a fresh gentoo install, without initramfs.

step 2

Add the following to /etc/portage/package.accept_keywords so that we can install all the s6 tools
Code:

dev-libs/skalibs
dev-lang/execline
sys-apps/s6
# required by sys-apps/s6-linux-init-0.4.0.0::gentoo
# required by sys-apps/s6-linux-init (argument)
=sys-apps/s6-linux-utils-2.4.0.2 ~amd64
# required by sys-apps/s6-linux-init-0.4.0.0::gentoo
# required by sys-apps/s6-linux-init (argument)
=sys-apps/s6-portable-utils-2.2.1.1 ~amd64
# required by sys-apps/s6-linux-init (argument)
=sys-apps/s6-linux-init-0.4.0.0 ~amd64
# required by s6-rc (argument)
=sys-apps/s6-rc-0.4.0.1 ~amd64


step 3

Code:

emerge sys-apps/s6
emerge sys-apps/s6-linux-init
emerge execline
emerge s6-rc


step 4

We want to add an extra GRUB menu item so that we can pick our init system on boot. We boot into normal openrc gentoo linux to work on this stuff, then boot into the s6 init system to test our changes.


Edit /etc/grub.d/40_custom

Code:

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.

menuentry "s6" {
   insmod ext2
   set root='hd0,msdos1'
   echo 'loading linux with s6'
   linux /boot/vmlinuz-4.9.95-gentoo root=/dev/sda1 init=/bin/sh ro
}


Regenerate the grub config grub-mkconfig -o /boot/grub/grub.cfg

step 5

Use s6 init maker to build up the stage1 init:

Code:
rm -rf /s6
s6-linux-init-maker -c /s6 -G '/sbin/agetty 38400 tty1' -2 /s6/scripts/rc.init -Z /s6/scripts/shutdown /s6
mkdir -p /s6/scripts
touch /s6/scripts/rc.init
touch /s6/scripts/shutdown
chmod +x /s6/scripts/shutdown /s6/scripts/rc.init


Now fill up those 2 files.

Code:

curl -o /s6/scripts/rc.init https://raw.githubusercontent.com/skarnet/s6-linux-init/master/examples/rc.init

/s6/scripts/shutdown
#!/bin/sh
# https://skarnet.org/software/s6-linux-init/quickstart.html
exec s6-rc -da change


and then you can edit the grub config to /s6/init and regen it.[/code]
Back to top
View user's profile Send private message
rain1
n00b
n00b


Joined: 13 Apr 2018
Posts: 8

PostPosted: Sun Jun 17, 2018 9:40 pm    Post subject: Reply with quote

step 6

that should boot up, but you wont have /proc or a writable filesystem. To get these parts working we need to build an s6 stage2 compiled s6-rc script folder.

I will make a git repo called `gentoo-s6-services` with more useful things in it, but for starting we are copying parts from lh-bootstrap:

on the host:
Code:

$ mkdir gentoo-s6-services
$ cp -r lh-bootstrap/layout/rootfs/etc/s6-rc/source-base/00/ gentoo-s6-services/
$ cp -r lh-bootstrap/layout/rootfs/etc/s6-rc/source-base/mount-proc/ gentoo-s6-services/


scp it in to /root then in the host:

Code:

s6-rc-compile /run/services /root/gentoo-s6-services


and update /s6/rc.init to point to the compiled service dir

Code:

if { s6-rc-init -c /s6/scripts/compiled/ /run/service }[/b]


This should give you /proc mounted, I have written service to remount the rootfs as writable too, and start up static eth0 networking. Working on sshd and dhcp next.
Back to top
View user's profile Send private message
rain1
n00b
n00b


Joined: 13 Apr 2018
Posts: 8

PostPosted: Mon Jun 18, 2018 2:53 pm    Post subject: Reply with quote

I have made a repo for the gentoo s6 services that I am working on. It is very bare at the moment because I'm still learning a lot about how s6 works. https://github.com/rain-1/gentoo-s6-services

ssh
Today I've got sshd starting up correctly supervised by s6 and also a special logging service for it. It was important to pass the -e flag to sshd so that it would log to stderr in order that s6 log can capture it. By default it logs to the system log. This may be a common pitfall when writing service dirs.

I was shown the commans ps afuxww (or alternatively s6-ps -H) which are very useful for visualizing the service tree and seeing which service failed to start.

Another thing of note is that the 00 service (and eth0) use an env variable directory to load up custom options for the service. In this case the computers hostname.

ssh killer
One of the issues with ssh is that when i reboot, the terminals that were ssh'ing in get jammed and if you wait a while you may get a broken pipe error. What is much nicer is when the shutdown process cleanly terminates all ssh sessions before taking down networking and rebooting.

I created an ssh-killer service to do this: It uses pkill which isn't the ideal solution but it works so I'll leave it at that for now. Using pkill isn't great becaues it has to pause every process on the system (including pid 1) then kill, then unpause.

Gentoo bug on this same issue https://bugs.gentoo.org/259183 I think systemd does it using dbus.[/b]
Back to top
View user's profile Send private message
rain1
n00b
n00b


Joined: 13 Apr 2018
Posts: 8

PostPosted: Tue Jun 19, 2018 7:38 pm    Post subject: Reply with quote

I stop working on this over disagreements with lead dev on security.

https://skarnet.org/software/s6/s6-log.html
s6 log uses the executable bit on the log files to signal 1 bit of information: whether or not the log is currently being written
but an attacker can often influence the content of log files (e.g. ssh in with `nastycommand` as username)
so it feels like abusing the +x bit for this purpose opens up a potential security weakness similar to httpd log poisoning
it is similar to a standard http log poisoning lfi to shell attack.

they just reject that this is an issue and are insulting about my bug report.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21490

PostPosted: Wed Jun 20, 2018 2:11 am    Post subject: Reply with quote

Setting +x on a file to represent temporary state is horrible and wrong. However, rather than abandon the project, you could apply an ebuild patch to remove that bit of trouble.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


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

PostPosted: Wed Jun 20, 2018 12:19 pm    Post subject: Reply with quote

rain1 wrote:
I stop working on this over disagreements with lead dev on security.

rain1 ... that's a shame, as I was interested/following.

best ... khay
Back to top
View user's profile Send private message
rain1
n00b
n00b


Joined: 13 Apr 2018
Posts: 8

PostPosted: Wed Jun 20, 2018 7:01 pm    Post subject: Reply with quote

sorry folks I didn't realize there were so many people interested in it. I am disappointed too. Mostly that we were not able to resolve the issue by discussion and it went into name calling and insults. It isn't a good sign if other flaws were found would they be ignored too..

Anyway, there are a couple ways to remedy it. One could maintain a hardening patchset but that can become a lot of work. Another option would be to mount the log partition noexec, openbsd style. I may look into implementing this. A shame that it requires repartitioning the disk though.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21490

PostPosted: Thu Jun 21, 2018 1:18 am    Post subject: Reply with quote

rain1 wrote:
sorry folks I didn't realize there were so many people interested in it.
I am not interested in it. I just don't like seeing people run off from a project over political issues.
rain1 wrote:
It isn't a good sign if other flaws were found would they be ignored too..
Agreed.
rain1 wrote:
Another option would be to mount the log partition noexec, openbsd style. I may look into implementing this. A shame that it requires repartitioning the disk though.
Why would you need to repartition for this?
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


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

PostPosted: Thu Jun 21, 2018 8:12 am    Post subject: Reply with quote

rain1 wrote:
sorry folks I didn't realize there were so many people interested in it. I am disappointed too. Mostly that we were not able to resolve the issue by discussion and it went into name calling and insults. It isn't a good sign if other flaws were found would they be ignored too.

rain1 ... I looked for the discussion on the supervision mailing list but it seems this occurred on irc. I find Laurent mostly amiable, and I agree with most of what he has to say (he has an account here, and has engaged in various discussions), so I wonder what it is/was that would set you at loggerheads, or why he wouldn't see +x as a rather odd way of setting status. Anyhow, I doubt this is a sign of his unwillingness to consider criticism in general, you may have caught him on a bad day, who knows.

One criticism I could make myself (from the perspective of trying to understand s6 as a novice) is that the lack of a standard namespace for service directories makes it very difficult when looking at how people are using it, you see all manner of "service" setups that it makes it hard to digest the underlying methodology. I understand the rational behind "seperation of mechanism from policy" but were there some attempt to standardise naming it might make adoption, and comprehension, somewhat less of a struggle. If I look at, and compare, the stuff out there there is no "aha!" moment, why use "00" (as I've seen in various places) and then not follow with something that would make the runlevel obvious (or at least structured to make what follows make sense from that perspective). Not all hosts are the same, obviously, but what needs to happen can be reduced to some kind of structure, at least where names are concerned.

best ... khay
Back to top
View user's profile Send private message
Dr.Willy
Guru
Guru


Joined: 15 Jul 2007
Posts: 547
Location: NRW, Germany

PostPosted: Mon Jul 02, 2018 12:21 pm    Post subject: Reply with quote

khayyam wrote:
One criticism I could make myself (from the perspective of trying to understand s6 as a novice) is that the lack of a standard namespace for service directories makes it very difficult when looking at how people are using it, you see all manner of "service" setups that it makes it hard to digest the underlying methodology. I understand the rational behind "seperation of mechanism from policy" but were there some attempt to standardise naming it might make adoption, and comprehension, somewhat less of a struggle. If I look at, and compare, the stuff out there there is no "aha!" moment, why use "00" (as I've seen in various places) and then not follow with something that would make the runlevel obvious (or at least structured to make what follows make sense from that perspective). Not all hosts are the same, obviously, but what needs to happen can be reduced to some kind of structure, at least where names are concerned.

Well for a start you could just copy the scheme from openrc.
Back to top
View user's profile Send private message
fxkrait
n00b
n00b


Joined: 30 Jul 2018
Posts: 15
Location: DRPK

PostPosted: Thu Aug 02, 2018 4:13 am    Post subject: Reply with quote

I just came from Obarun, which is Arch + S6 init. Would be really cool if Gentoo supported this. From what I've gathered it is a pretty decent init, even better than runit.
_________________
A great painter does not content himself by affecting us with his masterpieces; ultimately, he succeeds in changing the landscape of our minds. Once a miniaturist's artistry enters our souls this way, it becomes the criterion for the beauty of our world.
Back to top
View user's profile Send private message
skarnet
n00b
n00b


Joined: 01 Jul 2014
Posts: 25
Location: Paris, France

PostPosted: Sun Sep 16, 2018 10:35 pm    Post subject: Reply with quote

I was made aware today of the existence of this thread, and it looks like you guys only got one side of the story. I normally would not mind, because I don't have the interest, time or energy for social media drama, but what I will not accept is driving people away from experimenting with s6 with falsehoods or disingenuous FUD.

rain1 wrote:
sorry folks I didn't realize there were so many people interested in it. I am disappointed too. Mostly that we were not able to resolve the issue by discussion and it went into name calling and insults. It isn't a good sign if other flaws were found would they be ignored too..


So here's the thing.
There is a design choice in s6-log: using the 0100 bit on the logdir/current file as a flag (whether the file is finalized or not).
The reason for this choice is purely technical and an implementation detail. It makes the rotation state machine much simpler and easier to implement than other choices to represent a flag, which have many more failure modes. Even using another, empty, file in the logdir can fail in more cases, including running out of inodes. It's only a little more complex, but it's still more complex.

I will agree that this choice is not pretty. I totally get that, and I totally understand that people may not like it. That's fair.
But there's another thing that this choice is not: a security risk. And any person who pretends it's a security risk is either confused about what "a security risk" means, or ignorant of how Unix works, or ill-intentioned.
  • The current file is owned by the logging user. Only the logging user can ever misuse it. There is no crossing of privilege boundaries, ever - which is what a security risk means. The only thing that might ever happen is someone (root, essentially) taking the credentials of the logging user, and using this executable bit to shoot themselves in the foot - but if you have access to the account, you can already wreak havoc on it anyway. There's nothing you can do with this executable bit that you can't do without it: so any claim that it's a security issue is nonsense.
  • Why would you ever execute a log file? This is Unix, which was never designed to be foolproof. If you're a sysadmin, you're supposed to know what you're doing. You're not supposed to randomly execute files, even if they have an x bit. Also, logs are text files, and unless you deactivated timestamps and your daemon is especially malicious there's zero chance a log file starts with #!, so the probability that executing a log file will do anything else than loudly fail is close to zero. But even if it did anything else, it would be 100% your fault, because you have no business executing log files.
  • The presence of the x bit on a text file does not make it more dangerous. Did you know you can try to execute any file, without the x bit, as a shell script, by calling "/bin/sh file"? Or more generally, you can try to execute any file without the x bit as the code for any interpreted language, by calling "path-to-interpreter file" ? So if you really want to be an idiot and try to mess up the logging user by randomly executing log files, you can already do so anyway.

The design of this particular part of s6-log might be aesthetically questionable, but it changes exactly nothing to what you can or cannot do with log files or the log user: it is by no means a security risk, and any person who understands Unix understands this.
I explained this to rain1 twice on IRC, but he kept disagreeing and pretending it was a security risk. It was taking a lot of bandwidth on the channel and distracting me from other s6-related conversations with more substance and more technical grounding, so I refused to engage any further, telling rain1 to figure this out by himself and to stop wasting my time until then. I did not insult anyone; I did call rain1 disrespectful, because that's what insisting on taking space while being wrong is.

We have since mended somewhat, but I was not aware of this thread, and I am displeased that he would speak ill of s6 to other people just because we happened to have a disagreement he was wrong about. This is a very bad look, especially since he also did this on lobste.rs. Given the harm this FUD-spreading behaviour can cause to a project, I'm not sure it's a good idea to keep such a person in the project's community, and will have to think about it.

I can only encourage people to keep trying out s6 and making their own opinion about it, and give my reassurance that any issue, especially a security issue, will be seriously investigated, as they always have been. What will not be investigated, however, is obvious bullshit, no matter how insistent. There are enough serious, technically interesting, welcome discussions to have around s6, so I would like this nothing-burger to stop taking their space.

Edit: typo
_________________
Laurent


Last edited by skarnet on Thu Sep 20, 2018 10:48 pm; edited 1 time in total
Back to top
View user's profile Send private message
Akkara
Bodhisattva
Bodhisattva


Joined: 28 Mar 2006
Posts: 6702
Location: &akkara

PostPosted: Mon Sep 17, 2018 4:36 am    Post subject: Reply with quote

I don't know anything about s6 except for what was said in this thread, so the following suggestion might be naive, but:

I understand you need a way of indicating whether the file is currently in flux (being written to). Is that correct?

If so, couldn't the 'w' write bit be used for this purpose? The process of updating the file would then involve,
  • Chmod +w
  • Open file for writing
  • Write
  • Close file
  • Chmod -w
Seems to me like a natural for this purpose. Of course there may be reasons I'm not aware of why it can't be used. But if it can be made work, not only will it remove the objections over using the 'x' bit (whether unfounded or not), but it also more directly shows the intent, and it makes it impossible to have a bug when the file is being written but the bit hadn't been flipped to indicate this.

Hmmm... and now that I think of it some more, I'm guessing you probably already considered it and rejected it for some reason, in favor of the 'x' bit. I'd be curious what stops 'w' from working.
_________________
Many think that Dilbert is a comic. Unfortunately it is a documentary.
Back to top
View user's profile Send private message
Jimmy Jazz
Guru
Guru


Joined: 04 Oct 2004
Posts: 325
Location: Strasbourg

PostPosted: Mon Sep 17, 2018 1:54 pm    Post subject: Reply with quote

I like the way s6 is written and use the mdevd deamon myself.
I suggest,
- test the old no more used sticky bit (chmod 1600 logfile)
- test the existence of a hard link on the log file (not all system support hard link, its creation is exclusive).
- the filesystem could be mounted with option noexec

Otherwise if the log file has an execute bit enabled, the head of the file could contain:
#!/bin/cat
or
[ ${0##*/} = logfile ] && exit 2

even a directory could work
#!/var/empty

but i could be absolutely false :)
_________________
« La seule condition au triomphe du mal, c'est l'inaction des gens de bien » E.Burke
Code:

+----+----+----+
|    |::::|    |
|    |::::|    |
+----+----+----+

motto: WeLCRO
WritE Less Code, Repeat Often
Back to top
View user's profile Send private message
skarnet
n00b
n00b


Joined: 01 Jul 2014
Posts: 25
Location: Paris, France

PostPosted: Mon Sep 17, 2018 8:19 pm    Post subject: Reply with quote

  • The w bit doesn't work... simply because I need to open the log file for writing before clearing the "finalized" marker. And you can't open a file for writing if it doesn't already have the w bit.
  • BSD/OS doesn't support the sticky bit on regular files. It's been discontinued for 15 years, but who knows. :) The sticky bit on regular files is a legacy thing that I don't trust operating systems to keep honoring forever. At some point, kernels will decide to use it for something else, they will assign real meaning to it - or they will stop supporting it. I'd rather use a bit with well-defined semantics that won't change, knowing using that bit is harmless though ugly, than use an old bit that could get reassigned at any time.
  • The existence of hard links is not a good marker because nothing should prevent the log user from creating their own hard links. It is not specified that hard links are forbidden, and there's no reason it should be when another solution exists that does not need that restriction.
  • Mounting the log filesystem noexec is an excellent idea, but that's a decision I have no power on - only the administrators can take it. If an admin mounts the logfs noexec, then the x bit loses its original meaning on this partition, and using it as s6-log does becomes 100% legit. You should totally do this. :wink:

_________________
Laurent
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21490

PostPosted: Tue Sep 18, 2018 1:16 am    Post subject: Reply with quote

If a file is +w when it is in flux and -w when it is "stable", what is the problem with the ordering? You would mark it +w (declaring it in flux), then open it for writing (at which point it truly is in flux). You get a small race where the file is claimed to be in flux when it isn't, but that should be harmless. Any tools that care about whether a file is in flux should be correct as long as an actively-used file is properly marked. An inactive file that is becoming active can be said to be active without breaking the rules, since there is no distinction between an in-use file that has not yet been written (because nobody has generated logs yet) versus a not-in-use file that claims to be in-use (because it is about to be in use).

If you are actively concerned about keeping the state flag accurate in case of an untimely crash, what about using a file lock (which the kernel will naturally clear on reboot) instead of a file bit?

As for sticky, at least on Linux, I doubt the kernel will ever repurpose it in a way that breaks your code. Linus is very strict about not breaking user tools, even when the break is caused by fixing kernel bugs (with some limited exception for fixing security bugs). I don't know if the BSD maintainers have that same level of strictness, or what they would do with that bit if they are less strict.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


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

PostPosted: Wed Sep 19, 2018 6:21 am    Post subject: Reply with quote

Hu wrote:
Setting +x on a file to represent temporary state is horrible and wrong.
Bah, humbug. It's a very old trick used for conf files originally; so the admin would mark +x to indicate that the conf should be read, with default delivery being nothing (nice and clean.)
Personally I still favour that approach, even if no-one uses it. (It's only used in /etc, and it means ls indicates clearly which files are being used, in addition to the simple control which is the point of it.)

FWIW I agree with you about the write bit on files you own; I am not sure how that interacts with a logging daemon and services that own their logfiles as a specific account (they should definitely run as non-root, imo.)

As for stick #! whatever at the front, that's nonsense; just echo a newline to begin the file (if you don't have a standard #header), and your worries are over. (You can put whatever you want, so long as the first two bytes are not #!.)
Additionally, shebang files are never run suid on Linux (which is a help, though does not address the whole issue of execution.)

Shell does not need /bin/sh file to execute; it is defined to try running a command as a sh file, in the event of a return from exec.
Think for a moment how useful that is, especially in make. (It means you are not dependent on the specific path given, eg on Solaris, which has /usr/bin/xpg.)
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6920

PostPosted: Wed Sep 19, 2018 12:51 pm    Post subject: Reply with quote

FWIW runit and daemontools also use u+x as a semaphore, it's not like s6 is just making this up.

Those that don't understand unix always seem to want to throw it out for "enterprise solutions"...
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21490

PostPosted: Thu Sep 20, 2018 1:04 am    Post subject: Reply with quote

steveL wrote:
Hu wrote:
Setting +x on a file to represent temporary state is horrible and wrong.
Bah, humbug. It's a very old trick used for conf files originally; so the admin would mark +x to indicate that the conf should be read, with default delivery being nothing (nice and clean.)
I may have confused matters by addressing the +w bit more recently, but part of my complaint with +x (and the reason I said "temporary state") is that file modes are part of the file system and persist until the file is deleted. Whether the file is actively being written is a transient condition that can change without updating the flag if the system is reset by power failure or if the logging process crashes. Transient state should be tracked by a transient variable that will also reset automatically when the transient state changes. As I understand the implementation from the discussion here, permanent state (+x) is being used to track a temporary condition. That is what I consider to be wrong.

To address your remark, steveL, while I don't much care for marking configuration files like that, that convention at least matches stable filesystem state to stable usage.
Back to top
View user's profile Send private message
skarnet
n00b
n00b


Joined: 01 Jul 2014
Posts: 25
Location: Paris, France

PostPosted: Thu Sep 20, 2018 6:15 am    Post subject: Reply with quote

Hu wrote:
As I understand the implementation from the discussion here, permanent state (+x) is being used to track a temporary condition.

This is not the case, and I wonder what made you think so. Tracking temporary conditions is done via flags in RAM, obviously.

The point of using the x bit is precisely that it remains the same across process deaths. It's used to transmit information from an invocation of s6-log to the next one, namely: did s6-log correctly finalize the file before exiting (+x) or did it exit early in which case the file may need some processing before it gets appended to? (-x)

People who know s6 know that one of its advantages is that it doesn't use .pid files, which are the poster child for the "storing transient state in the filesystem" mistake. It's precisely one of the points that s6 goes out of its way to address. Once again, I welcome criticism about s6, but I'd like it to be about what it really does, not about what people mistakenly think it does.
_________________
Laurent
Back to top
View user's profile Send private message
Jimmy Jazz
Guru
Guru


Joined: 04 Oct 2004
Posts: 325
Location: Strasbourg

PostPosted: Thu Sep 20, 2018 3:58 pm    Post subject: Reply with quote

steveL wrote:

As for stick #! whatever at the front, that's nonsense; just echo a newline to begin the file (if you don't have a standard #header), and your worries are over. (You can put whatever you want, so long as the first two bytes are not #!.)


Not so hasty. You forget the code error returned if an error has occurred. echo a newline or # to the begin of the file returns always 0. Better see a code error as nothing.

BTW I still use the x flag for config files to exclude some of then in a directory :)
_________________
« La seule condition au triomphe du mal, c'est l'inaction des gens de bien » E.Burke
Code:

+----+----+----+
|    |::::|    |
|    |::::|    |
+----+----+----+

motto: WeLCRO
WritE Less Code, Repeat Often
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21490

PostPosted: Fri Sep 21, 2018 1:30 am    Post subject: Reply with quote

skarnet wrote:
Hu wrote:
As I understand the implementation from the discussion here, permanent state (+x) is being used to track a temporary condition.
This is not the case, and I wonder what made you think so. Tracking temporary conditions is done via flags in RAM, obviously.
rain1 said so (which prompted the post where I said using +x was horrible and wrong. Nobody corrected that statement.
rain1 wrote:
s6 log uses the executable bit on the log files to signal 1 bit of information: whether or not the log is currently being written
"currently being written" is, to me, roughly equal to "currently open for writing", which is a transient condition. Your opening post to correct rain1 touched on this briefly, but not in a way that definitively confirmed or refuted that interpretation:
skarnet wrote:
There is a design choice in s6-log: using the 0100 bit on the logdir/current file as a flag (whether the file is finalized or not).
That post never came back to define what is meant by "finalized", leaving it ambiguous whether a file that is not open for writing is always considered finalized or if special handling elsewhere is required to declare it finalized. (Your latest post addresses this more directly. Still, I find it a bit odd to intentionally leave a file in a state that requires special close-out logic before rotation.)
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