Re: [systemd-devel] At wits end... need to execute a script prior to anything getting killed/changed on reboot/shutdown

[Reindl Harald]

Am 17.01.19 um 06:04 schrieb Jonathon Kowalski:
> On Thu, Jan 17, 2019 at 4:49 AM Christopher Cox  wrote:
>> Adding some extra systemd clarification.  Saying do this After or Before 
>> other
>> service doesn't mean the start/stop completes before moving on.  It may 
>> execute
>> asynchronously before/after, but processes aren't done synchronously.
>>
> 
> This isn't right. systemd's ordering is purely defined for jobs in
> queue. If your start job is ordered after another unit's start job,
> then it really will wait for the other start job to complete before
> dispatching yours. This may produce erroneous results if you don't
> configure the readiness of the service you wait on correctly, but that
> isn't a systemd issue at that point. Similarly, if a stop job for it
> gets enqueued, it will walk the reverse dependency and add one in
> queue for yours too, and yours will become runnable before the other
> one does, and as long as you're stopping, the other unit's stop job
> keeps waiting on you atleast (if nobody else) in queue.

to make it clear:

Type=simple won't work because that implies foreground process without
forking and systemd can't have any clue of the initialization state of
the service

perferred Type=notify which must be supported by the daemon or at least
Type=forking which needs the daemon to do a proper double fork *after*
it is ready to accept clietn tasks

at shutdown it's easier because the daemon only needs to exit with a
zero-state

that all is not really new and was not better with sysvinit, it only was
slow enough, full of sleep/usleep hacks and so most of the time by luck
worked but with no guarantess anyways
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] At wits end... need to execute a script prior to anything getting killed/changed on reboot/shutdown

[Jonathon Kowalski]

On Thu, Jan 17, 2019 at 4:49 AM Christopher Cox  wrote:
>
> On 01/16/2019 10:44 PM, Christopher Cox wrote:
> > On 01/16/2019 12:51 PM, Filipe Brandenburger wrote:
> >> If you want to run it early in the shutdown process, then keep
> >> DefaultDependencies=yes, in which case it will run before the base
> >> dependencies start to get stopped.
> >>
> >> If you need some other resources to be up, for instance network, then add
> >> After=network.target, etc.
> >>
> >> Remember that when shutting down, the dependencies are stopped in the
> >> opposite order as they're started up, so if you need your script to run
> >> *before* something else is stopped, then you need an After= dependency.
> >>
> > But only for services under systemd.  Everything else gets sprayed a TERM
> > signal.  Which is frustrating.  So... having it execute first doesn't
> > guarantee (and we're talking less than a second or so) that it will have 
> > time
> > to do what it needs to do before the kill spray happens, and I need all
> > processes to be around until my script finishes.
> >
> > Old sysvinit didn't have this limitation.
>
> Adding some extra systemd clarification.  Saying do this After or Before other
> service doesn't mean the start/stop completes before moving on.  It may 
> execute
> asynchronously before/after, but processes aren't done synchronously.
>

This isn't right. systemd's ordering is purely defined for jobs in
queue. If your start job is ordered after another unit's start job,
then it really will wait for the other start job to complete before
dispatching yours. This may produce erroneous results if you don't
configure the readiness of the service you wait on correctly, but that
isn't a systemd issue at that point. Similarly, if a stop job for it
gets enqueued, it will walk the reverse dependency and add one in
queue for yours too, and yours will become runnable before the other
one does, and as long as you're stopping, the other unit's stop job
keeps waiting on you atleast (if nobody else) in queue.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] At wits end... need to execute a script prior to anything getting killed/changed on reboot/shutdown

[Christopher Cox]

On 01/16/2019 10:44 PM, Christopher Cox wrote:

On 01/16/2019 12:51 PM, Filipe Brandenburger wrote:
If you want to run it early in the shutdown process, then keep 
DefaultDependencies=yes, in which case it will run before the base 
dependencies start to get stopped.


If you need some other resources to be up, for instance network, then add 
After=network.target, etc.


Remember that when shutting down, the dependencies are stopped in the 
opposite order as they're started up, so if you need your script to run 
*before* something else is stopped, then you need an After= dependency.


But only for services under systemd.  Everything else gets sprayed a TERM 
signal.  Which is frustrating.  So... having it execute first doesn't 
guarantee (and we're talking less than a second or so) that it will have time 
to do what it needs to do before the kill spray happens, and I need all 
processes to be around until my script finishes.


Old sysvinit didn't have this limitation.


Adding some extra systemd clarification.  Saying do this After or Before other 
service doesn't mean the start/stop completes before moving on.  It may execute 
asynchronously before/after, but processes aren't done synchronously.




You shouldn't add any ordering regarding reboot.target and shutdown.target. 
Just enable your service (so that it looks up during normal system usage), 
when the system goes down it will be stopped, and then depending on its 
After= dependencies it will block those other services from being stopped 
until you're done.


In recent systemd versions (I think starting from v238?) you can omit the 
ExecStart=/bin/true line, an unit without that line starts to be valid in one 
of those versions... Though keeping it around is fine and will work with 
older versions too.
Has anyone tried to do something (I'm on CentOS latest) with maybe an extra 
target (post default.target)... possible.  I need something that "works".


I hope this helps!

Cheers,
Filipe


On Wed, Jan 16, 2019 at 10:47 AM Christopher Cox > wrote:


I need to be able to execute a script before anything gets shutdown.  That
is,
when somebody does a "reboot", "shutdown" or "poweroff", I need this
script to
run first, and for it to finish before everything gets whacked.

I know the following isn't "right"... I've tried so many different things.
Google hasn't helped only giving me many "right" solutions that didn't
work. In
this current edition, basically I get a partial capture of processes that 
are

running (that is some were killed directly or indirectly).. I need them
all.  My
script needs to see the state of operation before 
reboot/shutdown/poweroff do

anything else.  My "save" saves some information about running processes
(some
not necessarily under systemd control).

[Unit]
Description=my-service save status
DefaultDependencies=no
Before=reboot.target shutdown.target
Conflicts=reboot.target shutdown.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecStop=/usr/local/bin/my-service.sh save
StandardOutput=journal

[Install]
WantedBy=multi-user.target

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org

https://lists.freedesktop.org/mailman/listinfo/systemd-devel





___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] At wits end... need to execute a script prior to anything getting killed/changed on reboot/shutdown

[Christopher Cox]

On 01/16/2019 12:51 PM, Filipe Brandenburger wrote:
If you want to run it early in the shutdown process, then keep 
DefaultDependencies=yes, in which case it will run before the base 
dependencies start to get stopped.


If you need some other resources to be up, for instance network, then add 
After=network.target, etc.


Remember that when shutting down, the dependencies are stopped in the opposite 
order as they're started up, so if you need your script to run *before* 
something else is stopped, then you need an After= dependency.


But only for services under systemd.  Everything else gets sprayed a TERM 
signal.  Which is frustrating.  So... having it execute first doesn't guarantee 
(and we're talking less than a second or so) that it will have time to do what 
it needs to do before the kill spray happens, and I need all processes to be 
around until my script finishes.


Old sysvinit didn't have this limitation.

You shouldn't add any ordering regarding reboot.target and shutdown.target. 
Just enable your service (so that it looks up during normal system usage), 
when the system goes down it will be stopped, and then depending on its After= 
dependencies it will block those other services from being stopped until 
you're done.


In recent systemd versions (I think starting from v238?) you can omit the 
ExecStart=/bin/true line, an unit without that line starts to be valid in one 
of those versions... Though keeping it around is fine and will work with older 
versions too.
Has anyone tried to do something (I'm on CentOS latest) with maybe an extra 
target (post default.target)... possible.  I need something that "works".


I hope this helps!

Cheers,
Filipe


On Wed, Jan 16, 2019 at 10:47 AM Christopher Cox > wrote:


I need to be able to execute a script before anything gets shutdown.  That
is,
when somebody does a "reboot", "shutdown" or "poweroff", I need this
script to
run first, and for it to finish before everything gets whacked.

I know the following isn't "right"... I've tried so many different things.
Google hasn't helped only giving me many "right" solutions that didn't
work. In
this current edition, basically I get a partial capture of processes that 
are
running (that is some were killed directly or indirectly).. I need them
all.  My
script needs to see the state of operation before reboot/shutdown/poweroff 
do
anything else.  My "save" saves some information about running processes
(some
not necessarily under systemd control).

[Unit]
Description=my-service save status
DefaultDependencies=no
Before=reboot.target shutdown.target
Conflicts=reboot.target shutdown.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecStop=/usr/local/bin/my-service.sh save
StandardOutput=journal

[Install]
WantedBy=multi-user.target

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org

https://lists.freedesktop.org/mailman/listinfo/systemd-devel



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Bugfix release(s)

[Amish]

On 16/01/19 11:52 pm, Lennart Poettering wrote:

On Mi, 16.01.19 09:46, Colin Guthrie (gm...@colin.guthr.ie) wrote:


Jérémy ROSEN wrote on 16/01/2019 08:24:

yes... adding a "this is the start of the freeze" tag sounds like a low
hanging fruit... it's almost no work for the core team to do, and it
would be a clear signal that the freeze period is starting...

And automated mails to the list when this happens would be nice too, as
some folk will likely still follow the list more than they login to
github (and for those that do login to github they may have many other
projects so it could get lost in the noise)

Hmm, I figure we'd need to set up a webhook for that... but someone
would have to host this? Anyone wants to set this up? If so, that'd be
excellent of course!

Thanks,

Lennart


May be a user (say systemd-watch) with 
systemd-devel@lists.freedesktop.org as email id can be created on Github.


And that user activates "Watch" feature with "Releases only" mode set.

So Github will automatically send email to mailing list. (needs some 
testing by mailing list administrator)


Regards,

Amish.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Bugfix release(s)

[Ryan Gonzalez]

All that sounds great! I'll get to work ASAP.

On Wed, Jan 16, 2019 at 12:46 PM Lennart Poettering 
wrote:

> On Mi, 16.01.19 12:30, Ryan Gonzalez (rym...@gmail.com) wrote:
>
> > I'd love to do this!
>
> That'd be excellent! Thank you!
>
> > To be clear, it'd basically automatically send out a message on new
> > "freeze" tags and release?
>
> I think it could be as simple as just sending out a mail to the
> mailing list on every single tag. After all we only use tags for
> releases so far, and we now want to use it for pre-releases too, but
> in both cases such a msg makes sense.
>
> To add a cherry on top a brief explanatory text along with it would be
> great. For example, if a tag matching the regexp ^v[0-9]+$ is seen the
> message should contain a blurb like this:
>
>  A new, official systemd release has just  been  tagged
> . Please download the tarball here:
>
> https://github.com/systemd/systemd/archive/$TAG.tar.gz
>
> And in case the tag matches ^v[0-9]+-pre-.*$ may be this:
>
> A new systemd ☠️ pre-release☠️  has just been tagged. Please
> download the tarball here:
>
> https://github.com/systemd/systemd/archive/$TAG.tar.gz
>
> NOTE: This is ☠️ pre-release☠️ software. Do not run this on
> production systems, but please test this and report any issues you
> find to GitHub:
>
> https://github.com/systemd/systemd/issues/new?template=Bug_report.md
>
> Or something like that. But adding such a blurb is of course already
> the second step, not needed really.
>
> And if you feel really keen to make this nice, you could even pull the
> NEWS file from the tagged version, truncate it before the second line
> matching ^CHANGES WITH.*$ and include the result in the mail. if you
> do that, then we can stop writing [RELEASE] mails, as this would
> happen fully automatically, which would be excellent, of course!
>
> But of course, that's all entirely up to you how much love you want to
> give this ;-)
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>


-- 
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-nspawn: access to disk devices does not work on centos 7/systemd 219

[Mailing List SVR]

Il 16/01/19 19:24, Lennart Poettering ha scritto:

On Mi, 16.01.19 09:20, Mailing List SVR (li...@svrinformatica.it) wrote:


Well, this command will make the sd devices readable inside the container on
centos 7 too

echo 'b 8:* rw' > 
/sys/fs/cgroup/devices/machine.slice/machine-bionic\\x2druntime.scope/devices.allow

now I'll will search how to pass to systemd-nspawn using a command line
argument

Use --property=DeviceAllow=…


thanks but this does not seems available in systemd 219, the version 
shipped with centos 7, it fails with unrecognized option error.


Newer systemd versions work out of the box probably because they have 
DevicePolicy=auto as default,


so basically I ended up writing a systemd-nspawn wrapper that, launched 
from a systemd service, wait for 
/sys/fs/cgroup/devices/machine.slice/machine-.scope to appear and 
then it sets the required permissions in devices.allow.


If I use the reboot command inside the container then the cgroup dir is 
recreated and the permissions are lost since my wrapper is not called


luckily I can control the container and so I changed the reboot command 
so it shutdowns the container instead and I set Restart=always in the 
systemd service so the container is restarted automatically after the 
shutdown,


so the only way to shutdown the container is using systemctl stop service> but this is better than nothing,


Nicola



Lennart

--
Lennart Poettering, Red Hat



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] At wits end... need to execute a script prior to anything getting killed/changed on reboot/shutdown

[Filipe Brandenburger]

If you want to run it early in the shutdown process, then keep
DefaultDependencies=yes, in which case it will run before the base
dependencies start to get stopped.

If you need some other resources to be up, for instance network, then add
After=network.target, etc.

Remember that when shutting down, the dependencies are stopped in the
opposite order as they're started up, so if you need your script to run
*before* something else is stopped, then you need an After= dependency.

You shouldn't add any ordering regarding reboot.target and shutdown.target.
Just enable your service (so that it looks up during normal system usage),
when the system goes down it will be stopped, and then depending on its
After= dependencies it will block those other services from being stopped
until you're done.

In recent systemd versions (I think starting from v238?) you can omit the
ExecStart=/bin/true line, an unit without that line starts to be valid in
one of those versions... Though keeping it around is fine and will work
with older versions too.

I hope this helps!

Cheers,
Filipe


On Wed, Jan 16, 2019 at 10:47 AM Christopher Cox 
wrote:

> I need to be able to execute a script before anything gets shutdown.  That
> is,
> when somebody does a "reboot", "shutdown" or "poweroff", I need this
> script to
> run first, and for it to finish before everything gets whacked.
>
> I know the following isn't "right"... I've tried so many different
> things.
> Google hasn't helped only giving me many "right" solutions that didn't
> work. In
> this current edition, basically I get a partial capture of processes that
> are
> running (that is some were killed directly or indirectly).. I need them
> all.  My
> script needs to see the state of operation before reboot/shutdown/poweroff
> do
> anything else.  My "save" saves some information about running processes
> (some
> not necessarily under systemd control).
>
> [Unit]
> Description=my-service save status
> DefaultDependencies=no
> Before=reboot.target shutdown.target
> Conflicts=reboot.target shutdown.target
>
> [Service]
> Type=oneshot
> RemainAfterExit=yes
> ExecStart=/bin/true
> ExecStop=/usr/local/bin/my-service.sh save
> StandardOutput=journal
>
> [Install]
> WantedBy=multi-user.target
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] At wits end... need to execute a script prior to anything getting killed/changed on reboot/shutdown

[Christopher Cox]

I need to be able to execute a script before anything gets shutdown.  That is, 
when somebody does a "reboot", "shutdown" or "poweroff", I need this script to 
run first, and for it to finish before everything gets whacked.


I know the following isn't "right"... I've tried so many different things.  
Google hasn't helped only giving me many "right" solutions that didn't work. In 
this current edition, basically I get a partial capture of processes that are 
running (that is some were killed directly or indirectly).. I need them all.  My 
script needs to see the state of operation before reboot/shutdown/poweroff do 
anything else.  My "save" saves some information about running processes (some 
not necessarily under systemd control).


[Unit]
Description=my-service save status
DefaultDependencies=no
Before=reboot.target shutdown.target
Conflicts=reboot.target shutdown.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecStop=/usr/local/bin/my-service.sh save
StandardOutput=journal

[Install]
WantedBy=multi-user.target

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Bugfix release(s)

[Lennart Poettering]

On Mi, 16.01.19 12:30, Ryan Gonzalez (rym...@gmail.com) wrote:

> I'd love to do this!

That'd be excellent! Thank you!

> To be clear, it'd basically automatically send out a message on new
> "freeze" tags and release?

I think it could be as simple as just sending out a mail to the
mailing list on every single tag. After all we only use tags for
releases so far, and we now want to use it for pre-releases too, but
in both cases such a msg makes sense.

To add a cherry on top a brief explanatory text along with it would be
great. For example, if a tag matching the regexp ^v[0-9]+$ is seen the
message should contain a blurb like this:

 A new, official systemd release has just  been  tagged
. Please download the tarball here:

https://github.com/systemd/systemd/archive/$TAG.tar.gz

And in case the tag matches ^v[0-9]+-pre-.*$ may be this:

A new systemd ☠️ pre-release☠️  has just been tagged. Please
download the tarball here:

https://github.com/systemd/systemd/archive/$TAG.tar.gz

NOTE: This is ☠️ pre-release☠️ software. Do not run this on
production systems, but please test this and report any issues you
find to GitHub:

https://github.com/systemd/systemd/issues/new?template=Bug_report.md

Or something like that. But adding such a blurb is of course already
the second step, not needed really.

And if you feel really keen to make this nice, you could even pull the
NEWS file from the tagged version, truncate it before the second line
matching ^CHANGES WITH.*$ and include the result in the mail. if you
do that, then we can stop writing [RELEASE] mails, as this would
happen fully automatically, which would be excellent, of course!

But of course, that's all entirely up to you how much love you want to
give this ;-)

Lennart

--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Bugfix release(s)

[Ryan Gonzalez]

I'd love to do this!

To be clear, it'd basically automatically send out a message on new
"freeze" tags and release?

--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/

On Wed, Jan 16, 2019, 12:22 PM Lennart Poettering  On Mi, 16.01.19 09:46, Colin Guthrie (gm...@colin.guthr.ie) wrote:
>
> > Jérémy ROSEN wrote on 16/01/2019 08:24:
> > > yes... adding a "this is the start of the freeze" tag sounds like a low
> > > hanging fruit... it's almost no work for the core team to do, and it
> > > would be a clear signal that the freeze period is starting...
> > And automated mails to the list when this happens would be nice too, as
> > some folk will likely still follow the list more than they login to
> > github (and for those that do login to github they may have many other
> > projects so it could get lost in the noise)
>
> Hmm, I figure we'd need to set up a webhook for that... but someone
> would have to host this? Anyone wants to set this up? If so, that'd be
> excellent of course!
>
> Thanks,
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] RFC: idea for a pstore systemd service

[Lennart Poettering]

On Di, 15.01.19 23:39, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:

>
> [Service]
> ExecStart=/bin/bash -c '/usr/bin/mv -t /var/lib/pstore /sys/fs/pstore/*'
> Restart=on-success

While this would certainly work, I think I'd prefer a version in C
and not depend on an installed shell for this. I mean, so far systemd
has been an excercise in keeping shell out of the default codepaths in
the boot process...

Moreover, we want a recognizable journal message (i.e. one with
MESSAGE_ID) to be generated when we move a file out of pstore, much
like we have it for coredumps and so on, and as soon as you do more
than just the basic "mv" it gets nastier and nastier to do this from
shell, while it is easy from C.

Lennart

--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-nspawn: access to disk devices does not work on centos 7/systemd 219

[Lennart Poettering]

On Mi, 16.01.19 09:20, Mailing List SVR (li...@svrinformatica.it) wrote:

> Well, this command will make the sd devices readable inside the container on
> centos 7 too
>
> echo 'b 8:* rw' > 
> /sys/fs/cgroup/devices/machine.slice/machine-bionic\\x2druntime.scope/devices.allow
>
> now I'll will search how to pass to systemd-nspawn using a command line
> argument

Use --property=DeviceAllow=…

Lennart

--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Bugfix release(s)

[Lennart Poettering]

On Mi, 16.01.19 09:46, Colin Guthrie (gm...@colin.guthr.ie) wrote:

> Jérémy ROSEN wrote on 16/01/2019 08:24:
> > yes... adding a "this is the start of the freeze" tag sounds like a low
> > hanging fruit... it's almost no work for the core team to do, and it
> > would be a clear signal that the freeze period is starting...
> And automated mails to the list when this happens would be nice too, as
> some folk will likely still follow the list more than they login to
> github (and for those that do login to github they may have many other
> projects so it could get lost in the noise)

Hmm, I figure we'd need to set up a webhook for that... but someone
would have to host this? Anyone wants to set this up? If so, that'd be
excellent of course!

Thanks,

Lennart

--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Bugfix release(s)

[Lennart Poettering]

On Mi, 16.01.19 01:06, Christian Hesse (l...@eworm.de) wrote:

> Lennart Poettering  on Tue, 2019/01/15 20:00:
> > Note that we don't branch releases right now. Instead when we are
> > getting closer to a release we simply don't merge PRs we don't
> > consider appropriate for the release anymore until after the
> > release. Or in other words: the master branch simply "stops" for a
> > while getting new stuff, and only gets bugfixes until we release the
> > version, which reopens the floodgates
>
> Most people do not notice when this happens. Having milestones on github is
> nice, but most of us miss that. Just make it obvious: add a tag when
> you start preparation for a release - no matter if you call it 'v241-freeze',
> 'v241-rc' or whatever. I guess 'communication' on the lowest level can help a
> lot here.

(Hmm, are you sure a git tag is more "visible" than a github
milestone?  I am not so sure)

Either way, Zbigniew and I agreed to tag preliminary versions now,
let's see how this goes.

Hmm, anyone wants to set up a bot that automatically sends a mail to
this mailing list whenever a new tag is added to the git repo?

Lennart

--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Bugfix release(s)

[František Šumšal]

On 1/14/19 4:36 PM, Lennart Poettering wrote:
> On Mo, 14.01.19 10:59, Jan Synacek (jsyna...@redhat.com) wrote:
>
> I'd love to see some more CI hookup with Arch and Debian for example
> (right now there is zero) or even just a git preview package set or so 
> that interested people can test. Without either it's very likely that
> things break on those distros, because there's no way we'll catch
> things beforehand.
> 

After a really quick "research" I noticed that many distributions provide
Vagrant images[0][1]. In theory, it should be possible to simply use these 
images
along with a "proper" virtualization (vagrant-libvirt[2]) to do some more 
advanced
sanity/regression testing.

As for the infrastructure - the CentOS CI machine pool provides baremetal 
machines[3],
which would be, again in theory, great for such effort. Having a dedicated 
machine pool
of distro-specific nodes would be much better, but that's a long shot even if 
would be 
possible for some distro to have such infrastructure.


[0] https://www.archlinux.org/download/ (section Vagrant images)
[1] https://app.vagrantup.com/debian
[2] https://github.com/vagrant-libvirt/vagrant-libvirt
[3] https://wiki.centos.org/QaWiki/PubHardware


-- 
GPG key ID: 0xFB738CE27B634E4B



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Bugfix release(s)

[Colin Guthrie]

Jérémy ROSEN wrote on 16/01/2019 08:24:
> yes... adding a "this is the start of the freeze" tag sounds like a low
> hanging fruit... it's almost no work for the core team to do, and it
> would be a clear signal that the freeze period is starting...
And automated mails to the list when this happens would be nice too, as
some folk will likely still follow the list more than they login to
github (and for those that do login to github they may have many other
projects so it could get lost in the noise)

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Bugfix release(s)

[Jérémy ROSEN]

yes... adding a "this is the start of the freeze" tag sounds like a low
hanging fruit... it's almost no work for the core team to do, and it would
be a clear signal that the freeze period is starting...



Le mer. 16 janv. 2019 à 01:14, Christian Hesse  a écrit :

> Lennart Poettering  on Tue, 2019/01/15 20:00:
> > Note that we don't branch releases right now. Instead when we are
> > getting closer to a release we simply don't merge PRs we don't
> > consider appropriate for the release anymore until after the
> > release. Or in other words: the master branch simply "stops" for a
> > while getting new stuff, and only gets bugfixes until we release the
> > version, which reopens the floodgates
>
> Most people do not notice when this happens. Having milestones on github is
> nice, but most of us miss that. Just make it obvious: add a tag when
> you start preparation for a release - no matter if you call it
> 'v241-freeze',
> 'v241-rc' or whatever. I guess 'communication' on the lowest level can
> help a
> lot here.
>
> (BTW, there's another place I would like to see more tags... Would be nice
> to
> have signed tags whenever a bunch of commits lands in a stable branch.)
> --
> main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
> "CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
> putchar(b-1/(/*Chriscc -ox -xc - && ./x
> */b/42*2-3)*42);}
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>


-- 
[image: SMILE]  

20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique

[image: email] jeremy.ro...@smile.fr
[image: phone]  +33 6 88 25 87 42
[image: url] http://www.smile.eu

[image: Twitter]  [image: Facebook]
 [image: LinkedIn]
 [image: Github]


[image: Découvrez l’univers Smile, rendez-vous sur smile.eu]

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-nspawn: access to disk devices does not work on centos 7/systemd 219

[Mailing List SVR]

Well, this command will make the sd devices readable inside the 
container on centos 7 too


echo 'b 8:* rw' > 
/sys/fs/cgroup/devices/machine.slice/machine-bionic\\x2druntime.scope/devices.allow


now I'll will search how to pass to systemd-nspawn using a command line 
argument



Il 16/01/19 01:42, Mailing List SVR ha scritto:

Hi,

I'm quite new to systemd-nspawn,

I configured a systemd container based on ubuntu bionic using 
debootstrap.


I can start the container from a bionic host (systemd 237) with a 
command like this one


systemd-nspawn -b -D bionic-devel 
--capability=CAP_SYS_TIME,CAP_SYS_RAWIO --bind=/dev/sda


and inside the container I have read/write permissions on /dev/sda, 
for example cat /dev/sda works fine.


If I start the same container from Arch Linux (systemd 240) it works 
the same way: /dev/sda is accessibile,


but if I start this container from centos 7 (systemd 219) I cannot 
read /dev/sda


cat /dev/sda
cat: /dev/sda: Operation not permitted

I tryed to disable selinux with no luck and I cannot see nothing 
relevant in the logs,


can the problem be related to the old systemd version? Any idea on how 
to debug this issue?


thanks!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel