* s6/s6-rc policy for Gentoo: The logging directory
@ 2024-07-05 23:45 Paul Sopka
2024-07-06 10:06 ` Laurent Bercot
2024-07-08 22:45 ` Peter Pentchev
0 siblings, 2 replies; 11+ messages in thread
From: Paul Sopka @ 2024-07-05 23:45 UTC (permalink / raw)
To: supervision
[-- Attachment #1.1.1: Type: text/plain, Size: 847 bytes --]
The last "thread" I open for this night. I promise.
I currently have set up logging in the following way:
System supervision tree logs to to /var/log/${daemon}
User supervision tree logs got to /var/log/${USER}/${daemon}
Currently, the logging dir is hardcoded in all s6-log daemons. I want to
change that.
Concerning the user tree loggers, this is easy, the system service
starting the user tree just sets an environment variable all user tree
s6-log daemons can use.
Concerning the system tree loggers, my first idea is to set an
environment variable somewhere in the scripts s6-linux-init provides.
Is this even possible?
What would be the best place to do this?
Is there a better alternative?
Generally, I would be interested hear what you think about my choice of
logging directories.
Paul
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3195 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: s6/s6-rc policy for Gentoo: The logging directory
2024-07-05 23:45 s6/s6-rc policy for Gentoo: The logging directory Paul Sopka
@ 2024-07-06 10:06 ` Laurent Bercot
2024-07-06 13:28 ` Paul Sopka
2024-07-08 22:45 ` Peter Pentchev
1 sibling, 1 reply; 11+ messages in thread
From: Laurent Bercot @ 2024-07-06 10:06 UTC (permalink / raw)
To: Paul Sopka, supervision
>Concerning the system tree loggers, my first idea is to set an environment variable somewhere in the scripts s6-linux-init provides.
>
>Is this even possible?
>
>What would be the best place to do this?
Any environment variable you want to make available for a whole
supervision tree should be added via a "-e var=value" option to your
s6-linux-init-maker invocation.
For user supervision trees, I suppose you're not using s6-l-i-m, so
the best place would be to put the variables in an envdir and use
"-E $envdir" (and possibly "-e $var" if you need to substitute $USER
or something) in your s6-usertree-maker invocation.
If you're not using these tools, the best way is to do the same thing
they do: put the variables in an envdir somewhere, and source the envdir
both before running s6-svscan and before running your s6-rc-init and
s6-rc script.
--
Laurent
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: s6/s6-rc policy for Gentoo: The logging directory
2024-07-06 10:06 ` Laurent Bercot
@ 2024-07-06 13:28 ` Paul Sopka
[not found] ` <ZoqyuyVTk4fBYm3s@sparta>
0 siblings, 1 reply; 11+ messages in thread
From: Paul Sopka @ 2024-07-06 13:28 UTC (permalink / raw)
To: Laurent Bercot, supervision
[-- Attachment #1.1.1: Type: text/plain, Size: 2823 bytes --]
> Any environment variable you want to make available for a whole
> supervision tree should be added via a "-e var=value" option to your
> s6-linux-init-maker invocation.
Thanks, will do!
> For user supervision trees, I suppose you're not using s6-l-i-m, so
> the best place would be to put the variables in an envdir and use
> "-E $envdir" (and possibly "-e $var" if you need to substitute $USER
> or something) in your s6-usertree-maker invocation.
> If you're not using these tools, the best way is to do the same thing
> they do: put the variables in an envdir somewhere, and source the envdir
> both before running s6-svscan and before running your s6-rc-init and
> s6-rc script.
I tested s6-usertree-maker, but I does not do everything I need. Anyway,
I based my currently working scripts on its output.
This is how it looks right now:
${USER}-sv/run:
#!/bin/execlineb -P
fdmove -c 2 1
define USER Nanderty
define XDG_RUNTIME_DIR /run/${USER}
emptyenv -p
export USER ${USER}
s6-envuidgid -i ${USER}
backtick -in HOME { homeof ${USER} }
multisubstitute
{
importas -Si USER
importas -Si HOME
importas -Si UID
importas -Si GID
importas -Si GIDLIST
}
foreground install -d -o ${USER} -g ${USER} -m 700 ${XDG_RUNTIME_DIR} ""
foreground install -d -o ${USER} -g ${USER} /var/log/${USER} ""
foreground install -d -o ${USER} -g ${USER} ${XDG_RUNTIME_DIR}/service ""
export XDG_DATA_HOME ${HOME}/.local/share
export XDG_STATE_HOME ${HOME}/.local/state
export XDG_CACHE_HOME ${HOME}/.cache
export XDG_RUNTIME_DIR ${XDG_RUNTIME_DIR}
export DBUS_SESSION_BUS_ADDRESS unix:path=${XDG_RUNTIME_DIR}/session-bus
s6-applyuidgid -U
s6-svscan -d3 ${XDG_RUNTIME_DIR}/service
${USER}-sv/finish:
#!/bin/execlineb -P
define USER Nanderty
rm -rf /run/${USER}
${USER}-rc/up:
#!/bin/execlineb -P
fdmove -c 2 1
define USER Nanderty
s6-setuidgid ${USER}
foreground {
s6-rc-init -c /home/${USER}/.local/share/s6-rc/compiled -l
/run/${USER}/s6-rc /run/${USER}/service
}
s6-rc -v2 -l /run/${USER}/s6-rc -up change default
${USER}-rc/down:
#!/bin/execlineb -P
define USER Nanderty
s6-setuidgid ${USER}
s6-rc -l /run/${USER}/s6-rc -bDa change
Plus, of course, the catch all logger for the ${USER}-sv process.
I would just export the logging dir variable as I do with the XDG_*
vars, so I do not need to source a variable dir. I would need to define
them in this script anyway, if I do not want to use the env-dir as a
permanent external config file.
Would you consider it a better way to utilize an env-dir as a means of a
config and source it in ${USER}-sv/run, thus exporting the vars for all
child processes anyway?
Thank you for your input.
Paul
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3195 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: s6/s6-rc policy for Gentoo: The logging directory
[not found] ` <ZoqyuyVTk4fBYm3s@sparta>
@ 2024-07-07 15:46 ` Paul Sopka
0 siblings, 0 replies; 11+ messages in thread
From: Paul Sopka @ 2024-07-07 15:46 UTC (permalink / raw)
To: Hoël Bézier, supervision
[-- Attachment #1.1.1: Type: text/plain, Size: 549 bytes --]
>> foreground install -d -o ${USER} -g ${USER} -m 700 ${XDG_RUNTIME_DIR} ""
>> foreground install -d -o ${USER} -g ${USER} /var/log/${USER} ""
>> foreground install -d -o ${USER} -g ${USER}
>> ${XDG_RUNTIME_DIR}/service ""
>
> foreground { install -d -o ${USER} -g ${USER} -m 700 ${XDG_RUNTIME_DIR} }
> foreground { install -d -o ${USER} -g ${USER} /var/log/${USER} }
> foreground { install -d -o ${USER} -g ${USER}
> ${XDG_RUNTIME_DIR}/service }
>
> This seems more idiomatic to me.
Agreed, will change.
Thank you!
Paul
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3195 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: s6/s6-rc policy for Gentoo: The logging directory
2024-07-05 23:45 s6/s6-rc policy for Gentoo: The logging directory Paul Sopka
2024-07-06 10:06 ` Laurent Bercot
@ 2024-07-08 22:45 ` Peter Pentchev
2024-07-09 0:03 ` Jan Braun
1 sibling, 1 reply; 11+ messages in thread
From: Peter Pentchev @ 2024-07-08 22:45 UTC (permalink / raw)
To: Paul Sopka; +Cc: supervision
[-- Attachment #1: Type: text/plain, Size: 850 bytes --]
On Sat, Jul 06, 2024 at 01:45:42AM +0200, Paul Sopka wrote:
> The last "thread" I open for this night. I promise.
>
> I currently have set up logging in the following way:
>
> System supervision tree logs to to /var/log/${daemon}
>
> User supervision tree logs got to /var/log/${USER}/${daemon}
Quick question (that you may have already thought about, apologies in
advance): what happens if one wants to start a new daemon that has
the same name as an already existing system user account?
Also, what happens if a new system user account is created with
the same name as an already configured service daemon?
G'luck,
Peter
--
Peter Pentchev roam@ringlet.net roam@debian.org peter@morpheusly.com
PGP key: https://www.ringlet.net/roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: s6/s6-rc policy for Gentoo: The logging directory
2024-07-08 22:45 ` Peter Pentchev
@ 2024-07-09 0:03 ` Jan Braun
2024-07-09 8:24 ` Paul Sopka
0 siblings, 1 reply; 11+ messages in thread
From: Jan Braun @ 2024-07-09 0:03 UTC (permalink / raw)
To: Peter Pentchev; +Cc: Paul Sopka, supervision
[-- Attachment #1: Type: text/plain, Size: 686 bytes --]
Peter Pentchev schrob:
> On Sat, Jul 06, 2024 at 01:45:42AM +0200, Paul Sopka wrote:
> > System supervision tree logs to to /var/log/${daemon}
> >
> > User supervision tree logs got to /var/log/${USER}/${daemon}
>
> Quick question (that you may have already thought about, apologies in
> advance): what happens if one wants to start a new daemon that has
> the same name as an already existing system user account?
> Also, what happens if a new system user account is created with
> the same name as an already configured service daemon?
Indeed. Those should be /var/log/s6/${daemon} and
/var/log/s6-user/${USER}/${daemon} respectively, to avoid stepping on
any toes.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: s6/s6-rc policy for Gentoo: The logging directory
2024-07-09 0:03 ` Jan Braun
@ 2024-07-09 8:24 ` Paul Sopka
2024-07-12 13:15 ` Carlos Eduardo
0 siblings, 1 reply; 11+ messages in thread
From: Paul Sopka @ 2024-07-09 8:24 UTC (permalink / raw)
To: Peter Pentchev, supervision, janbraun
[-- Attachment #1.1.1: Type: text/plain, Size: 631 bytes --]
> Quick question (that you may have already thought about, apologies in
> advance): what happens if one wants to start a new daemon that has
> the same name as an already existing system user account?
> Also, what happens if a new system user account is created with
> the same name as an already configured service daemon?
Thank you for the heads up and don't apologize, you are completely right.
> Indeed. Those should be /var/log/s6/${daemon} and
> /var/log/s6-user/${USER}/${daemon} respectively, to avoid stepping on
> any toes.
This seems sensible, but I will think a bit more about the exact naming.
Paul
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3195 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: s6/s6-rc policy for Gentoo: The logging directory
2024-07-09 8:24 ` Paul Sopka
@ 2024-07-12 13:15 ` Carlos Eduardo
2024-07-13 10:04 ` Paul Sopka
0 siblings, 1 reply; 11+ messages in thread
From: Carlos Eduardo @ 2024-07-12 13:15 UTC (permalink / raw)
To: Paul Sopka; +Cc: Peter Pentchev, supervision, janbraun
[-- Attachment #1: Type: text/plain, Size: 1243 bytes --]
On my setup, logs are stored under a dot-directory in my home directory,
which avoids needing any cooperation from root when setting up user
services (and the mentioned risk of overlap between user and system
services).
Due to /var == ~/.local/state according to the XDG spec (which, from your
other threads, you seem to want to follow closely), you might want to use
"${HOME}/.local/state/log/${daemon}" [1].
[1] https://forum.artixlinux.org/index.php/topic,6918.msg41919.html#msg41919
Em ter., 9 de jul. de 2024 às 05:24, Paul Sopka <psopka@sopka.ch> escreveu:
>
> > Quick question (that you may have already thought about, apologies in
> > advance): what happens if one wants to start a new daemon that has
> > the same name as an already existing system user account?
> > Also, what happens if a new system user account is created with
> > the same name as an already configured service daemon?
> Thank you for the heads up and don't apologize, you are completely right.
> > Indeed. Those should be /var/log/s6/${daemon} and
> > /var/log/s6-user/${USER}/${daemon} respectively, to avoid stepping on
> > any toes.
>
> This seems sensible, but I will think a bit more about the exact naming.
>
>
> Paul
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: s6/s6-rc policy for Gentoo: The logging directory
2024-07-12 13:15 ` Carlos Eduardo
@ 2024-07-13 10:04 ` Paul Sopka
2024-07-14 15:25 ` Jan Braun
0 siblings, 1 reply; 11+ messages in thread
From: Paul Sopka @ 2024-07-13 10:04 UTC (permalink / raw)
To: Carlos Eduardo, supervision
[-- Attachment #1.1.1.1: Type: text/plain, Size: 2105 bytes --]
> On my setup, logs are stored under a dot-directory in my home directory,
> which avoids needing any cooperation from root when setting up user
> services (and the mentioned risk of overlap between user and system
> services).
Since I have a system service setting up the user service tree, this is
a non-issue for me. As of now, this service just creates a user owned
subdir /var/log/s6/user/${USER}, where all logs from ${USER} go. Thus
the main thing probably ends up weighing "having all logs at one
place"(at /var/log/s6) against "having all user-stuff as well as the
logs in one place" (at ~/).
If I now compare this to ${XDG_RUNTIME_DIR} and the service dir of the
s6 user-tree, it follows that, should I have the logs at "~/...", why do
I have "${XDG_RUNTIME_DIR} as well as the service dir of the user" at
/run/...
It is clear that those should reside in tmpfs for speed and the elegance
of self clean up on boot, should something go wrong. I would consider
mounting an tmpfs for every user having set up user-services at "~/"
needlessly complicated and overkill.
For consistency reasons it then follows that the user tree logs should
be in a dir at /var/log/s6/users/${USER} or something comparable, as the
"${XDG_RUNTIME_DIR} and service dir of the user" are at
/run/user/${USER} or comparable. With the nice bonus of having all the
logs in one place.
What do you think about that reasoning?
> Due to /var == ~/.local/state according to the XDG spec (which, from your
> other threads, you seem to want to follow closely), you might want to use
> "${HOME}/.local/state/log/${daemon}" [1].
I do not *want* to adhere to the XDG spec, it just seemed sensible to me
and nobody has provided any reason against it so far.
Anyway, [1] made me think about why not to use a "/"-like structure
under "~/" (e.g. ~/.var, ~/.etc) instead of the XDG spec. Can you point
me to any thread/list discussing that?
> [1]https://forum.artixlinux.org/index.php/topic,6918.msg41919.html#msg41919
I wish you a very nice weekend!
Paul
[-- Attachment #1.1.1.2: Type: text/html, Size: 2991 bytes --]
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3195 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: s6/s6-rc policy for Gentoo: The logging directory
2024-07-13 10:04 ` Paul Sopka
@ 2024-07-14 15:25 ` Jan Braun
2024-07-14 20:57 ` Paul Sopka
0 siblings, 1 reply; 11+ messages in thread
From: Jan Braun @ 2024-07-14 15:25 UTC (permalink / raw)
To: Paul Sopka; +Cc: Carlos Eduardo, supervision
[-- Attachment #1: Type: text/plain, Size: 905 bytes --]
Hey,
Paul Sopka schrob:
> [ user services have service dir in /run and logs in /var ]
> What do you think about that reasoning?
Agree.
Besides consistency, putting those below $HOME would also break in NFS
setups where $HOME is shared among several machines.
> I do not *want* to adhere to the XDG spec, it just seemed sensible to me and
> nobody has provided any reason against it so far.
See reason above. ;) But otherwise the correct sentiment.
> Anyway, [1] made me think about why not to use a "/"-like structure under
> "~/" (e.g. ~/.var, ~/.etc) instead of the XDG spec. Can you point me to any
> thread/list discussing that?
Please don't. There's already 2 different standards for dotfiles (XDG
and ~/.nameofprogram), inventing a third one is a case of
https://xkcd.com/927/
(But per the above, ~/ is not apropriate anyway, so the point is moot.)
cheers,
Jan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: s6/s6-rc policy for Gentoo: The logging directory
2024-07-14 15:25 ` Jan Braun
@ 2024-07-14 20:57 ` Paul Sopka
0 siblings, 0 replies; 11+ messages in thread
From: Paul Sopka @ 2024-07-14 20:57 UTC (permalink / raw)
To: Carlos Eduardo, supervision
[-- Attachment #1.1.1: Type: text/plain, Size: 721 bytes --]
> Besides consistency, putting those below $HOME would also break in NFS
> setups where $HOME is shared among several machines.
Good point. I will keep the user logs at /var/log/s6/user/${USER} for now.
> Please don't. There's already 2 different standards for dotfiles (XDG
> and ~/.nameofprogram), inventing a third one is a case of
> https://xkcd.com/927/
> (But per the above, ~/ is not apropriate anyway, so the point is moot.)
I am not planning that, don't worry. I am only thinking about the idea.
Generally, I think sometimes the 15th standard is needed if the other
fourteen are terrible enough. People made the same joke about pipewire
when it was started xD.
Have a nice week!
Paul
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3195 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2024-07-14 20:57 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-07-05 23:45 s6/s6-rc policy for Gentoo: The logging directory Paul Sopka
2024-07-06 10:06 ` Laurent Bercot
2024-07-06 13:28 ` Paul Sopka
[not found] ` <ZoqyuyVTk4fBYm3s@sparta>
2024-07-07 15:46 ` Paul Sopka
2024-07-08 22:45 ` Peter Pentchev
2024-07-09 0:03 ` Jan Braun
2024-07-09 8:24 ` Paul Sopka
2024-07-12 13:15 ` Carlos Eduardo
2024-07-13 10:04 ` Paul Sopka
2024-07-14 15:25 ` Jan Braun
2024-07-14 20:57 ` Paul Sopka
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).