[opensuse-packaging] Creating of systemd service files instead of init scripts for new packages
29 Mar
2013
29 Mar
'13
6:43 p.m.
Since we moved to systemd completely, I suggest that newly added files
will contain service files - and not init scripts anymore.
So, please only add service files to new packages and if you change your
init file, consider using a service file and dropping the init file,
Andreas
--
Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
30 Mar
30 Mar
3:29 a.m.
El 29/03/13 14:43, Andreas Jaeger escribió:
Since we moved to systemd completely, I suggest that
newly added files
will contain service files - and not init scripts anymore.
So, please only add service files to new packages and if you change your
init file, consider using a service file and dropping the init file,
Does anyone have access to a full unpacked tree of factory and can post
what packages contain init scripts but not service files so I can take
look at them ? there is no rpmlint check for that :-|
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
2 Apr
2 Apr
10:06 a.m.
On Fri, Mar 29, 2013 at 11:29:22PM -0300, Cristian Rodríguez wrote:
Does anyone have access to a full unpacked tree of factory and can
post what packages contain init scripts but not service files so I
can take look at them ? there is no rpmlint check for that :-|
And not long ago I was being assured there won't be...
Michal Kubeček
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
10:26 a.m.
On 02.04.2013 10:06, Michal Kubecek wrote:
On Fri, Mar 29, 2013 at 11:29:22PM -0300, Cristian
Rodríguez wrote:
We agreed not to enforce that. So your fine to have a package with init
scripts. But it's perfectly fine also to have a rpmlint warning that
a package has *only* init script and Cristian adding systemd services
for them - if the maintainer of the package disagrees to add it, then
we can talk again.
Greetings, Stephan
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Does anyone have access to a full unpacked tree of factory and can
post what packages contain init scripts but not service files so I
can take look at them ? there is no rpmlint check for that :-|
And not long ago I was being assured there won't be...
3 Apr
3 Apr
9:20 a.m.
Stephan Kulow wrote:
On 02.04.2013 10:06, Michal Kubecek wrote:
Well, the truth is that it doesn't make much sense anymore to keep
the sysv scripts if there is a service file. It only adds potential
code duplication and confusion. So I'd vote for having either
.service files or init scripts in a package but not both.
However, adding service files that break previous features or just
add the init script shell code 1:1 as ExecStartPre should be avoided
too.
cu
Ludwig
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG
Nürnberg)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On Fri, Mar 29, 2013 at 11:29:22PM -0300,
Cristian Rodríguez wrote:
We agreed not to enforce that. So your fine to have a package with init
scripts. But it's perfectly fine also to have a rpmlint warning that
a package has *only* init script and Cristian adding systemd services
for them - if the maintainer of the package disagrees to add it, then
we can talk again.
Does anyone have access to a full unpacked tree of factory and can
post what packages contain init scripts but not service files so I
can take look at them ? there is no rpmlint check for that :-|
And not long ago I was being assured there won't be...
4:42 p.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
On Wed, 3 Apr 2013 09:20, Ludwig Nussel <ludwig.nussel@...> wrote:
Stephan Kulow wrote:
As long as there is a SLE(S|D) without systemd support you are shooting
your own legs if you just "drop" all replaced sysVinit scripts.
For systems with full systemd support (12.1 and later), install
the scrips as %doc in the docdir for reference (and help).
Before a drop could be considered (13.1 and following), there is more
maturing needed (intoduce a .service, and get it working without
troubles for a full release, e.g. a 'new' .service in 12.3 gets a
moved /etc/init.d/ script as %doc in 13.1 and so on.
Similar in SLE, afer one run in a SLE service pack it could be considered
to move the scripts, but what of those that modified the scripts to suit
their needs?
I agree, that keeping the old sysVinit scripts beyond the end-of-life of
the last sysVinit supporting SLE version (12?, 11 for sure) does not make
sense, but before?
Are you trying to get the SLE support crew mad at you?
Just food for thoughts,
- Yamaban.
On 02.04.2013 10:06, Michal Kubecek wrote:
Well, the truth is that it doesn't make much sense anymore to keep
the sysv scripts if there is a service file. It only adds potential
code duplication and confusion. So I'd vote for having either
.service files or init scripts in a package but not both.
However, adding service files that break previous features or just
add the init script shell code 1:1 as ExecStartPre should be avoided
too. On Fri, Mar 29, 2013 at 11:29:22PM -0300,
Cristian Rodríguez wrote:
We agreed not to enforce that. So your fine to have a package with init
scripts. But it's perfectly fine also to have a rpmlint warning that
a package has *only* init script and Cristian adding systemd services
for them - if the maintainer of the package disagrees to add it, then
we can talk again.
Does anyone have access to a full unpacked tree of factory and can
post what packages contain init scripts but not service files so I
can take look at them ? there is no rpmlint check for that :-|
And not long ago I was being assured there won't be...
4:47 p.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
On 04/03/2013 04:42 PM, Yamaban wrote:
On Wed, 3 Apr 2013 09:20, Ludwig Nussel
<ludwig.nussel@...> wrote:
Only as long as packages are build for SLE 11 - and many are not.
Stephan Kulow wrote:
As long as there is a SLE(S|D) without systemd support you are shooting
your own legs if you just "drop" all replaced sysVinit scripts. On 02.04.2013 10:06, Michal Kubecek wrote:
Well, the truth is that it doesn't make much sense anymore to keep
the sysv scripts if there is a service file. It only adds potential
code duplication and confusion. So I'd vote for having either
.service files or init scripts in a package but not both.
However, adding service files that break previous features or just
add the init script shell code 1:1 as ExecStartPre should be avoided
too. On Fri, Mar 29, 2013 at 11:29:22PM -0300,
Cristian Rodríguez wrote:
>
> Does anyone have access to a full unpacked tree of factory and can
> post what packages contain init scripts but not service files so I
> can take look at them ? there is no rpmlint check for that :-|
And not long ago I was being assured there won't be...
We agreed not to enforce that. So your fine to have a package with init
scripts. But it's perfectly fine also to have a rpmlint warning that
a package has *only* init script and Cristian adding systemd services
for them - if the maintainer of the package disagrees to add it, then
we can talk again. For systems with full systemd support (12.1 and
later), install
the scrips as %doc in the docdir for reference (and help).
Before a drop could be considered (13.1 and following), there is more
maturing needed (intoduce a .service, and get it working without
troubles for a full release, e.g. a 'new' .service in 12.3 gets a
moved /etc/init.d/ script as %doc in 13.1 and so on.
No, this is really overkill in this case. Service files are not that
complicated and can be easily tested.
Similar in SLE, afer one run in a SLE service pack it
could be considered
to move the scripts, but what of those that modified the scripts to suit
their needs?
That's why you're not doing this during the lifetime of SLE 11 but
introduce it directly with e.g. SLE 12.
I agree, that keeping the old sysVinit scripts beyond
the end-of-life of
the last sysVinit supporting SLE version (12?, 11 for sure) does not make
sense, but before?
Are you trying to get the SLE support crew mad at you?
You don't need to worry about that,
Andreas
--
Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
7:21 p.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
Hello,
Am Mittwoch, 3. April 2013 schrieb Andreas Jaeger:
Does this mean you would accept the following patch in a SR to Factory?
(with $something replaced by aaa_base, vim, emacs, whatever)
--- $something.spec
+++ $something.spec
@@ some,line @@
%build
+%if 0%{?sles_version} > 10
+ echo "I don't care about SLE"
+ exit 42
+%endif
I'm looking forward for your answer ;-)
*SCNR*
Seriously:
I know openSUSE packagers don't need to worry about SLE. This is
especially true for packagers not paid by SUSE (you can't force them in
any way, maybe except "I won't pay you a drink at the conference" ;-)
OTOH in the interest of working together in a friendly way, it makes
sense to keep the packages SLE-compatible whenever possible ;-)
Regards,
Christian Boltz
--
GETOPT(3)
BUGS
This manpage is confusing.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On 04/03/2013 04:42 PM, Yamaban wrote:
Are you trying
to get the SLE support crew mad at you?
You don't need to worry about that,
8:20 p.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
On 04/03/2013 07:21 PM, Christian Boltz wrote:
Hello,
Am Mittwoch, 3. April 2013 schrieb Andreas Jaeger:
Does this mean you would accept the following patch in a SR to Factory?
(with $something replaced by aaa_base, vim, emacs, whatever)
--- $something.spec
+++ $something.spec
@@ some,line @@
%build
+%if 0%{?sles_version} > 10
+ echo "I don't care about SLE"
+ exit 42
+%endif
No, not at all.
I do care a lot about SLE - it's one of my responsibilities - but in
this specific context and how the question was asked, there's no need
for Yamaban to care about SLE.
On 04/03/2013 04:42 PM, Yamaban wrote:
Are you
trying to get the SLE support crew mad at you?
You don't need to worry about that,
I'm looking forward for your answer ;-)
christian, are you satisfied ? ;)
*SCNR*
Seriously:
I know openSUSE packagers don't need to worry about SLE. This is
especially true for packagers not paid by SUSE (you can't force them in
any way, maybe except "I won't pay you a drink at the conference" ;-)
OTOH in the interest of working together in a friendly way, it makes
sense to keep the packages SLE-compatible whenever possible ;-)
Sure. And supporting SLE 11 is fine - if that is wanted for a package
and a valid reason to not remove an init file.
But if a package is not build for SLE 11, then why should it have an
init file?
Andreas
--
Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
4 Apr
4 Apr
8:23 a.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
On Wednesday 03 of April 2013 20:20EN, Andreas Jaeger wrote:
But if a package is not build for SLE 11, then why should it have an
init file?
Because OpenSuSE is supposed to be a codebase for SLE12. And I don't see
much sense in taking effort in carefully removing anything reminding
System V init now and then making it work with System V init again
several months later (yes, perhaps I'm naïve, but I still believe there
will be System V init in SLE12).
Moreover, people like Coolo still claim they will be fine with someone
fixing System V init support in OpenSuSE with an add-on repository. But
seeing that things needed for proper System V init support are
countinuously taken away from distribution even when they do not harm
systemd in any way makes it kind of hard to believe that they are
sincere. As I plan to devote the Hackweek to such project, I would
really appreciate if people didn't deliberately make the work harder at
least in the cases when it actually doesn't help anyone.
Few months ago, I expressed my fear that package maintainers are going
to be pushed into removing init scripts from their packages. I have been
assured this is not going to happen. Few months later, we are seriously
discussing adding a warning to OBS if a package contains an init script
and not letting anyone to add a new package with an init script. And
everyone - or at least everyone who matters - seems to be OK with it.
Well, it's hard not to see this as pushing.
Michal Kubeček
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
8:33 a.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
On 04/04/2013 03:23 AM, Michal Kubeček wrote:
(yes, perhaps I'm naïve, but I still believe there
will be System V init in SLE12).
Yes, you are being naive, currently, there is no way to make any future
product to work without systemd without a massive effort that nobody
here will do.
As I plan to devote the Hackweek to such project, I would
really appreciate if people didn't deliberately
make the work harder at
least in the cases when it actually doesn't help anyone.
You will be wasting your time.
It is not my place to tell you what to do, however I would suggest you
pick something else.
Well, it's hard not to see this as pushing.
More than pushing, it is just an statement of fact, we are past the
point of return by now.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
8:53 a.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
On Thursday 04 of April 2013 03:33EN, Cristian Rodríguez wrote:
Even if I did, it is my right to do so. And even if the only result is
that it will make OpenSuSE usable for me for eight more months, it will
be worth it.
Well, forgive me not taking words of hard core systemd fan on this
matter as truth revealed. :-)
But the point is different: I just wanted to remind a promise given less
than half year ago which is now going to be broken.
Michal Kubeček
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On 04/04/2013 03:23 AM, Michal Kubeček wrote:
Well, you are definitely not the one to decide that so your opinion on
this is not a bit more valuable than mine. Enterprise world is much less
keen to fall for bells and whistles and much less accepting to the
general "we break anything anytime and it's world's job to adapt"
attitude of systemd people. So I guess, there is a chance.
(yes, perhaps I'm naïve, but I still believe
there
will be System V init in SLE12).
Yes, you are being naive, currently, there is no way to make any
future product to work without systemd without a massive effort that
nobody here will do. As I plan to
devote the Hackweek to such project, I would
really appreciate if people didn't deliberately make the work harder
at least in the cases when it actually doesn't help anyone.
You will be wasting your time. Well, it's
hard not to see this as pushing.
More than pushing, it is just an statement of fact, we are past the
point of return by now.
9:06 a.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
On 04/04/2013 03:53 AM, Michal Kubeček wrote:
Well, you are definitely not the one to decide that so
your opinion on
this is not a bit more valuable than mine. Enterprise world is much less
keen to fall for bells and whistles and much less accepting to the
general "we break anything anytime and it's world's job to adapt"
attitude of systemd people. So I guess, there is a chance.
Just in case, the competitors alreadsy have RHEL 7 betas and use systemd.
Even if I did, it is my right to do so. And even if
the only result is
that it will make OpenSuSE usable for me for eight more months, it will
be worth it.
It is not just a matter of restoring init scripts, currently you will
need to "fork" gnome, kde, udev, most of the base system..
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
9:20 a.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
On Thursday 04 of April 2013 04:06EN, Cristian Rodríguez wrote:
Just in case, the competitors alreadsy have RHEL 7
betas and use
systemd.
If RHEL 7 is going to be systemd-only, one more reason to provide both
as a competetive advantage...
It is not just a matter of restoring init scripts,
currently you will
need to "fork" gnome, kde, udev, most of the base system..
Yes, I noticed a lot of effort has been taken to make life of those who
want to use System V init harder. And unfortunately more than seldom
without actually helping those using systemd... which makes me sad.
Michal Kubeček
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
9:25 a.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
On 04/04/2013 04:20 AM, Michal Kubeček wrote:
Yes, I noticed a lot of effort has been taken to make
life of those who
want to use System V init harder.
No, lot of effort has been done to integrate systemd better.
And unfortunately more than seldom
without actually helping those using systemd... which makes me sad.
If there are bugs, we want to know so we can fix them.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
9:35 a.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
On Thursday 04 of April 2013 04:25EN, Cristian Rodríguez wrote:
I'm not talking about bugs. I'm talking about changes which will need to
be reverted to make System V init work again and which are neither
necessary nor helpful for systemd-only systems.
Michal Kubeček
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On 04/04/2013 04:20 AM, Michal Kubeček wrote:
Not all of it. A lot of changes are only "this is not needed anymore as
we have only systemd" - and such changes are being done even if keeping
those things wouldn't harm systemd-only systems in any way.
Yes, I noticed a lot of effort has been taken to
make life of those
who want to use System V init harder.
No, lot of effort has been done to integrate systemd better. And
unfortunately more than seldom
without actually helping those using systemd... which makes me sad.
If there are bugs, we want to know so we can fix them. 
9:48 a.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
On Thu, Apr 4, 2013 at 11:35 AM, Michal Kubeček <mkubecek(a)suse.cz> wrote:
On Thursday 04 of April 2013 04:25EN, Cristian
Rodríguez wrote:
I'm not talking about bugs. I'm talking about changes which will need to
be reverted to make System V init work again and which are neither
necessary nor helpful for systemd-only systems.
Having list of such changes somewhere would help as well.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On 04/04/2013 04:20 AM, Michal Kubeček wrote:
Not all of it. A lot of changes are only "this is not needed anymore as
we have only systemd" - and such changes are being done even if keeping
those things wouldn't harm systemd-only systems in any way.
Yes, I noticed a lot of effort has been taken to
make life of those
who want to use System V init harder.
No, lot of effort has been done to integrate systemd better. And
unfortunately more than seldom
without actually helping those using systemd... which makes me sad.
If there are bugs, we want to know so we can fix them. 
14 Apr
14 Apr
12:19 a.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
Am 04.04.2013 09:25, schrieb Cristian Rodríguez:
On 04/04/2013 04:20 AM, Michal Kubeček wrote:
Nobody fixes systemd bugs is my observation. Only new ones are added all
the time :-)
My machine has been unable to shut down without sysrq-E and sometimes
sysrq-I.
It hangs somewhere, but because everything is totally silent it does not
show any debugging output.
I have given up on reporting systemd bugs because they reappear faster
than you can report them.
Right now I would appreciate a working SysV-Init implementation we had
for 20 years much more than the ever changing and ever broken crap that
systemd is.
And I would bet quite some money that some of the customers I'm working
for will not buy SLES12 if it ships a systemd that does not run their
custom init scripts without tweaking.
--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Yes, I noticed a lot of effort has been taken to
make life of those who
want to use System V init harder.
No, lot of effort has been done to integrate systemd better.
And unfortunately more than seldom
without actually helping those using systemd... which makes me sad.
If there are bugs, we want to know so we can fix them.
12:34 a.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
El 13/04/13 19:19, Stefan Seyfried escribió:
Nobody fixes systemd bugs is my observation. Only new
ones are added all
the time :-)
That's not true.
My machine has been unable to shut down without
sysrq-E and sometimes
sysrq-I.
It hangs somewhere, but because everything is totally silent it does not
show any debugging output.
did you enabled debugging ?
I have given up on reporting systemd bugs because they
reappear faster
than you can report them.
do you have examples ?
Right now I would appreciate a working SysV-Init
implementation we had
for 20 years much more than the ever changing and ever broken crap that
systemd is.
It is not.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
1:34 a.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
Am 14.04.2013 00:34, schrieb Cristian Rodríguez:
My cryptohome does not mount every second boot. This time it was
actually asking me for the password on the text console and echoing the
passphrase to the terminal(!), but then at least it mounted $HOME.
I think I have reported cryptohome mount problems at least three times
in bugzilla, but I'm just tired of it.
Forwarding to syslog-ng does not work. Only "Forwarding to syslog missed
XXX messages" all the time.
Wait, scrap that. Since yesterday's reboot it seems to work, only ~130
missed messages during boot, now it works. (and no, journal is not an
alternative, because the performance is abysmal. "journalctl", then
hitting "end" thrashes my disk for about three minutes before
responding. I can grep through 3 Years worth of /var/log/messages-* in
the same time).
Maybe it works for you, but for me it is an nondeterministic heap of
crap. Latest example: Curiously after timedatectl was mentioned in this
hread, I issued "timedatectl" as a nonprivileged user(!) to see what it
would give me. Now I no longer can start / stop ntp and ntp is broken.
WTF? (Yes, I killed all involved processes I could find in the mean
time). Probably the solution will be a reboot. Systemd really brings us
closer to the other "great" Desktop OS's.
Initially I was thinking that systemd was a good idea, right now I'm
seriously considering switching to a busybox based home-built primitive
init that *just works* in a deterministic way (I have about 20 different
systems sitting in my A/V shelf, all running different busybox-based
init systems just fine and very reliably).
In theory, systemd should be more deterministic, but obviously it is
only tested in very few different scenarios and mine (a pretty normal,
moderately old laptop with bluetooth and wireless networking used and an
encrypted $HOME) is not one of them. Probably it's too exotic.
Encryption is only for terrorists and as such not supported :-)
At least I'll use busybox init as an alternative implementation to get
the system up when systemd fails.
--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
El 13/04/13 19:19, Stefan Seyfried escribió:
That's not feasible as I need to enable debugging at boot and then have
lots debug information wasting cycles just to debug the shutdown 2 weeks
later once a new kernel is out.
Or is there a way to enable debugging just before shutdown? I have not
found one.
Nobody fixes systemd bugs is my observation. Only
new ones are added all
the time :-)
That's not true.
My machine has been unable to shut down without
sysrq-E and sometimes
sysrq-I.
It hangs somewhere, but because everything is totally silent it does not
show any debugging output.
did you enabled debugging ? I have given
up on reporting systemd bugs because they reappear faster
than you can report them.
do you have examples ? Right now I
would appreciate a working SysV-Init implementation we had
for 20 years much more than the ever changing and ever broken crap that
systemd is.
It is not. 
1:54 a.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
On Sat, Apr 13, 2013 at 8:34 PM, Stefan Seyfried
<stefan.seyfried(a)googlemail.com> wrote:
Maybe it works for you, but for me it is an nondeterministic heap of
crap. Latest example: Curiously after timedatectl was mentioned in this
hread, I issued "timedatectl" as a nonprivileged user(!) to see what it
would give me. Now I no longer can start / stop ntp and ntp is broken.
WTF? (Yes, I killed all involved processes I could find in the mean
time). Probably the solution will be a reboot. Systemd really brings us
closer to the other "great" Desktop OS's.
Initially I was thinking that systemd was a good idea, right now I'm
seriously considering switching to a busybox based home-built primitive
init that *just works* in a deterministic way (I have about 20 different
systems sitting in my A/V shelf, all running different busybox-based
init systems just fine and very reliably).
In theory, systemd should be more deterministic, but obviously it is
only tested in very few different scenarios and mine (a pretty normal,
moderately old laptop with bluetooth and wireless networking used and an
encrypted $HOME) is not one of them. Probably it's too exotic.
Encryption is only for terrorists and as such not supported :-)
At least I'll use busybox init as an alternative implementation to get
the system up when systemd fails.
This story reminds me of ReiserFS.
Good in theory, not so hot in practice.
I must say that after updating that old ReiserFS-based system I had
(from back when Reiser was SUSE's default), it's now working quite
glitch-free. No tree rebuilds have been necessary in ages.
I'd expect SystemD will become usable far far after people give up on
it. All because it was introduced into distros quite prematurely.
In any case, aside from the obscurity of it, I haven't found such big
roadblocks with SystemD. It has an incredibly steep learning curve
though. For those used to the simplicity of SysVInit (once installed),
SystemD is as obscure as Windows' registry database. I felt like that
when I wanted to move kdm's startup sequence to a bit earlier (it
seems to wait for way more than would be required, delaying the login
screen), and for the life of me every step felt like I was going to
have to ask a clairvoyant or something, because it was nigh-impossible
to follow. I failed, btw, since the dependency is buried away in heaps
of indirection, and changing it would have required massive
restructuring of the distro's init sequence. Not to mention the error
messages, SystemD must have been the golden disciple of C++ in that
sense.
TBH, from what I saw, I think most of this obscurity stems from trying
to keep sysvinit scripts around.
Anyway, I digress. SLES will probably end up using SystemE, a
fictitious next-incarnation of SystemD, built with all the experience
learned from SystemD's mistakes Like btrfs seems compared to ReiserFS.
Only that will take about 5 years, if Reiser's story holds equivalent.
Until then... prepare to rebuild your tree... I mean swap your busybox
quite often.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Right now I would appreciate a working SysV-Init
implementation we had
for 20 years much more than the ever changing and ever broken crap that
systemd is.
It is not.
2:15 a.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
El 13/04/13 20:34, Stefan Seyfried escribió:
Am 14.04.2013 00:34, schrieb Cristian Rodríguez:
didnt this --> http://freedesktop.org/wiki/Software/systemd/Debugging
help ? are you sure the "freeze" is caused by systemd ? maybe be kernel
bug..just saying...
El 13/04/13 19:19, Stefan Seyfried escribió:
That's not feasible as I need to enable debugging at boot and then have
lots debug information wasting cycles just to debug the shutdown 2 weeks
later once a new kernel is out.
Or is there a way to enable debugging just before shutdown? I have not
found one. Nobody fixes systemd bugs is my observation. Only
new ones are added all
the time :-)
That's not true.
My machine has been unable to shut down without
sysrq-E and sometimes
sysrq-I.
It hangs somewhere, but because everything is totally silent it does not
show any debugging output.
did you enabled debugging ? My cryptohome does not mount every second boot. This
time it was
actually asking me for the password on the text console and echoing the
passphrase to the terminal(!), but then at least it mounted $HOME.
I think I have reported cryptohome mount problems at least three times
in bugzilla, but I'm just tired of it.
There were bugs, in the next iteration of systemd there are fixes
included for that.
Forwarding to syslog-ng does not work. Only "Forwarding to syslog missed
XXX messages" all the time.
have you considered that might be a bug in syslog-ng units and nothing
to do with systemd ?
(and no, journal is not an
alternative, because the performance is abysmal.
"journalctl", then
hitting "end" thrashes my disk for about three minutes before
responding. I can grep through 3 Years worth of /var/log/messages-* in
the same time).
Since systemd 195 there have been a lot of improvements into the
journal, I suggest you test and report what happends with systemd > 201
Maybe it works for you, but for me it is an
nondeterministic heap of
crap. Latest example: Curiously after timedatectl was mentioned in this
hread, I issued "timedatectl" as a nonprivileged user(!) to see what it
would give me. Now I no longer can start / stop ntp and ntp is broken.
WTF? (Yes, I killed all involved processes I could find in the mean
time). Probably the solution will be a reboot. Systemd really brings us
closer to the other "great" Desktop OS's.
timedatectl does not cause any misbehaviour here and well, NTPD is not
integrated with timedatectl/timedated in 12.3 .. it does not have native
units and does not have hooks into it, this is not a bug of systemd but
on the ntp package.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
11:09 a.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
Am 14.04.2013 02:15, schrieb Cristian Rodríguez:
Yes, there have always been, in every iteration since I first tried
systemd-30 or such. However, with SysV init my very same cryptohome has
just worked for way longer than 10 years.
10 years from now, maybe it will even work with systemd.
Syslog worked very well before systemd / journal got forced down
everyone's throats.
One thing I really hate about systemd is the total ignorance of both
upstream and many of its downstream proponents (Frederic is explicitly
excluded from this rant):
"we break everything *simply because we can*"
"everybody else needs to clean up the mess we left"
The tipping point for me was the "break everybody's suspend keys
config". Now I'm done with it.
Syslog worked before systemd.
Then it broke (until yesterday, right now it seems to work but that
might be typical nondeterministic systemd behaviour). IMNSVHO the ones
who broke it should fix it. No, the finger is pointed at everybody else
doing "broken" things -- funnily the same "broken" things have worked
for ages before.
I'm running Factory, there it is even more broken apparently.
(Yes, I know, Factory might contain new bugs, this is why I normally
keep silent about all the systemd stuff. I joust could not stand the
cheering systemd crowd anymore this time. I'll go back and just work
around the issues for me now. Building a full featured current busybox
right now).
El 13/04/13 20:34, Stefan Seyfried escribió:
Cite: "after booting with systemd.log_level=debug
systemd.log_target=kmsg log_buf_len=1M"
I'm not very inclined towards running all productive systems with "sir
spamalot" configuration to diagnose eventual shutdown problems.
I'll probably look into the debug shell.
Anyway -- debugging this with SysV init was a breeze compared with systemd.
That's not feasible as I need to enable
debugging at boot and then have
lots debug information wasting cycles just to debug the shutdown 2 weeks
later once a new kernel is out.
Or is there a way to enable debugging just before shutdown? I have not
found one.
didnt this --> http://freedesktop.org/wiki/Software/systemd/Debugging
help ? are you sure the "freeze" is caused by
systemd ? maybe be kernel
bug..just saying...
Pretty sure. After several sysrq-E, "ctrl-alt-del", sysrq-E, waiting,
more sysrq-E, some more ctrl-alt-del the system finally reboots. Most of
the time. Does not really look like a kernel problem to me.
My cryptohome
does not mount every second boot. This time it was
actually asking me for the password on the text console and echoing the
passphrase to the terminal(!), but then at least it mounted $HOME.
I think I have reported cryptohome mount problems at least three times
in bugzilla, but I'm just tired of it.
There were bugs, in the next iteration of systemd there are fixes
included for that. Forwarding to
syslog-ng does not work. Only "Forwarding to syslog missed
XXX messages" all the time.
have you considered that might be a bug in syslog-ng units and nothing
to do with systemd ? (and no, journal is not an
I doubt they will fix the online file format after the fact. The problem
is, that it creates massively fragmented files on-disk and this hurts
everyone with non-SSD setup. Probably it works well on Lennart and Kay's
notebooks with fast SSD but it sucks almost everywhere else.
Even each "systemctl status foo.service" thrashes the disk for ~10
seconds because it queries the journal.
And yeah -- again "the next version will fix it". I'm hearing this for
too long.
alternative, because the performance is abysmal.
"journalctl", then
hitting "end" thrashes my disk for about three minutes before
responding. I can grep through 3 Years worth of /var/log/messages-* in
the same time).
Since systemd 195 there have been a lot of improvements into the
journal, I suggest you test and report what happends with systemd > 201 Maybe it works
for you, but for me it is an nondeterministic heap of
crap. Latest example: Curiously after timedatectl was mentioned in this
hread, I issued "timedatectl" as a nonprivileged user(!) to see what it
would give me. Now I no longer can start / stop ntp and ntp is broken.
WTF? (Yes, I killed all involved processes I could find in the mean
time). Probably the solution will be a reboot. Systemd really brings us
closer to the other "great" Desktop OS's.
timedatectl does not cause any misbehaviour here and well, NTPD is not
integrated with timedatectl/timedated in 12.3 .. it does not have native
units and does not have hooks into it, this is not a bug of systemd but
on the ntp package.
Yeah, but why do the systemd proponents not fix it? Why does everyone
need to clean up after systemd?
--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
6:43 p.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
El 14/04/13 06:09, Stefan Seyfried escribió:
Syslog worked before systemd.
Then it broke (until yesterday, right now it seems to work but that
might be typical nondeterministic systemd behaviour).
systemd is doing what is told, however what it is being told is
wrong,apparently those who wrote the syslog openSUSE-custom units, did
not RTFM.
Yeah, but why do the systemd proponents not fix it?
Why does everyone
need to clean up after systemd?
That's what we have been doing for a while, it is bummer than days only
have 24 hours...
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
7:18 p.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
El 14/04/13 06:09, Stefan Seyfried escribió:
Anyway -- debugging this with SysV init was a breeze
compared with systemd.
No Stefan, it wasn't a breeze, it was a hack that required debugging
shell scripts.
Pretty sure. After several sysrq-E,
"ctrl-alt-del", sysrq-E, waiting,
more sysrq-E, some more ctrl-alt-del the system finally reboots. Most of
the time. Does not really look like a kernel problem to me.
If your machine has /dev/watchdog device you could also set
RuntimeWatchdogSec=20s in /etc/systemd/system then the hardware will
take care of rebooting the machine when things go bad.
However it will be cool to know why does it "freeze" at boot.
One thing I really hate about systemd is the total
ignorance of both
upstream.
Then you are not paying good attention, pretty much everything has or is
landing in upstream projects in one way or another.
I doubt they will fix the online file format after the
fact. The problem
is, that it creates massively fragmented files on-disk and this hurts
everyone with non-SSD setup. Probably it works well on Lennart and Kay's
notebooks with fast SSD but it sucks almost everywhere else.
Even each "systemctl status foo.service" thrashes the disk for ~10
seconds because it queries the journal.
And yeah -- again "the next version will fix it". I'm hearing this for
too long.
Since I see you are using syslog..(and by your description of fact, the
journal lives on a btrfs partition..does it?) can I suggest you a
workaround in the meanwhile ? set Storage=volatile in
/etc/systemd/journald.conf.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
7:58 p.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
(maybe we should move the discussion to factory? anyway, I'd think we
better let it die soon)
Am 14.04.2013 19:18, schrieb Cristian Rodríguez:
Actually I'd prefer to do sysrq-E, syrq-I, sysrq-S, sysrq-U before just
rebooting it hard. Often enough, a few additional sysrq-E and
ctrl-alt-del actally make sytemd reboot the system, but it takes way
longer than the old "slow" sysV init... so much for fast booting, fast
shutdown surely comes with the next version.
El 14/04/13 06:09, Stefan Seyfried escribió:
Which is a breeze compared with debugging systemd. As systemd is PID 1,
a single mistyped debug-printf in the code will panic my system. If I
mistype something in an init script, I boot with init=/bin/bash and fix
the typo.
Compared to "#!/bin/bash -x" in the old-style init scripts, it is much
harder to debug systemd correctly.
Anyway -- debugging this with SysV init was a
breeze compared with
systemd.
No Stefan, it wasn't a breeze, it was a hack that required debugging
shell scripts. Pretty sure.
After several sysrq-E, "ctrl-alt-del", sysrq-E, waiting,
more sysrq-E, some more ctrl-alt-del the system finally reboots. Most of
the time. Does not really look like a kernel problem to me.
If your machine has /dev/watchdog device you could also set
RuntimeWatchdogSec=20s in /etc/systemd/system then the hardware will
take care of rebooting the machine when things go bad. However it will be cool to know why does it
"freeze" at boot.
No. plain old ext4. I'm a bit conservative on my production machines.
One thing I really hate about systemd is the
total ignorance of both
upstream.
Then you are not paying good attention, pretty much everything has or is
landing in upstream projects in one way or another.
I doubt they will fix the online file format
after the fact. The problem
is, that it creates massively fragmented files on-disk and this hurts
everyone with non-SSD setup. Probably it works well on Lennart and Kay's
notebooks with fast SSD but it sucks almost everywhere else.
Even each "systemctl status foo.service" thrashes the disk for ~10
seconds because it queries the journal.
And yeah -- again "the next version will fix it". I'm hearing this for
too long.
Since I see you are using syslog..(and by your description of fact, the
journal lives on a btrfs partition..does it?) can I suggest you a
workaround in the meanwhile ? set Storage=volatile in
/etc/systemd/journald.conf.
I'll do that once I gained some confidence that the working syslog is
not an accident (means: it survives a few reboots).
Again with the journal, similar to systemd: the idea looks promising,
but the implementation is painful.
--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
8:18 p.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
El 14/04/13 14:58, Stefan Seyfried escribió:
(maybe we should move the discussion to factory?
anyway, I'd think we
better let it die soon)
Am 14.04.2013 19:18, schrieb Cristian Rodríguez:
Myth 25 --> http://0pointer.de/blog/projects/the-biggest-myths.html
El 14/04/13 06:09, Stefan Seyfried escribió:
Which is a breeze compared with debugging systemd. As systemd is PID 1,
a single mistyped debug-printf in the code will panic my system. If I
mistype something in an init script, I boot with init=/bin/bash and fix
the typo.
Compared to "#!/bin/bash -x" in the old-style init scripts, it is much
harder to debug systemd correctly. Anyway -- debugging this with SysV init was a
breeze compared with
systemd.
No Stefan, it wasn't a breeze, it was a hack that required debugging
shell scripts. I'll do that once I gained some confidence that
the working syslog is
not an accident (means: it survives a few reboots).
If you applied the unit I sent you, ensure things are cool by issuing
systemctl reenable syslog-ng.service too (missed that bit in the prev mail)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
9:43 p.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
On Sun, Apr 14, 2013 at 6:09 AM, Stefan Seyfried
<stefan.seyfried(a)googlemail.com> wrote:
This may have something to do with the fact that the journal is mmaped
into memory, even for writing.
It may be worthwhile to consider a different strategy there, or at
least make heavy use of madvise, in conjunction with preallocating the
space on disk, to make sure the FS allocates it sequentially.
Otherwise, the result will be a sparse file, which are usually heavily
fragmented when written in random order.
I guess I should say this upstream, but the thought occurred to me
here, I hope Christian will push it upstream if it is worthwhile?
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
(and no,
journal is not an
I doubt they will fix the online file format after the fact. The problem
is, that it creates massively fragmented files on-disk and this hurts
everyone with non-SSD setup. Probably it works well on Lennart and Kay's
notebooks with fast SSD but it sucks almost everywhere else.
Even each "systemctl status foo.service" thrashes the disk for ~10
seconds because it queries the journal. alternative, because the performance is abysmal.
"journalctl", then
hitting "end" thrashes my disk for about three minutes before
responding. I can grep through 3 Years worth of /var/log/messages-* in
the same time).
Since systemd 195 there have been a lot of improvements into the
journal, I suggest you test and report what happends with systemd > 201
7:33 a.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
В Sun, 14 Apr 2013 01:34:53 +0200
Stefan Seyfried <stefan.seyfried(a)googlemail.com> пишет:
Am 14.04.2013 00:34, schrieb Cristian Rodríguez:
SIGRTMIN+22, SIGRTMIN+23
Sets the log level to debug (or info on SIGRTMIN+23), as controlled
via systemd.log_level=debug (or systemd.log_level=info on
SIGRTMIN+23) on the kernel command line.
SIGRTMIN+26, SIGRTMIN+27, SIGRTMIN+28, SIGRTMIN+29
Sets the log level to journal-or-kmsg (or console on SIGRTMIN+27,
You can list signals using "kill -l"; SIGRTMIN+22 is 56 here and
SIGRTMIN+27 is 61. So
kill -56 1
kill -61 1
dmesg -n 7
Gives me debug output on console (I had to repeat "kill -61" for
whatever reason, may be it takes time to switch).
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
El 13/04/13 19:19, Stefan Seyfried escribió:
That's not feasible as I need to enable debugging at boot and then have
lots debug information wasting cycles just to debug the shutdown 2 weeks
later once a new kernel is out.
Or is there a way to enable debugging just before shutdown? I have not
found one.
Nobody fixes systemd bugs is my observation. Only
new ones are added all
the time :-)
That's not true.
My machine has been unable to shut down without
sysrq-E and sometimes
sysrq-I.
It hangs somewhere, but because everything is totally silent it does not
show any debugging output.
did you enabled debugging ?
11:16 a.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
Am 14.04.2013 07:33, schrieb Andrey Borzenkov:
That's good to know. I would put this into before.local so that I don't
forget it, but I'm pretty sure (have not tried) that this no longer
works with systemd.
Thanks, this might help when the next kernel comes out.
--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
В Sun, 14 Apr 2013 01:34:53 +0200
Stefan Seyfried <stefan.seyfried(a)googlemail.com> пишет:
That's not
feasible as I need to enable debugging at boot and then have
lots debug information wasting cycles just to debug the shutdown 2 weeks
later once a new kernel is out.
Or is there a way to enable debugging just before shutdown? I have not
found one.
SIGRTMIN+22, SIGRTMIN+23
Sets the log level to debug (or info on SIGRTMIN+23), as controlled
via systemd.log_level=debug (or systemd.log_level=info on
SIGRTMIN+23) on the kernel command line.
SIGRTMIN+26, SIGRTMIN+27, SIGRTMIN+28, SIGRTMIN+29
Sets the log level to journal-or-kmsg (or console on SIGRTMIN+27,
You can list signals using "kill -l"; SIGRTMIN+22 is 56 here and
SIGRTMIN+27 is 61. So
kill -56 1
kill -61 1
dmesg -n 7
7:40 a.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
В Sat, 13 Apr 2013 19:34:44 -0300
Cristian Rodríguez <crrodriguez(a)opensuse.org> пишет:
Did you actually try to debug problems that happen on shutdown due to
incorrect unit dependencies? systemd simply does not provide enough
information so it is more of a black magic than science. You just see
that something is timed out. You never see *why* it timed out (i.e. what
unit it had been waiting on).
This had been this way 3 years ago, this remains this way today. As
far as I can tell this is due to design of systemd so I am not sure if
it is even possible to ever fix it.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
My machine has been unable to shut down without
sysrq-E and sometimes
sysrq-I.
It hangs somewhere, but because everything is totally silent it does not
show any debugging output.
did you enabled debugging ?
16 Apr
16 Apr
3:02 p.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
On Sun, Apr 14, 2013 at 09:40:28AM +0400, Andrey Borzenkov wrote:
Did you actually try to debug problems that happen on
shutdown due to
incorrect unit dependencies? systemd simply does not provide enough
information so it is more of a black magic than science. You just see
that something is timed out. You never see *why* it timed out (i.e. what
unit it had been waiting on).
This had been this way 3 years ago, this remains this way today. As
far as I can tell this is due to design of systemd so I am not sure if
it is even possible to ever fix it.
Latest systemd will tell you what timed out.
--
Regards,
Olav
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
14 Apr
14 Apr
2:55 a.m.
New subject: syslog loosing messages [WAS[opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages]
Ok Stefan:
So your syslog-ng losses messages on boot.. can you please test the
following unit file and report back ?
save it as "syslog-ng.service" in /etc/systemd/system/
[Unit]
Description=System Logging Service
Requires=var-run.mount
Requires=syslog.socket
After=var-run.mount
Conflicts=rsyslog.service syslogd.service
[Service]
Environment=SYSLOG_NG_PARAMS=
ExecStartPre=/usr/sbin/syslog-ng-service-prepare
EnvironmentFile=-/etc/sysconfig/syslog
ExecStart=/usr/sbin/syslog-ng -F $SYSLOG_NG_PARAMS
ExecReload=/bin/kill -HUP $MAINPID
StandardOutput=null
[Install]
WantedBy=multi-user.target
Alias=syslog.service
systemctl --system daemon-reload
test, test, test..
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
11:29 a.m.
New subject: syslog loosing messages [WAS[opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages]
Am 14.04.2013 02:55, schrieb Cristian Rodríguez:
Ok Stefan:
So your syslog-ng losses messages on boot.. can you please test the
following unit file and report back ?
save it as "syslog-ng.service" in /etc/systemd/system/
[Unit]
Description=System Logging Service
Requires=var-run.mount
Requires=syslog.socket
After=var-run.mount
Conflicts=rsyslog.service syslogd.service
[Service]
Environment=SYSLOG_NG_PARAMS=
ExecStartPre=/usr/sbin/syslog-ng-service-prepare
EnvironmentFile=-/etc/sysconfig/syslog
ExecStart=/usr/sbin/syslog-ng -F $SYSLOG_NG_PARAMS
ExecReload=/bin/kill -HUP $MAINPID
StandardOutput=null
[Install]
WantedBy=multi-user.target
Alias=syslog.service
systemctl --system daemon-reload
test, test, test..
Ok, changed this, next reboot date depends on Kernel:HEAD having x86_64
relevant updates
I found that /etc/systemd/system contains lots of directories and
symlinks that do not belong to any package. And then there is one file
that also does not belong to any package:
systemd-random-seed-load.service
it's dated Jan 29 2013, I'm pretty sure I did not create it manually and
it fails.
To get back on topic in opensuse-packaging:
should we mark all those /etc/systemd/system/dbus-org.bluez.service and
friends as %ghost in the packages so that one actually can find out if
this is a system file or not? I'm usually inclined to remove everything
not known to RPM from my systems, but I figured that this might break my
system even more.... :-)
--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
12:22 p.m.
New subject: syslog loosing messages [WAS[opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages]
On Sun, 14 Apr 2013 11:29, Stefan Seyfried <stefan.seyfried@...> wrote:
Am 14.04.2013 02:55, schrieb Cristian Rodríguez:
> Ok Stefan:
[snip]
I found that /etc/systemd/system contains lots of
directories and
symlinks that do not belong to any package. And then there is one file
that also does not belong to any package:
systemd-random-seed-load.service
it's dated Jan 29 2013, I'm pretty sure I did not create it manually and
it fails.
To get back on topic in opensuse-packaging:
should we mark all those /etc/systemd/system/dbus-org.bluez.service and
friends as %ghost in the packages so that one actually can find out if
this is a system file or not? I'm usually inclined to remove everything
not known to RPM from my systems, but I figured that this might break my
system even more.... :-)
With these symlinks under /etc/systemd/.. does systemd the control what to
start (and what target wants which service / socket),
similar to /etc/init.d/rc?.d/[SK][num][name] symlinks from sysVinit.
The service / socket / target files themself reside under /lib/systemd/...
and / or /usr/lib/systemd/... so, if you have a candidate like
"systemd-random-seed-load.service" from above, use locate / or find -name
on those two "lib" dirs, for the file shown this should give:
/usr/lib/systemd/system/sysinit.target.wants/systemd-random-seed-load.service
/usr/lib/systemd/system/systemd-random-seed-load.service
and a man-page:
/usr/share/man/man8/systemd-random-seed-load.service.8.gz
a "rpm -qf" on those makes more sense than on the /etc/ symlinks.
(and shows that this file belongs to the systemd package)
But imho it's a learn-everything-anew thing with systemd, esp.
debugging faults is not so easy any more.
For example:
But a nonvalid line in your syslog-ng / rsyslog config
and do a "systemctl reload syslog.service" .
Just where are your "Fail / Error" messages? - Not nice.
A "systemctl status syslog.service" gives just a "failed"
but not the error message from the deamon itself. And
systemd tries to spawn syslog.service contiously anew.
Happy debugging.
A question to the ones that do the config defaults
for rsyslogd : why are the cron messages in the
/var/log/NetworkManager file? (OSS 12.3 out of the box)
I'm still at the start of learning how to handle systemd.
For added praxis I try writing .service files for deamons
that I use and that do not bring them in the package.
That can be very frustrating, due to the lack of useable
debug output.
And then we can start about determinability. Or the lack of.
- Yamaban, who wishes you all a nice weekend.
12:58 p.m.
New subject: syslog loosing messages [WAS[opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages]
> On
14/4/2013 at 03:52 PM, Yamaban <foerster(a)lisas.de> wrote:
On Sun, 14 Apr
2013 11:29, Stefan Seyfried <stefan.seyfried@...> wrote:
Am 14.04.2013 02:55, schrieb Cristian Rodríguez:
> Ok Stefan:
[snip]
> I found that /etc/systemd/system contains lots of directories and
> symlinks that do not belong to any package. And then there is one file
> that also does not belong to any package:
>
> systemd-random-seed-load.service
> For example:
But a nonvalid line in your syslog-ng / rsyslog config
and do a "systemctl reload syslog.service" .
Just where are your "Fail / Error" messages? - Not nice.
journalctl [-b]
Refer to journalctl man page to view logs of a specific unit or other uses.
Srinidhi.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
1:20 p.m.
New subject: syslog loosing messages [WAS[opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages]
В Sun, 14 Apr 2013 04:58:01 -0600
"Srinidhi B" <srinidhi(a)novell.com> пишет:
<snip>>
You miss the point. systemd silently ignores error and pretends unit
file is OK. There is no reason to dig into journal because no error is
reported in the first place.
bor@opensuse:~> sudo systemctl status foo.service
foo.service - Test foo
Loaded: loaded (/run/systemd/system/foo.service; static)
Active: inactive (dead)
CGroup: name=systemd:/system/foo.service
bor@opensuse:~> sudo systemctl show -p Type foo.service
Type=simple
bor@opensuse:~> grep Type /run/systemd/system/foo.service
Type=xxxx
See? It ignored invalid value for Type and silently replaced it with
something else. Yes, you will see it in journal, but admin has no
reason to look there in the first place - everything appears to be OK.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
> On 14/4/2013 at 03:52 PM, Yamaban
<foerster(a)lisas.de> wrote:
On Sun, 14 Apr 2013 11:29, Stefan Seyfried
<stefan.seyfried@...> wrote:
Am 14.04.2013 02:55, schrieb Cristian Rodríguez:
> Ok Stefan:
[snip]
> I found that /etc/systemd/system contains lots of directories and
> symlinks that do not belong to any package. And then there is one file
> that also does not belong to any package:
>
> systemd-random-seed-load.service
> For example:
But a nonvalid line in your syslog-ng / rsyslog config
and do a "systemctl reload syslog.service" .
Just where are your "Fail / Error" messages? - Not nice.
journalctl [-b]
Refer to journalctl man page to view logs of a specific unit or other uses.
7:41 p.m.
New subject: syslog loosing messages [WAS[opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages]
El 14/04/13 08:20, Andrey Borzenkov escribió:
See? It ignored invalid value for Type and silently replaced it with
something else. Yes, you will see it in journal, but admin has no
reason to look there in the first place - everything appears to be OK.
Hrmm..you might have a point here..
if (!empty(type) || !is_valid_type(type)) then it should mark the unit
as failed... empty means "simple"..
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
17 Apr
17 Apr
8:41 a.m.
New subject: syslog loosing messages [WAS[opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages]
On Sun, Apr 14, 2013 at 2:22 PM, Yamaban <foerster(a)lisas.de> wrote:
But imho it's a learn-everything-anew thing with
systemd, esp.
debugging faults is not so easy any more.
For example:
But a nonvalid line in your syslog-ng / rsyslog config
and do a "systemctl reload syslog.service" .
Just where are your "Fail / Error" messages? - Not nice.
A "systemctl status syslog.service" gives just a "failed"
but not the error message from the deamon itself. And
systemd tries to spawn syslog.service contiously anew.
Happy debugging.
Could you test if this commit does what you want?
http://cgit.freedesktop.org/systemd/systemd/commit/?id=e8e581bf256b8c0fbd43…
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
14 Apr
14 Apr
6:28 p.m.
New subject: syslog loosing messages [WAS[opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages]
El 14/04/13 06:29, Stefan Seyfried escribió:
I found that /etc/systemd/system contains lots of
directories and
symlinks that do not belong to any package.
That's correct, nothing there belongs to any package, expected.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
17 Apr
17 Apr
10:28 a.m.
New subject: syslog loosing messages [WAS[opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages]
Am 14.04.2013 02:55, schrieb Cristian Rodríguez:
Ok Stefan:
So your syslog-ng losses messages on boot.. can you please test the
following unit file and report back ?
save it as "syslog-ng.service" in /etc/systemd/system/
[Unit]
Description=System Logging Service
Requires=var-run.mount
Requires=syslog.socket
After=var-run.mount
Conflicts=rsyslog.service syslogd.service
[Service]
Environment=SYSLOG_NG_PARAMS=
ExecStartPre=/usr/sbin/syslog-ng-service-prepare
EnvironmentFile=-/etc/sysconfig/syslog
ExecStart=/usr/sbin/syslog-ng -F $SYSLOG_NG_PARAMS
ExecReload=/bin/kill -HUP $MAINPID
StandardOutput=null
[Install]
WantedBy=multi-user.target
Alias=syslog.service
rebooted today,
susi:~ # journalctl -b | grep Forwarding
Apr 17 08:46:05 susi.home.s3e.de systemd-journal[249]: Forwarding to syslog missed 112
messages.
Apr 17 08:46:46 susi.home.s3e.de systemd-journal[249]: Forwarding to syslog missed 31
messages.
Before:
Apr 17 08:45:41 susi.home.s3e.de systemd[1]: Starting Syslog Socket.
Apr 17 08:45:41 susi.home.s3e.de systemd[1]: Listening on Syslog Socket.
...
Apr 17 08:45:41 susi.home.s3e.de systemd[1]: Started Journal Service.
Apr 17 08:45:41 susi.home.s3e.de systemd[1]: Starting Syslog.
Apr 17 08:45:41 susi.home.s3e.de systemd[1]: Reached target Syslog.
susi:~ # ps xauwww|grep syslog-ng
root 1022 0.0 0.0 211028 4196 ? Ssl 08:46 0:00 /usr/sbin/syslog-ng -F
susi:~ # stat /proc/1022/
File: ‘/proc/1022/’
Size: 0 Blocks: 0 IO Block: 1024 directory
Device: 3h/3d Inode: 14613 Links: 8
Access: (0555/dr-xr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2013-04-17 08:46:09.932639720 +0200
Modify: 2013-04-17 08:46:09.932639720 +0200
Change: 2013-04-17 08:46:09.932639720 +0200
Birth: -
So it looks like syslog-ng is only started after the first "Forwarding to
syslog missed..." message.
But I can tolerate this if it now keeps logging for longer than a few days (I
rebooted because it again stopped doing that and apparently the only way to
get things to work reliably with systemd is to reboot, at least if you don't
want to do a PhD thesis on "booting linux" but just work with the box).
I understand correctly: there is no way to get rid of journal completely and
just log to syslog like we always did (or passing the messages from syslog to
journal instead of the other, non-working way round)?
Would it be possible to let the journal only handle systemd but keep away
from the tradiditonal syslog socket?
--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
11:01 a.m.
New subject: syslog loosing messages [WAS[opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages]
On Wed, Apr 17, 2013 at 12:28 PM, Stefan Seyfried
<stefan.seyfried(a)googlemail.com> wrote:
... alias syslog.service is correctly created?
Am 14.04.2013 02:55, schrieb Cristian Rodríguez:
> Ok Stefan:
>
> So your syslog-ng losses messages on boot.. can you please test the
> following unit file and report back ?
>
>
> save it as "syslog-ng.service" in /etc/systemd/system/
>
Does not it also need "systemctl enable syslog-ng.service", so that ...
[Unit]
Description=System Logging Service
Requires=var-run.mount
Requires=syslog.socket
After=var-run.mount
Conflicts=rsyslog.service syslogd.service
[Service]
Environment=SYSLOG_NG_PARAMS=
ExecStartPre=/usr/sbin/syslog-ng-service-prepare
EnvironmentFile=-/etc/sysconfig/syslog
ExecStart=/usr/sbin/syslog-ng -F $SYSLOG_NG_PARAMS
ExecReload=/bin/kill -HUP $MAINPID
StandardOutput=null
[Install]
WantedBy=multi-user.target
Alias=syslog.service
rebooted today,
susi:~ # journalctl -b | grep Forwarding
Apr 17 08:46:05 susi.home.s3e.de systemd-journal[249]: Forwarding to syslog missed 112
messages.
Apr 17 08:46:46 susi.home.s3e.de systemd-journal[249]: Forwarding to syslog missed 31
messages.
Before:
Apr 17 08:45:41 susi.home.s3e.de systemd[1]: Starting Syslog Socket.
Apr 17 08:45:41 susi.home.s3e.de systemd[1]: Listening on Syslog Socket.
...
Apr 17 08:45:41 susi.home.s3e.de systemd[1]: Started Journal Service.
Apr 17 08:45:41 susi.home.s3e.de systemd[1]: Starting Syslog.
Apr 17 08:45:41 susi.home.s3e.de systemd[1]: Reached target Syslog.
susi:~ # ps xauwww|grep syslog-ng
root 1022 0.0 0.0 211028 4196 ? Ssl 08:46 0:00 /usr/sbin/syslog-ng -F
susi:~ # stat /proc/1022/
File: ‘/proc/1022/’
Size: 0 Blocks: 0 IO Block: 1024 directory
Device: 3h/3d Inode: 14613 Links: 8
Access: (0555/dr-xr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2013-04-17 08:46:09.932639720 +0200
Modify: 2013-04-17 08:46:09.932639720 +0200
Change: 2013-04-17 08:46:09.932639720 +0200
Birth: -
So it looks like syslog-ng is only started after the first "Forwarding to
syslog missed..." message.
Yes, it tries to start syslog.service when something connects to
syslog socket. What "systemctl status syslog.service" show?
But I can tolerate this if it now keeps logging for
longer than a few days (I
rebooted because it again stopped doing that and apparently the only way to
get things to work reliably with systemd is to reboot, at least if you don't
want to do a PhD thesis on "booting linux" but just work with the box).
I understand correctly: there is no way to get rid of journal completely and
just log to syslog like we always did (or passing the messages from syslog to
journal instead of the other, non-working way round)?
Would it be possible to let the journal only handle systemd but keep away
from the tradiditonal syslog socket?
OK, but let's face it - before journald these messages were silently
lost. Now you are at least aware of this and optionally can also
collect and store them persistently. Why getting messages is worse
than losing them?
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
4:57 p.m.
New subject: syslog loosing messages [WAS[opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages]
On 04/17/2013 06:01 AM, Andrey Borzenkov wrote:
On Wed, Apr 17, 2013 at 12:28 PM, Stefan Seyfried
<stefan.seyfried(a)googlemail.com> wrote:
yep.
Am 14.04.2013 02:55, schrieb Cristian Rodríguez:
> Ok Stefan:
>
> So your syslog-ng losses messages on boot.. can you please test the
> following unit file and report back ?
>
>
> save it as "syslog-ng.service" in /etc/systemd/system/
>
Does not it also need "systemctl enable syslog-ng.service", so that ... ... alias syslog.service is correctly created?
It should be on systemctl reenable...
OK, but let's face it - before journald these
messages were silently
lost. Now you are at least aware of this and optionally can also
collect and store them persistently. Why getting messages is worse
than losing them?
Im also a little bit annoyed by this, because I fail to see what exactly
is his complain now, first it was because messages were lost, now it is
because messages are beign forwarded huh wth?
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
5:41 p.m.
New subject: syslog loosing messages [WAS[opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages]
Am 17.04.2013 11:01, schrieb Andrey Borzenkov:
OK, but let's face it - before journald these
messages were silently
lost. Now you are at least aware of this and optionally can also
collect and store them persistently. Why getting messages is worse
than losing them?
I don't care too much about not forwarding the boot messages, as long as
the journal does not stop forwarding after some random time (a few
days). That is really pissing me off.
(And no, "the journal has them stored also" is not an answer. It is too
slow and I cannot grep through those logs with my known-working tools).
--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
5:45 p.m.
New subject: syslog loosing messages [WAS[opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages]
El 17/04/13 12:41, Stefan Seyfried escribió:
I don't care too much about not forwarding the
boot messages, as long as
the journal does not stop forwarding after some random time (a few
days). That is really pissing me off.
Does it stop forwarding after days ? why you did not mentioned this ?
(And no, "the journal has them stored also" is not an answer. It is too
slow
Your disk is slow.. ;)
and I cannot grep through those logs with my
known-working tools).
There is no need for grep in this case..
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
5:49 p.m.
New subject: syslog loosing messages [WAS[opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages]
Am 17.04.2013 17:45, schrieb Cristian Rodríguez:
El 17/04/13 12:41, Stefan Seyfried escribió:
This was my complaint from the beginning. The drop at boot was just an
additional detail.
--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
I don't care too much about not forwarding
the boot messages, as long as
the journal does not stop forwarding after some random time (a few
days). That is really pissing me off.
Does it stop forwarding after days ? why you did not mentioned this ?
6:23 p.m.
New subject: syslog loosing messages [WAS[opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages]
El 17/04/13 12:49, Stefan Seyfried escribió:
This was my complaint from the beginning.
OK, I dont think that we could solve either a bug or confussion here,
please open a report about this.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
5:48 p.m.
New subject: syslog loosing messages [WAS[opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages]
I don't care too much about not forwarding the
boot messages, as long as
the journal does not stop forwarding after some random time (a few
days). That is really pissing me off.
With the new units, syslog implementations *require* the syslog socket,
if that goes away for whatever reason, the service will fail and you
will know why ...
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
4:51 p.m.
New subject: syslog loosing messages [WAS[opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages]
On 04/17/2013 05:28 AM, Stefan Seyfried wrote:
susi:~ # journalctl -b | grep Forwarding
Apr 17 08:46:05 susi.home.s3e.de systemd-journal[249]: Forwarding to syslog missed 112
messages.
Apr 17 08:46:46 susi.home.s3e.de systemd-journal[249]: Forwarding to syslog missed 31
messages.
This is correct, it is operating exactly as intended.
So it looks like syslog-ng is only started after the
first "Forwarding to
syslog missed..." message.
Yes, nothing wrong with that, what do you expect ? no messages "lost",
as the log says the journal forwarded messages to syslog when it
started, syslog is a regular service, it has to start waay *after*
systemd begins logging..
I understand correctly: there is no way to get rid of
journal completely and
just log to syslog like we always did (or passing the messages from syslog to
journal instead of the other, non-working way round)?
Would it be possible to let the journal only handle systemd but keep away
from the tradiditonal syslog socket?
No, and there is nothing wrong in what it is currently doing, care to
explain exactly what you see it is wrong now ?
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
5:31 p.m.
New subject: syslog loosing messages [WAS[opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages]
El 17/04/13 11:51, Cristian Rodríguez escribió:
On 04/17/2013 05:28 AM, Stefan Seyfried wrote:
Messages told to be "missed" are stored in the journal (in the past,
when syslog was the only way, those messages were simply lost) in this
context "missed" means that the syslog socket buffer is full and can't
take it anymore.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
susi:~ # journalctl -b | grep Forwarding
Apr 17 08:46:05 susi.home.s3e.de systemd-journal[249]: Forwarding to
syslog missed 112 messages.
Apr 17 08:46:46 susi.home.s3e.de systemd-journal[249]: Forwarding to
syslog missed 31 messages.
This is correct, it is operating exactly as intended.
So it looks like syslog-ng is only started after
the first "Forwarding to
syslog missed..." message.
Yes, nothing wrong with that, what do you expect ? no messages "lost",
as the log says the journal forwarded messages to syslog when it
started, syslog is a regular service, it has to start waay *after*
systemd begins logging..
5:47 p.m.
New subject: syslog loosing messages [WAS[opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages]
Am 17.04.2013 17:31, schrieb Cristian Rodríguez:
Well, the syslog buffer never was full and dropping messages after a few
days of uptime before journal came along.
This is not about a 100k messages / second syslog server, this is a
notebook with 3 dhclient messages every 30 minutes and all of them get
lost once it starts to malfunction.
I will see if it works better now after the reboot.
And voila: last message in syslog is
Apr 17 14:28:55 susi dhclient[1923]: DHCPREQUEST on air to ...
and journal starts dropping at...
Apr 17 14:31:07 susi.home.s3e.de systemd-journal[249]: Forwarding to
syslog missed 1 messages.
Everything after that is missing from syslog.
=> journald does not work as advertised. Can I prevent
systemd/journald's occupation of the syslog socket somehow?
--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
El 17/04/13 11:51, Cristian Rodríguez escribió:
> On 04/17/2013 05:28 AM, Stefan Seyfried wrote:
>
>> susi:~ # journalctl -b | grep Forwarding
>> Apr 17 08:46:05 susi.home.s3e.de systemd-journal[249]: Forwarding to
>> syslog missed 112 messages.
>> Apr 17 08:46:46 susi.home.s3e.de systemd-journal[249]: Forwarding to
>> syslog missed 31 messages.
>
> This is correct, it is operating exactly as intended.
>
>> So it looks like syslog-ng is only started after the first
>> "Forwarding to
>> syslog missed..." message.
Ok, that's fine.
Yes, nothing
wrong with that, what do you expect ? no messages "lost",
as the log says the journal forwarded messages to syslog when it
started, syslog is a regular service, it has to start waay *after*
systemd begins logging..
Messages told to be "missed" are stored in the journal (in the past,
when syslog was the only way, those messages were simply lost) in this
context "missed" means that the syslog socket buffer is full and can't
take it anymore.
5:55 p.m.
New subject: syslog loosing messages [WAS[opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages]
El 17/04/13 12:47, Stefan Seyfried escribió:
And voila: last message in syslog is
Apr 17 14:28:55 susi dhclient[1923]: DHCPREQUEST on air to ...
Apr 17 14:31:07 susi.home.s3e.de systemd-journal[249]: Forwarding to
syslog missed 1 messages.
Everything after that is missing from syslog.
What do you mean ? You are not expressing your problem correctly I am
afraid
=> journald does not work as advertised.
WHAT? it does work as expected, unless your expectatives are different
or distorted..
Can I prevent
systemd/journald's occupation of the syslog socket
somehow?
No, This is a mandatory feature.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
6:04 p.m.
New subject: syslog loosing messages [WAS[opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages]
Hi,
On Wed, 17 Apr 2013, Cristian Rodríguez wrote:
Isn't that obvious? After the DHCPREQUEST entry there should be more
entries following. There aren't, so they are missing. Stefan complains
about that. Correctly so.
huh? It surely isn't expected to stop forwarding messages to syslog once
there was an error in transmission (which is also highly unlikely to
occur, certainly syslog buffers aren't full because of one DHCP syslog
entry).
Then it better be fixed, right?
Ciao,
Michael.
And voila:
last message in syslog is
Apr 17 14:28:55 susi dhclient[1923]: DHCPREQUEST on air to ...
Apr 17 14:31:07 susi.home.s3e.de systemd-journal[249]: Forwarding to
syslog missed 1 messages.
Everything after that is missing from syslog.
What do you mean ? You are not expressing your problem correctly I am
afraid => journald
does not work as advertised.
WHAT? it does work as expected, unless your expectatives are different or
distorted..
If you could stop being obnoxious I would be thankful.
Can I prevent
systemd/journald's occupation of the syslog socket somehow?
No, This is a mandatory feature.
6:08 p.m.
New subject: syslog loosing messages [WAS[opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages]
El mié 17 abr 2013 13:04:17 CLST, Michael Matz escribió:
Isn't that obvious? After the DHCPREQUEST entry
there should be more
entries following. There aren't, so they are missing. Stefan complains
about that. Correctly so.
OK, then does the journal have the entries then ?
huh? It surely isn't expected to stop forwarding
messages to syslog once
there was an error in transmission (which is also highly unlikely to
occur, certainly syslog buffers aren't full because of one DHCP syslog
entry).
It does not stop forwarding when there is an error ..
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
6:12 p.m.
New subject: syslog loosing messages [WAS[opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages]
Hi,
On Wed, 17 Apr 2013, Cristian Rodríguez wrote:
El mié 17 abr 2013 13:04:17 CLST, Michael Matz
escribió:
That we know only after debugging. The symptoms look like so, and that's
what Stefan reported.
Ciao,
Michael.
Isn't that obvious? After the DHCPREQUEST
entry there should be more
entries following. There aren't, so they are missing. Stefan complains
about that. Correctly so.
OK, then does the journal have the entries then ?
huh? It surely isn't expected to stop
forwarding messages to syslog once
there was an error in transmission (which is also highly unlikely to
occur, certainly syslog buffers aren't full because of one DHCP syslog
entry).
It does not stop forwarding when there is an error ..
7:51 p.m.
New subject: [opensuse-packaging] syslog-ng bug (was: Re: syslog loosing messages)
Am 17.04.2013 18:12, schrieb Michael Matz:
Let's end the thread.
Cristian is probably right, systemd is probably not to blame.
It looks like a syslog-ng bug, it apparently soft-locks around a
g_static_mutex_lock(&self->lock);
https://bugzilla.novell.com/815746
Followup-to: opensuse-factory.
Sorry for the noise, I should have explored this way earlier (But since
syslog-ng has been reliable for me for the last >5 years, it did not
come to my mind...)
Best regards and thanks for all the offered help, now I have at least a
cheat-sheet for what to enable during shutdown to debug systemd shutdown
hangs :-)
Stefan
--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
On Wed, 17 Apr 2013, Cristian Rodríguez wrote:
It does not
stop forwarding when there is an error ..
That we know only after debugging. The symptoms look like so, and that's
what Stefan reported.
8:07 p.m.
New subject: [opensuse-packaging] Re: syslog-ng bug (was: Re: syslog loosing messages)
El mié 17 abr 2013 14:51:45 CLST, Stefan Seyfried escribió:
Am 17.04.2013 18:12, schrieb Michael Matz:
Let's end the thread.
Cristian is probably right, systemd is probably not to blame.
It looks like a syslog-ng bug, it apparently soft-locks around a
g_static_mutex_lock(&self->lock);
heh :-) anyway, the units required adjustment because there weren't
quite right either.
Hi,
On Wed, 17 Apr 2013, Cristian Rodríguez wrote:
It does
not stop forwarding when there is an error ..
That we know only after debugging. The symptoms look like so, and that's
what Stefan reported. Sorry for the noise, I should have explored this way
earlier (But since
syslog-ng has been reliable for me for the last >5 years, it did not
come to my mind...)
No, thank YOU for looking for the root cause ;)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
4 Apr
4 Apr
9:13 a.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
On Thursday, April 04, 2013 08:23:10 Michal Kubeček wrote:
On Wednesday 03 of April 2013 20:20EN, Andreas Jaeger
wrote:
Michal, SLE 12 will have systemd,
Andreas
--
Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
But if a package is not build for SLE 11, then
why should it have an
init file?
Because OpenSuSE is supposed to be a codebase for SLE12. And I don't
see much sense in taking effort in carefully removing anything
reminding System V init now and then making it work with System V
init again several months later (yes, perhaps I'm naïve, but I still
believe there will be System V init in SLE12).
9:23 a.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
On Thursday 04 of April 2013 09:13EN, Andreas Jaeger wrote:
Michal, SLE 12 will have systemd,
Yes, I'm sure this is inevitable. But this doesn't mean it cannot have
System V init.
Michal Kubeček
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
9:34 a.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
On 04/04/2013 04:23 AM, Michal Kubeček wrote:
But this doesn't mean it cannot have
> System V init.
For all practical reasons, yes it means it cannot.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
9:53 a.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
On Thu, Apr 04, 2013 at 04:34:04AM -0300, Cristian Rodríguez wrote:
On 04/04/2013 04:23 AM, Michal Kubeček wrote:
Well the compat mode for 3rd party init scripts will work, but not
much more.
Btw, do not blindly remove sysvinit scripts from packages that
are also built and used on older distributions, e.g. dnsmasq.
Ciao, Marcus
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
But this doesn't mean it cannot have
> System V init.
For all practical reasons, yes it means it cannot.
10:02 a.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
On Thu 04 Apr 2013 04:53:46 AM CLST, Marcus Meissner wrote:
On Thu, Apr 04, 2013 at 04:34:04AM -0300, Cristian
Rodríguez wrote:
Package fails to build in old distros with or without the change.. did
you saw the build status ?
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On 04/04/2013 04:23 AM, Michal Kubeček wrote:
Well the compat mode for 3rd party init scripts will work, but not
much more.
Btw, do not blindly remove sysvinit scripts from packages that
are also built and used on older distributions, e.g. dnsmasq. But this doesn't mean it cannot have
> System V init.
For all practical reasons, yes it means it cannot.
1:17 p.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
On Thu, Apr 04, 2013 at 05:02:55AM -0300, Cristian Rodríguez wrote:
On Thu 04 Apr 2013 04:53:46 AM CLST, Marcus Meissner
wrote:
hmm, it had fails in your project, but i see that network disables it mostly.
Ciao, Marcus
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On Thu, Apr 04, 2013 at 04:34:04AM -0300,
Cristian Rodríguez wrote:
Package fails to build in old distros with or without the change.. did you
saw the build status ? On 04/04/2013 04:23 AM, Michal Kubeček wrote:
Well the compat mode for 3rd party init scripts will work, but not
much more.
Btw, do not blindly remove sysvinit scripts from packages that
are also built and used on older distributions, e.g. dnsmasq. But this doesn't mean it cannot have
> System V init.
For all practical reasons, yes it means it cannot.
3 Apr
3 Apr
7:56 p.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
On 04/03/2013 11:42 AM, Yamaban wrote:
As long as there is a SLE(S|D) without systemd support
you are shooting
your own legs if you just "drop" all replaced sysVinit scripts.
SLE codebase has nothing to do with this.. SLE11 does not change unless
there is a security update or a service pack, which has very specfic,
delimited scope.
For systems with full systemd support (12.1 and
later), install
the scrips as %doc in the docdir for reference (and help).
init scripts are not documentation.
Before a drop could be considered (13.1 and following), there is more
maturing needed (intoduce a .service, and get it working without
troubles for a full release, e.g. a 'new' .service in 12.3 gets a
moved /etc/init.d/ script as %doc in 13.1 and so on.
sounds like an entangled mess..will make things worst, not better.
Are you trying to get the SLE support crew mad at you?
I dont give a flying f** about who gets mad. ;D
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
5 Apr
5 Apr
12:49 p.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
Yamaban wrote:
On Wed, 3 Apr 2013 09:20, Ludwig Nussel
<ludwig.nussel@...> wrote:
When I said 'keep the sysv scripts' I was referring to having
them installed in the system if %suse_version >= 1230. The package
maintainer is free to keep the scripts in the package sources and
install them only if the package is used as backport of course.
cu
Ludwig
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG
Nürnberg)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Stephan Kulow wrote:
As long as there is a SLE(S|D) without systemd support you are shooting
your own legs if you just "drop" all replaced sysVinit scripts. On 02.04.2013 10:06, Michal Kubecek wrote:
Well, the truth is that it doesn't make much sense anymore to keep
the sysv scripts if there is a service file. It only adds potential
code duplication and confusion. So I'd vote for having either
.service files or init scripts in a package but not both.
However, adding service files that break previous features or just
add the init script shell code 1:1 as ExecStartPre should be avoided
too. On Fri, Mar 29, 2013 at 11:29:22PM -0300,
Cristian Rodríguez wrote:
>
> Does anyone have access to a full unpacked tree of factory and can
> post what packages contain init scripts but not service files so I
> can take look at them ? there is no rpmlint check for that :-|
And not long ago I was being assured there won't be...
We agreed not to enforce that. So your fine to have a package with init
scripts. But it's perfectly fine also to have a rpmlint warning that
a package has *only* init script and Cristian adding systemd services
for them - if the maintainer of the package disagrees to add it, then
we can talk again. 
12:58 p.m.
New subject: [opensuse-packaging] Re: Creating of systemd service files instead of init scripts for new packages
On 04/05/2013 12:49 PM, Ludwig Nussel wrote:
When I said 'keep the sysv scripts' I was
referring to having
them installed in the system if %suse_version >= 1230. The package
maintainer is free to keep the scripts in the package sources and
install them only if the package is used as backport of course.
If there are both systemd.service and sysvinit file present my
understanding was if %suse_version >= 1230 then only systemd service
file and if %suse_version < 1230 then upto the packager but better to
include sysvinit in this case
Am I missing it
Togan
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
2 Apr
2 Apr
10:27 a.m.
On Tuesday, April 02, 2013 10:06:46 Michal Kubecek wrote:
On Fri, Mar 29, 2013 at 11:29:22PM -0300, Cristian
Rodríguez wrote:
You don't need to make it an error,
Andreas
--
Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Does anyone have access to a full unpacked tree
of factory and can
post what packages contain init scripts but not service files so I
can take look at them ? there is no rpmlint check for that :-|
And not long ago I was being assured there won't be... 
11:05 a.m.
Le mardi 02 avril 2013 à 10:27 +0200, Andreas Jaeger a écrit :
On Tuesday, April 02, 2013 10:06:46 Michal Kubecek
wrote:
The only case where it should be an error is "early boot" initscripts
(the one named boot.*). Support for that has been removed in upstream
systemd and I'd prefer to not backport the support in our systemd, if we
can avoid it..
--
Frederic Crozat <fcrozat(a)suse.com>
SUSE
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On Fri, Mar 29, 2013 at 11:29:22PM -0300,
Cristian Rodríguez wrote:
You don't need to make it an error, Does anyone have access to a full unpacked tree
of factory and can
post what packages contain init scripts but not service files so I
can take look at them ? there is no rpmlint check for that :-|
And not long ago I was being assured there won't be...
7:02 p.m.
El 02/04/13 06:05, Frederic Crozat escribió:
Support for that has been removed in upstream
systemd and I'd prefer to not backport the support
in our systemd, if we
can avoid it..
As far as I understand, all those boot.* scripts that are not already
masked, are replaced by upstream provided integration with systemd and
dracut.
We should just drop them and integrate upstream changes, however this
also implies getting rid of suse mkinitrd.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
3 Apr
3 Apr
10:04 a.m.
Le mardi 02 avril 2013 à 14:02 -0300, Cristian Rodríguez a écrit :
El 02/04/13 06:05, Frederic Crozat escribió:
Support for that has been removed in upstream
Well, I would still like to see dracut replacing mkinitrd..
--
Frederic Crozat <fcrozat(a)suse.com>
SUSE
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
systemd and I'd prefer to not backport the
support in our systemd, if we
can avoid it..
As far as I understand, all those boot.* scripts that are not already
masked, are replaced by upstream provided integration with systemd and
dracut.
We should just drop them and integrate upstream changes, however this
also implies getting rid of suse mkinitrd.
2 Apr
2 Apr
9:09 p.m.
Hello,
Am Dienstag, 2. April 2013 schrieb Frederic Crozat:
Le mardi 02 avril 2013 à 10:27 +0200, Andreas Jaeger a
écrit :
> On Tuesday, April 02, 2013 10:06:46 Michal Kubecek wrote:
> > On Fri, Mar 29, 2013 Cristian Rodríguez wrote:
> > > Does anyone have access to a full unpacked tree of factory and
> > > can post what packages contain init scripts but not service
> > > files so can take look at them ? there is no rpmlint check for
> > > that :-|
grepping ARCHIVES.gz might be helpful ;-)
(and it might be helpful to have an ARCHIVES.gz for factory)
The only case where it should be an error is
"early boot" initscripts
(the one named boot.*). Support for that has been removed in upstream
systemd
Nice[tm]. What's the reason for this? (I assume "let's break some
initscripts from stone age" was not the reason - I seriously hope
Lennart is not evil enough for that ;-)
and I'd prefer to not backport the support in our
systemd, if
we can avoid it..
At the moment you'll break lots of packages and, more important,
break lots of basic features like RAID and LVM.
I'll give you a short overview from my system (Factory, last updated
about 3 weeks ago):
# cd /etc/init.d && for file in boot.* ; do echo === $file ===; pac=$(rpm -qf
$file); echo Package: $pac; rpm -ql $pac |grep '\.service$'; echo; done
=== boot.apparmor ===
Package: apparmor-parser-2.8.1-130.1.x86_64
=== boot.cycle ===
Package: bootcycle-0.3-244.1.x86_64
=== boot.d ===
Package: filesystem-12.3-11.1.x86_64
=== boot.device-mapper ===
Package: device-mapper-1.02.77-22.1.x86_64
=== boot.dmraid ===
Package: dmraid-1.0.0.rc16-23.1.x86_64
=== boot.kdump ===
Package: kdump-0.8.1-21.1.x86_64
=== boot.loadmodules ===
Package: mkinitrd-2.7.2-5.7.x86_64
/usr/lib/systemd/system/purge-kernels.service # doesn't count ;-)
=== boot.local ===
Package: file /etc/init.d/boot.local is not owned by any package # but should continue
to work ;-)
=== boot.localnet ===
Package: aaa_base-12.3-17.1.x86_64
=== boot.lvm ===
Package: lvm2-2.02.98-22.1.x86_64
=== boot.md ===
Package: mdadm-3.2.6-0.x86_64
=== boot.scpm ===
Package: scpm-1.1.7-21.1.x86_64
=== boot.sysstat ===
Package: sysstat-10.0.5-7.1.x86_64
/usr/lib/systemd/system/sysstat.service
=== boot.udev ===
Package: udev-195-24.1.x86_64
/usr/lib/systemd/system/basic.target.wants/systemd-udev-root-symlink.service
/usr/lib/systemd/system/sysinit.target.wants/systemd-udev-trigger.service
/usr/lib/systemd/system/sysinit.target.wants/systemd-udevd.service
/usr/lib/systemd/system/systemd-udev-root-symlink.service
/usr/lib/systemd/system/systemd-udev-settle.service
/usr/lib/systemd/system/systemd-udev-trigger.service
/usr/lib/systemd/system/systemd-udevd.service
/usr/lib/systemd/system/udev.service
In other words: from the 14 packages owning boot.* initscripts on my
system, only 2 have service files.
I'm sure the maintainers of the other 12 will happily accept submit
requests that add the service file and do the migration in %post ;-)
Note that I didn't write anything about "remove the initscript" - for
AppArmor, I'd like to keep it for backwards compability with older
openSUSE releases. Other maintainers might or might not have similar
wishes.
BTW: is ExecStatus supported in the meantime?
(Needless to say that updating systemd is a no-go until all affected
packages have a service file.)
Regards,
Christian Boltz
--
Doh, bad Steve, no donut! [...]
That's what I got for copy&wasting from a diff.
[Steve Beattie in apparmor]
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
3 Apr
3 Apr
1:05 a.m.
El 02/04/13 16:09, Christian Boltz escribió:
Nice[tm]. What's the reason for this? (I assume
"let's break some
initscripts from stone age" was not the reason - I seriously hope
Lennart is not evil enough for that ;-)
Early boot scripts were a distribution specific extension of sysvinit,
hence everybody does it differently.
To be more specific than Frederic, systemd no longer includes any
distribution-specific code, all distributions targets (in our case
TARGET_SUSE) are gone.
At the moment you'll break lots of packages and,
more important,
break lots of basic features like RAID and LVM.
RAID and LVM already have systemd support upstream, to make it work,
last time I checked it required dracut.
# cd /etc/init.d && for file in boot.* ; do
echo === $file ===; pac=$(rpm -qf $file); echo Package: $pac; rpm -ql $pac |grep
'\.service$'; echo; done
=== boot.cycle ===
Package: bootcycle-0.3-244.1.x86_64
Not sure if that still works, the package consist of just an init script
and instructions for GRUB legacy that is no longer even installed by
default..
=== boot.d ===
Package: filesystem-12.3-11.1.x86_64
Unused.
=== boot.device-mapper ===
Package: device-mapper-1.02.77-22.1.x86_64
=== boot.dmraid ===
Package: dmraid-1.0.0.rc16-23.1.x86_64
Supported with systemd/dracut
=== boot.kdump ===
Package: kdump-0.8.1-21.1.x86_64
=== boot.loadmodules ===
Already sent a patch to replace it.
http://lists.opensuse.org/opensuse-kernel/2013-03/msg00016.html
Not merged yet :-( another reason to use dracut.
Package: mkinitrd-2.7.2-5.7.x86_64
/usr/lib/systemd/system/purge-kernels.service # doesn't count ;-)
=== boot.local ===
Package: file /etc/init.d/boot.local is not owned by any package # but should continue
to work ;-)
Could replace that by a generator, or just call it "local.service".. ;)
=== boot.localnet ===
Package: aaa_base-12.3-17.1.x86_64
masked, I already sent a patch to remove it which was merged.
=== boot.lvm ===
Package: lvm2-2.02.98-22.1.x86_64
=== boot.md ===
Package: mdadm-3.2.6-0.x86_64
Supported with systemd/dracut.
=== boot.scpm ===
Package: scpm-1.1.7-21.1.x86_64
No idea.
=== boot.sysstat ===
Package: sysstat-10.0.5-7.1.x86_64
/usr/lib/systemd/system/sysstat.service
already migrated.
=== boot.udev ===
Unused,
Note that I didn't write anything about
"remove the initscript" - for
AppArmor, I'd like to keep it for backwards compability with older
openSUSE releases. Other maintainers might or might not have similar
wishes.
BTW: is ExecStatus supported in the meantime?
selinux and smack LSMs have native support merged in systemd (by the
authors, Redhat and people from Intel respectively) kinda telling that
apparmor doesn't...:-|
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
9:26 a.m.
Cristian Rodríguez wrote:
El 02/04/13 16:09, Christian Boltz escribió:
What exactly is dracut needed for there? Or to put it the other way
around what's missing from mkinitrd?
cu
Ludwig
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG
Nürnberg)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
At the moment you'll break lots of packages
and, more important,
break lots of basic features like RAID and LVM.
RAID and LVM already have systemd support upstream, to make it work,
last time I checked it required dracut.
9:35 a.m.
On 03.04.2013 09:26, Ludwig Nussel wrote:
Cristian Rodríguez wrote:
A maintainer. I for one would like to see us switching to dracut yesterday.
Greetings, Stephan
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
El 02/04/13 16:09, Christian Boltz escribió:
What exactly is dracut needed for there? Or to put it the other way
around what's missing from mkinitrd? At the moment you'll break lots of packages
and, more important,
break lots of basic features like RAID and LVM.
RAID and LVM already have systemd support upstream, to make it work,
last time I checked it required dracut.
10:13 a.m.
On Wed, Apr 3, 2013 at 11:35 AM, Stephan Kulow <coolo(a)suse.de> wrote:
On 03.04.2013 09:26, Ludwig Nussel wrote:
I'm not sure I understand, what lacks maintainer - mkinitrd or dracut?
In case of dracut I'd tentatively volunteer to (co-)maintain it.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Cristian Rodríguez wrote:
A maintainer. I for one would like to see us switching to dracut yesterday.
El 02/04/13 16:09, Christian Boltz escribió:
What exactly is dracut needed for there? Or to put it the other way
around what's missing from mkinitrd? At the moment you'll break lots of packages
and, more important,
break lots of basic features like RAID and LVM.
RAID and LVM already have systemd support upstream, to make it work,
last time I checked it required dracut.
10:18 a.m.
Le mercredi 03 avril 2013 à 12:13 +0400, Andrey Borzenkov a écrit :
On Wed, Apr 3, 2013 at 11:35 AM, Stephan Kulow
<coolo(a)suse.de> wrote:
For mkinitrd (both package and sources).
--
Frederic Crozat <fcrozat(a)suse.com>
SUSE
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On 03.04.2013 09:26, Ludwig Nussel wrote:
I'm not sure I understand, what lacks maintainer - mkinitrd or dracut?
In case of dracut I'd tentatively volunteer to (co-)maintain it. Cristian Rodríguez wrote:
A maintainer. I for one would like to see us switching to dracut yesterday.
El 02/04/13 16:09, Christian Boltz escribió:
> At the moment you'll break lots of packages and, more important,
> break lots of basic features like RAID and LVM.
RAID and LVM already have systemd support upstream, to make it work,
last time I checked it required dracut.
What exactly is dracut needed for there? Or to put it the other way
around what's missing from mkinitrd? 
11:34 a.m.
On Wednesday 03 April 2013 12:13:50 Andrey Borzenkov wrote:
I'm not sure I understand, what lacks maintainer - mkinitrd or dracut?
In case of dracut I'd tentatively volunteer to (co-)maintain it.
Hi Andrey,
As Frederic already indicated mkinitrd seems to be the one missing the
maintainership. However we would welcome any help we can get to really exploit
dracut and to have it replace mkinitrd in openSUSE 13.1.
The main devel package is in the Base:System repository and currently
Christian Rodriguez and I are maintaining it. A couple of months ago I took it
upon me to get dracut into openSUSE, but unfortunately due to an work overload
at my normal job, I am not able to spend that much time on it.
We are tracking the releases and the package is in openSUSE Factory. I guess
the main thing to do is to validate if all angles are covered when using
dracut to generate the inird instead of mkinitrd. This would be specifically
with LUKS/crypt support.
Another topic would be not to increase the size of the initrd and to get the
right default settings for dracut. These can then be integrated in the other
packages that are currently calling mkinitrd.
So still some work to do, but in general things should work out-of-the-box.
Regards
Raymond
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
What exactly is dracut needed for there? Or to put it
the other way
around what's missing from mkinitrd?
A maintainer. I for one would like to see us switching to dracut
yesterday. 
3:19 p.m.
On Wed, Apr 3, 2013 at 4:34 AM, Raymond Wooninck <tittiatcoke(a)gmail.com> wrote:
On Wednesday 03 April 2013 12:13:50 Andrey Borzenkov
wrote:
I'm not sure I understand, what lacks maintainer - mkinitrd or dracut?
In case of dracut I'd tentatively volunteer to (co-)maintain it.
Hi Andrey,
As Frederic already indicated mkinitrd seems to be the one missing the
maintainership. However we would welcome any help we can get to really exploit
dracut and to have it replace mkinitrd in openSUSE 13.1.
The main devel package is in the Base:System repository and currently
Christian Rodriguez and I are maintaining it. A couple of months ago I took it
upon me to get dracut into openSUSE, but unfortunately due to an work overload
at my normal job, I am not able to spend that much time on it.
We are tracking the releases and the package is in openSUSE Factory. I guess
the main thing to do is to validate if all angles are covered when using
dracut to generate the inird instead of mkinitrd. This would be specifically
with LUKS/crypt support.
I use LUKS for root and - while it took me a few tries - I do have a
working system that boots just fine with either dracut or
mkinitrd-built initrds.
The key for me was that I had to refer to the (very good!) Fedora
documentation to add:
rd.auto
to the kernel/initrd commandline. I still can't get dracut to decrypt
my swap partition.
I am interested in helping out with a transition to dracut.
Besides testing, what might be the best way for me to contribute?
--
Jon
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
What exactly is dracut needed for there? Or to put it
the other way
around what's missing from mkinitrd?
A maintainer. I for one would like to see us switching to dracut
yesterday.
3:27 p.m.
Le mercredi 03 avril 2013 à 08:19 -0500, Jon Nelson a écrit :
On Wed, Apr 3, 2013 at 4:34 AM, Raymond Wooninck
<tittiatcoke(a)gmail.com> wrote:
Hmm, I haven't dig into dracut for sometime but you shouldn't have to do
that (or something is wrong). Please open a bug report.
On Wednesday 03 April 2013 12:13:50 Andrey
Borzenkov wrote:
Hi Andrey,
As Frederic already indicated mkinitrd seems to be the one missing the
maintainership. However we would welcome any help we can get to really exploit
dracut and to have it replace mkinitrd in openSUSE 13.1.
The main devel package is in the Base:System repository and currently
Christian Rodriguez and I are maintaining it. A couple of months ago I took it
upon me to get dracut into openSUSE, but unfortunately due to an work overload
at my normal job, I am not able to spend that much time on it.
We are tracking the releases and the package is in openSUSE Factory. I guess
the main thing to do is to validate if all angles are covered when using
dracut to generate the inird instead of mkinitrd. This would be specifically
with LUKS/crypt support.
I use LUKS for root and - while it took me a few tries - I do have a
working system that boots just fine with either dracut or
mkinitrd-built initrds.
The key for me was that I had to refer to the (very good!) Fedora
documentation to add:
rd.auto
to the kernel/initrd commandline. > What
exactly is dracut needed for there? Or to put it the other way
> around what's missing from mkinitrd?
A maintainer. I for one would like to see us switching to dracut
yesterday.
I'm not sure I understand, what lacks maintainer - mkinitrd or dracut?
In case of dracut I'd tentatively volunteer to (co-)maintain it. I still can't get dracut to decrypt
my swap partition.
Same, open a bug report.
I am interested in helping out with a transition to
dracut.
Besides testing, what might be the best way for me to contribute?
I suggest to either use this mailing list or -factory mailing. If you
find something broken, open a bug report, notify folks here and if you
want to help fixing, indicate it in the bug report.
I would also suggest, if you can, to use irc channel on Freenode,
#opensuse-factory and #dracut
(For folks interested, I'll probably work on dracut as my hackweek
project next week, to help polish it so it could replace mkinitrd and
also switch its internal to systemd).
--
Frederic Crozat <fcrozat(a)suse.com>
SUSE
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
6:30 p.m.
В Wed, 3 Apr 2013 08:19:00 -0500
Jon Nelson <jnelson-suse(a)jamponi.net> пишет:
May be I miss something obvious but I recently did several test
installations on LVM on encrypted container and did not have a single
issue except lack of out-of-the box support in grub2 (it is a single
parameter in /etc/default/grub). But it was definitely *not* a problem
in initrd or boot.crypto. And if you use separate /boot (which
installer forces anyway) then it works out of the box using vanilla
installer.
So may someone explain what are these problems with crypto mentioned
here?
I could imagine problem with additional file systems but then it is out
of scope for mkinitrd/dracut.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
We are tracking the releases and the package is in openSUSE Factory. I guess
the main thing to do is to validate if all angles are covered when using
dracut to generate the inird instead of mkinitrd. This would be specifically
with LUKS/crypt support.
I use LUKS for root and - while it took me a few tries - I do have a
working system that boots just fine with either dracut or
mkinitrd-built initrds.
5 Apr
5 Apr
1:20 p.m.
Stephan Kulow wrote:
On 03.04.2013 09:26, Ludwig Nussel wrote:
That's the information that was missing so far. At least it wasn't
obvious to me. From a technical PoV I don't see the superiority of
dracut. It looks like just another flavor of the same shell script
mess. So by switching to dracut right now we would not switch to some
next generation initrd that can to things in smarter ways.
I'm reluctant to waste time dealing with things like e.g.
modules.d/90crypt/cryptroot-ask.sh. That feels like boot.crypto which
was rightfully killed by systemd raising from the dead.
cu
Ludwig
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG
Nürnberg)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Cristian Rodríguez wrote:
A maintainer. El 02/04/13 16:09, Christian Boltz escribió:
What exactly is dracut needed for there? Or to put it the other way
around what's missing from mkinitrd? At the moment you'll break lots of packages
and, more important,
break lots of basic features like RAID and LVM.
RAID and LVM already have systemd support upstream, to make it work,
last time I checked it required dracut.
1:42 p.m.
В Fri, 05 Apr 2013 13:20:54 +0200
Ludwig Nussel <ludwig.nussel(a)suse.de> пишет:
That's the information that was missing so far. At least it wasn't
obvious to me. From a technical PoV I don't see the superiority of
dracut. It looks like just another flavor of the same shell script
mess. So by switching to dracut right now we would not switch to some
next generation initrd that can to things in smarter ways.
dracut is being actively developed and is targeting toward full
systemd integration. Having systemd in initrd sounds like being close
to next generation to me.
I'm reluctant to waste time dealing with things
like e.g.
modules.d/90crypt/cryptroot-ask.sh. That feels like boot.crypto which
was rightfully killed by systemd raising from the dead.
At some point you will have several systemd-cryptsetup services
instead. Like this happened in booted OS now.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
1:45 p.m.
On 05.04.2013 13:20, Ludwig Nussel wrote:
Stephan Kulow wrote:
That's why dracut maintainers are working on integrating systemd into
initrd - and mkinitrd maintainers are not.
Greetings, Stephan
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On 03.04.2013 09:26, Ludwig Nussel wrote:
That's the information that was missing so far. At least it wasn't
obvious to me. From a technical PoV I don't see the superiority of
dracut. It looks like just another flavor of the same shell script
mess. So by switching to dracut right now we would not switch to some
next generation initrd that can to things in smarter ways.
I'm reluctant to waste time dealing with things like e.g.
modules.d/90crypt/cryptroot-ask.sh. That feels like boot.crypto which
was rightfully killed by systemd raising from the dead.
Cristian Rodríguez wrote:
A maintainer. El 02/04/13 16:09, Christian Boltz escribió:
> At the moment you'll break lots of packages and, more important,
> break lots of basic features like RAID and LVM.
RAID and LVM already have systemd support upstream, to make it work,
last time I checked it required dracut.
What exactly is dracut needed for there? Or to put it the other way
around what's missing from mkinitrd?
3 Apr
3 Apr
9:42 a.m.
On 04/03/2013 04:26 AM, Ludwig Nussel wrote:
Cristian Rodríguez wrote:
Technically I would have to take a look more deeply to figure out
exactly what. however.. what I know is that a bunch a people worked
together making it work and took all upstream. thing that..well.we never
did.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
El 02/04/13 16:09, Christian Boltz escribió:
What exactly is dracut needed for there? Or to put it the other way
around what's missing from mkinitrd? At the moment you'll break lots of packages
and, more important,
break lots of basic features like RAID and LVM.
RAID and LVM already have systemd support upstream, to make it work,
last time I checked it required dracut.
9:47 a.m.
On 04/03/2013 04:42 AM, Cristian Rodríguez wrote:
what I know is that a bunch a people worked
together making it work and took all upstream. thing that..well.we never
did.
Of course this people did it for reason, they need it for for RHEL 7 ;)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
8:29 p.m.
Hello,
Am Dienstag, 2. April 2013 schrieb Cristian Rodríguez:
... and dracut is not working on openSUSE yet if I understan the other
mails correctly.
In other words: At the moment, RAID and LVM will _not_ work without the
boot.* initscripts.
Reading the mails in opensuse-kernel, the migration will depend on the
mkinitrd package. If we switch to dracut, you should also add it to
another package that is actually installed ;-) (for example dracut or
kernel-*)
As long as it works, I don't really care about the method ;-)
BTW: There might be more boot.* initscripts - my mail only listed those
installed on my system. ARCHIVES.gz will probably give you a longer
list.
[...]
You most probably know that most of the AppArmor development is done by
Ubuntu developers nowadays. [1]
Yes, that's the distribution with upstart. Not too surprising that they
don't care about systemd, right?
That said: writing an apparmor.service file shouldn't be too hard, but
at the moment I don't really have time to do it.
BTW: do the RPM macros for migration to *.service also work with boot.*
initscripts? I had a look at /usr/sbin/systemd-sysv-convert, and I
somehow doubt. It seems to check /etc/rc.d/rc*.d/ only, but not
/etc/rc.d/boot.d/...
Talking about /usr/sbin/systemd-sysv-convert - even --help is buggy:
cat << EOF
Save and Restore SusV Service Runlevel Information
^
;-)
Regards,
Christian Boltz
[1] I'm also doing some work upstream, but that's mostly updating
profiles and sometimes fixing some scripts. I also take part in
discussions about future development, but you don't want me to
write C code ;-) [2]
[2] if I ever write or edit C code, I strongly recommend to confine it
with AppArmor *g*
--
what does "> /dev/null" mean?
and how do i reverse it?
would "< /dev/null" be right?
[aus comp.unix.shell]
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
El 02/04/13 16:09, Christian Boltz escribió:
That still sums up to "let's break some initscripts from stone age".
Seems like I have to add "on multiple distributions, so that everybody
gets hurt".
Again: Is there a (technical) reason to remove the distro-specific code?
I start to think Lennart reads too many BOfH stories... :-(
Nice[tm]. What's the reason for this? (I
assume "let's break some
initscripts from stone age" was not the reason - I seriously hope
Lennart is not evil enough for that ;-)
Early boot scripts were a distribution specific extension of sysvinit,
hence everybody does it differently.
To be more specific than Frederic, systemd no longer includes any
distribution-specific code, all distributions targets (in our case
TARGET_SUSE) are gone. At the moment
you'll break lots of packages and, more important,
break lots of basic features like RAID and LVM.
RAID and LVM already have systemd support upstream, to make it work,
last time I checked it required dracut. ===
boot.loadmodules ===
Already sent a patch to replace it.
http://lists.opensuse.org/opensuse-kernel/2013-03/msg00016.html
Not merged yet :-( another reason to use dracut. === boot.local
===
Package: file /etc/init.d/boot.local is not owned by any package #
but should continue to work ;-)
Could replace that by a generator, or just call it
"local.service"..
;) Note that I
didn't write anything about "remove the initscript" -
for
AppArmor, I'd like to keep it for backwards compability with older
openSUSE releases. Other maintainers might or might not have similar
wishes.
BTW: is ExecStatus supported in the meantime?
selinux and smack LSMs have native support merged in systemd (by the
authors, Redhat and people from Intel respectively) kinda telling that
apparmor doesn't...:-|
9:23 p.m.
El 03/04/13 15:29, Christian Boltz escribió:
... and dracut is not working on openSUSE yet if I understan the other
mails correctly.
Yes, dracut works, what needs update is LVM and RAID ( update in the
sense of "pull from upstream and test" )
Again: Is there a (technical) reason to remove the
distro-specific code?
Yes, distribution specific code has to live in distributions trees.. not
upstream.
Most, if not all, this "distribution specific" code have generic
upstream replacements and we want to use them instead.
At the moment you'll break lots of packages and,
more important,
break lots of basic features like RAID and LVM.
RAID and LVM already have systemd support upstream, to make it work,
last time I checked it required dracut.
In other words: At the moment, RAID and LVM will _not_ work without the
boot.* initscripts.
Yes, in the current state of things that's correct.
Reading the mails in opensuse-kernel, the migration
will depend on the
mkinitrd package. If we switch to dracut, you should also add it to
another package that is actually installed ;-) (for example dracut or
kernel-*)
It can be accomodated elsewhere but ideally mkinitrd should close the
door and turn the lights off on exit.
>> Note that I didn't write anything about
"remove the initscript" -
>> for
>> AppArmor, I'd like to keep it for backwards compability with older
>> openSUSE releases. Other maintainers might or might not have similar
>> wishes.
Just add a conditional %{suse_version} < ... then
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
10:07 a.m.
Le mardi 02 avril 2013 à 21:09 +0200, Christian Boltz a écrit :
BTW: is ExecStatus supported in the meantime?
No.
I remember some systemd folks had idea to implement it but it isn't very
high on their TODO list.
(Needless to say that updating systemd is a no-go
until all affected
packages have a service file.)
You better hurry then, I'd like to update systemd next week in
Factory ;)
--
Frederic Crozat <fcrozat(a)suse.com>
SUSE
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
8:33 p.m.
Hello,
Am Mittwoch, 3. April 2013 schrieb Frederic Crozat:
Le mardi 02 avril 2013 à 21:09 +0200, Christian Boltz
a écrit :
If I understand the other mails right, RAID and LVM would require dracut
to work without their boot.* initscript, and dracut is not ready yet in
openSUSE.
This sums up to the following options:
a) break booting of all systems using RAID and/or LVM [1] by submitting
the new systemd package
b) first make sure RAID and LVM works without the boot.* initscript, and
_after_ that is done, submit the new systemd package
I'd strongly recommend to avoid method a) ;-)
Regards,
Christian Boltz
[1] and maybe other critical parts I didn't notice yet
--
Aussage eines Mathematikprofessors von mir: 'Die Informatiker, das sind
die, die dann am Bahnsteig stehen, und ihre Koffer zählen - 0, 1, 2 -
Mist, wo ist der dritte Koffer?' [Adalbert Michelic in suse-linux]
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
(Needless to say that updating systemd is a no-go
until all affected
packages have a service file.)
You better hurry then, I'd like to update systemd next week in
Factory ;)
1:55 p.m.
I've added now at
https://en.opensuse.org/openSUSE:Packaging_guidelines#Init_scripts the
following:
Since openSUSE 12.3 has switched completely to systemd, no more new
SysV-style init scripts should be written. Existing init scripts should
be replaced with systemd service files and new packages should get only
systemd service files.
Andreas
--
Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
2:01 p.m.
On Wed 03 Apr 2013 13:55:33 Andreas Jaeger wrote:
I've added now at
https://en.opensuse.org/openSUSE:Packaging_guidelines#Init_scripts the
following:
Andreas maybe a simple example of how to convert a simple init script to
a
systemd service might be useful.
Alin
--
Without Questions there are no Answers!
______________________________________________________________________
Alin Marin ELENA
Advanced Molecular Simulation Research Laboratory
School of Physics, University College Dublin
----
Ardionsamblú Móilíneach Saotharlann Taighde
Scoil na Fisice, An Coláiste Ollscoile, Baile Átha Cliath
______________________________________________________________________
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
2:07 p.m.
On Wed, Apr 3, 2013 at 4:01 PM, Alin M Elena <alinm.elena(a)gmail.com> wrote:
On Wed 03 Apr 2013 13:55:33 Andreas Jaeger wrote:
http://0pointer.de/blog/projects/systemd-for-admins-3.html
Or is there anything more (open)SUSE specific?
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
I've added now at
https://en.opensuse.org/openSUSE:Packaging_guidelines#Init_scripts the
following:
Andreas maybe a simple example of how to convert a simple init script
to a
systemd service might be useful.
2:12 p.m.
nothing opensuse specific... just convenience... and you do not need
the user to google all over to find something which is usually pretty
trivial...
Alin
Without Questions there are no Answers!
______________________________________________________________________
Alin Marin ELENA
Advanced Molecular Simulation Research Laboratory
School of Physics, University College Dublin
----
Ardionsamblú Móilíneach Saotharlann Taighde
Scoil na Fisice, An Coláiste Ollscoile, Baile Átha Cliath
______________________________________________________________________
On 3 April 2013 13:07, Andrey Borzenkov <arvidjaar(a)gmail.com> wrote:
On Wed, Apr 3, 2013 at 4:01 PM, Alin M Elena
<alinm.elena(a)gmail.com> wrote:
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On Wed 03 Apr 2013 13:55:33 Andreas Jaeger
wrote:
http://0pointer.de/blog/projects/systemd-for-admins-3.html
Or is there anything more (open)SUSE specific?
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
I've added now at
https://en.opensuse.org/openSUSE:Packaging_guidelines#Init_scripts the
following:
Andreas maybe a simple example of how to convert a simple init script
to a
systemd service might be useful.
2:18 p.m.
Le mercredi 03 avril 2013 à 16:07 +0400, Andrey Borzenkov a écrit :
On Wed, Apr 3, 2013 at 4:01 PM, Alin M Elena
<alinm.elena(a)gmail.com> wrote:
No, fortunately, except maybe the RPM macros (which were written before
systemd had its own set of macros and unfortunately, they diverge a
bit ; I'll see if I can merge all of them in Factory).
Everything is explained at
http://en.opensuse.org/openSUSE:Systemd_packaging_guidelines
--
Frederic Crozat <fcrozat(a)suse.com>
SUSE
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On Wed 03 Apr 2013 13:55:33 Andreas Jaeger
wrote:
http://0pointer.de/blog/projects/systemd-for-admins-3.html
Or is there anything more (open)SUSE specific? I've added now at
https://en.opensuse.org/openSUSE:Packaging_guidelines#Init_scripts the
following:
Andreas maybe a simple example of how to convert a simple init script
to a
systemd service might be useful.
7:48 p.m.
On 04/03/2013 09:07 AM, Andrey Borzenkov wrote:
Or is there anything more (open)SUSE specific?
No. there is (and really shouln't be) nothing opensuse-specific other
than the rpm spec macros..
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
4 Apr
4 Apr
8:24 a.m.
Le mercredi 03 avril 2013 à 14:48 -0300, Cristian Rodríguez a écrit :
On 04/03/2013 09:07 AM, Andrey Borzenkov wrote:
And I plan to merge the "upstream" RPM macros in Factory to make sure
both our openSUSE specific one and "upstream" one do the same thing.
--
Frederic Crozat <fcrozat(a)suse.com>
SUSE
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Or is there anything more (open)SUSE specific?
No. there is (and really shouln't be) nothing opensuse-specific other
than the rpm spec macros..
2:19 a.m.
El 03/04/13 09:01, Alin M Elena escribió:
On Wed 03 Apr 2013 13:55:33 Andreas Jaeger wrote:
There is plenty of documentation how to do this, there is even a photo
circulating on the internet with a printed manual filling TWO TOMES :-D
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
I've added now at
https://en.opensuse.org/openSUSE:Packaging_guidelines#Init_scripts the
following:
Andreas maybe a simple example of how to convert a simple init script
to a
systemd service might be useful. 
11:18 a.m.
Hello,
On Apr 3 21:19 Cristian Rodríguez wrote:
El 03/04/13 09:01, Alin M Elena escribió:
I do not understand such kind of answers.
What was wrong with the question that Alin M Elena
does not get a useful answer?
E.g. an appropriate URL where the requested information is.
Or perhaps someone who knows such an URL might even add it to
https://en.opensuse.org/openSUSE:Packaging_guidelines#Init_scripts
so that others who read that could also directly access the
right information without using random stuff from the Internet.
Regards
Johannes Meixner
--
SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany
HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer
On Wed 03 Apr 2013 13:55:33 Andreas Jaeger
wrote:
There is plenty of documentation how to do this, there is even a photo
circulating on the internet with a printed manual filling TWO TOMES :-D I've added now at
https://en.opensuse.org/openSUSE:Packaging_guidelines#Init_scripts the
following:
Andreas maybe a simple example of how to convert a simple init script
to a systemd service might be useful. 
5 Apr
5 Apr
11:08 a.m.
On 03/29/2013 06:43 PM, Andreas Jaeger wrote:
Since we moved to systemd completely, I suggest that
newly added files
will contain service files - and not init scripts anymore.
So, please only add service files to new packages and if you change your
init file, consider using a service file and dropping the init file,
Andreas
I'm to lazy to read this exploding thread so please explain how I am
supposed to package for openSUSE and SLE at the same time? I already got
a declined sr because of that and I fail to see the review team
discussion for that.
Also, I see people going crazy dropping init scripts for now reason.
While it is true that openSUSE packagers should not care for SLE in
general, they could care for the distros that are still in maintenance.
Many (devel) projects provide packages for 12.1 even and there you have
good reason to keep init scripts around.
How about a concrete example, I'm currently preparing chef-11 (the
Erlang one) and want to submit it to Factory. My SUSE employee alter ego
does that because we're going to make use of it in the SLE context. My
openSUSE community member alter ego follows an upstream first policy, so
I want it to be part of openSUSE (and thus Factory). However, even
though I'm a big advocate of systemd, I couldn't care less for a service
file ATM.
So it's either chef-11 for Factory w/o service file or I would have to
move to IBS and then there's no chef-11.
--
With kind regards,
Sascha Peilicke
SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
11:30 a.m.
On 04/05/2013 11:08 AM, Sascha Peilicke wrote:
On 03/29/2013 06:43 PM, Andreas Jaeger wrote:
In this case, you could add both init file and service file - or explain
what you're doing with the submission, and I would be ok with it.
I don't see this guideline as a law but as guidance. So, let's talk
about exceptions. And if you have a suggestion for a better wording then
please propose one.
Andreas
--
Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Since we moved to systemd completely, I suggest
that newly added files
will contain service files - and not init scripts anymore.
So, please only add service files to new packages and if you change your
init file, consider using a service file and dropping the init file,
Andreas
I'm to lazy to read this exploding thread so please explain how I am
supposed to package for openSUSE and SLE at the same time? I already got
a declined sr because of that and I fail to see the review team
discussion for that.
Also, I see people going crazy dropping init scripts for now reason.
While it is true that openSUSE packagers should not care for SLE in
general, they could care for the distros that are still in maintenance.
Many (devel) projects provide packages for 12.1 even and there you have
good reason to keep init scripts around.
How about a concrete example, I'm currently preparing chef-11 (the
Erlang one) and want to submit it to Factory. My SUSE employee alter ego
does that because we're going to make use of it in the SLE context. My
openSUSE community member alter ego follows an upstream first policy, so
I want it to be part of openSUSE (and thus Factory). However, even
though I'm a big advocate of systemd, I couldn't care less for a service
file ATM.
So it's either chef-11 for Factory w/o service file or I would have to
move to IBS and then there's no chef-11.
1:33 p.m.
On 04/05/2013 11:30 AM, Andreas Jaeger wrote:
On 04/05/2013 11:08 AM, Sascha Peilicke wrote:
Unfortunately I don't have the desire to spend time on that. I'm more
than happy if someone wants to contribute service files (in general and
my particular example).
On 03/29/2013 06:43 PM, Andreas Jaeger wrote:
In this case, you could add both init file and service file - or explain
what you're doing with the submission, and I would be ok with it Since we moved to systemd completely, I suggest
that newly added files
will contain service files - and not init scripts anymore.
So, please only add service files to new packages and if you change your
init file, consider using a service file and dropping the init file,
Andreas
I'm to lazy to read this exploding thread so please explain how I am
supposed to package for openSUSE and SLE at the same time? I already got
a declined sr because of that and I fail to see the review team
discussion for that.
Also, I see people going crazy dropping init scripts for now reason.
While it is true that openSUSE packagers should not care for SLE in
general, they could care for the distros that are still in maintenance.
Many (devel) projects provide packages for 12.1 even and there you have
good reason to keep init scripts around.
How about a concrete example, I'm currently preparing chef-11 (the
Erlang one) and want to submit it to Factory. My SUSE employee alter ego
does that because we're going to make use of it in the SLE context. My
openSUSE community member alter ego follows an upstream first policy, so
I want it to be part of openSUSE (and thus Factory). However, even
though I'm a big advocate of systemd, I couldn't care less for a service
file ATM.
So it's either chef-11 for Factory w/o service file or I would have to
move to IBS and then there's no chef-11. I don't see this guideline as a law but as
guidance. So, let's talk
about exceptions. And if you have a suggestion for a better wording then
please propose one.
Then reviews should not be declined based upon this guideline.
--
With kind regards,
Sascha Peilicke
SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
8 Apr
8 Apr
3:20 p.m.
After some discussion with Sascha, we agreed that we have the following
goals:
* Moving to only systemd service files (while still supporting SysV init
service files)
* Supporting building with SLE 11 which comes with SysV init
* The rcXXX script should continue to work with systemd
The first goal is not a hard goal.
So, we suggest to change the guideline to accomodate this better:
* If there is both an init file and a service file, install for openSUSE
12.3 and newer only the service file.
* If the package is needed for SLE 11, you need at least a SysV init file
* If you only support a service file, link rcXXX to /sbin/service so that
rcXXX continues to work
* If you submit a new package, consider your audience: Create a new
service file for openSUSE 12.3 and newer - or a SysV init file for SLE 11.
You can (continue to) use the SysV init file for openSUSE, if you want -
but consider adding a new service file, these are really easy to write.
Sascha & Andreas
--
Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
6:08 p.m.
On Mon, Apr 08, 2013 at 03:20:19PM +0200, Andreas Jaeger wrote:
After some discussion with Sascha, we agreed that we
have the following
goals:
* Moving to only systemd service files (while still supporting SysV init
service files)
* Supporting building with SLE 11 which comes with SysV init
* The rcXXX script should continue to work with systemd
Hi,
can we have the rcXXX rpmlint error for that? I'm not sure how much
systemd-only packages do we have atm and how many of them links
/sbin/service in this case.
The first goal is not a hard goal.
So, we suggest to change the guideline to accomodate this better:
* If there is both an init file and a service file, install for openSUSE
12.3 and newer only the service file.
rpmlint error would be great as well
* If the package is needed for SLE 11, you need at
least a SysV init file
* If you only support a service file, link rcXXX to /sbin/service so that
rcXXX continues to work
* If you submit a new package, consider your audience: Create a new
service file for openSUSE 12.3 and newer - or a SysV init file for SLE 11.
You can (continue to) use the SysV init file for openSUSE, if you want -
but consider adding a new service file, these are really easy to write.
Last two sentences imho try to say the old "no new init scripts in
Factory" rule using more void words. Or am I wrong?
Regards
Michal Vyskocil
6:23 p.m.
On 04/08/2013 01:08 PM, Michal Vyskocil wrote:
On Mon, Apr 08, 2013 at 03:20:19PM +0200, Andreas
Jaeger wrote:
rcXXX is a foreign concept not part of systemd , therefore there should
be no expectative whatsoever about it working with systemd, even less an
rpmlint error in place.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
After some discussion with Sascha, we agreed that
we have the following
goals:
* Moving to only systemd service files (while still supporting SysV init
service files)
* Supporting building with SLE 11 which comes with SysV init
* The rcXXX script should continue to work with systemd
Hi,
can we have the rcXXX rpmlint error for that? I'm not sure how much
systemd-only packages do we have atm and how many of them links
/sbin/service in this case.
6:40 p.m.
Le lundi 08 avril 2013 à 13:23 -0300, Cristian Rodríguez a écrit :
On 04/08/2013 01:08 PM, Michal Vyskocil wrote:
But it is an expectation from our users (openSUSE and SLE). We worked
hard to make transition to systemd as smooth as possible and making sure
rcXXX still works is part of that. We shouldn't drop it.
--
Frederic Crozat <fcrozat(a)suse.com>
SUSE
--
Frederic Crozat <fcrozat(a)suse.com>
SUSE
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On Mon, Apr 08, 2013 at 03:20:19PM +0200, Andreas
Jaeger wrote:
rcXXX is a foreign concept not part of systemd , therefore there should
be no expectative whatsoever about it working with systemd, even less an
rpmlint error in place. After some discussion with Sascha, we agreed that
we have the following
goals:
* Moving to only systemd service files (while still supporting SysV init
service files)
* Supporting building with SLE 11 which comes with SysV init
* The rcXXX script should continue to work with systemd
Hi,
can we have the rcXXX rpmlint error for that? I'm not sure how much
systemd-only packages do we have atm and how many of them links
/sbin/service in this case.
7 p.m.
On 04/08/2013 01:40 PM, Frederic Crozat wrote:
But it is an expectation from our users (openSUSE and
SLE). We worked
hard to make transition to systemd as smooth as possible and making sure
rcXXX still works is part of that. We shouldn't drop it.
Do you realize that rcxxx does not make any sense for a large number of
services right ?
- Services that cannot be stopped
- services cannot be started
- Services that cannot be restarted
- services on which it is meaningless and confusing, because they will
be activated or stopped whenenever needed by udev, or by socket
activation or dbus.
- rcxxx symlinks were not part of sysvinit, it is yet another SUSE
extension.
- systemctl has bash/zsh/etc completion for people that do not want to
type larger commands.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
7:04 p.m.
Le lundi 08 avril 2013 à 14:00 -0300, Cristian Rodríguez a écrit :
On 04/08/2013 01:40 PM, Frederic Crozat wrote:
Yes and we should carry it, because many of our users are still using
it. Removing it just for the sake of removing it is absurd.
But it is an expectation from our users (openSUSE
and SLE). We worked
hard to make transition to systemd as smooth as possible and making sure
rcXXX still works is part of that. We shouldn't drop it.
Do you realize that rcxxx does not make any sense for a large number of
services right ?
- Services that cannot be stopped
- services cannot be started
- Services that cannot be restarted
- services on which it is meaningless and confusing, because they will
be activated or stopped whenenever needed by udev, or by socket
activation or dbus.
- rcxxx symlinks were not part of sysvinit, it is yet another SUSE
extension. - systemctl has bash/zsh/etc completion for people
that do not want to
type larger commands.
Of course, I encourage people to use systemctl, but it is not the point
here.
--
Frederic Crozat <fcrozat(a)suse.com>
SUSE
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
7:07 p.m.
On 04/08/2013 02:04 PM, Frederic Crozat wrote:
Yes and we should carry it, because many of our users
are still using
it. Removing it just for the sake of removing it is absurd.
So we should carry them even when anachronic and confusing ?
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
10 Apr
10 Apr
8:04 p.m.
Dnia poniedziałek, 8 kwietnia 2013 14:07:40 Cristian Rodríguez pisze:
On 04/08/2013 02:04 PM, Frederic Crozat wrote:
I do not think we should carry anachronic and confusing RC scripts. Those
should be updated and cleaned up first.
IMHO,
Chris
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Yes and we should carry it, because many of our
users are still using
it. Removing it just for the sake of removing it is absurd.
So we should carry them even when anachronic and confusing ?
8:14 p.m.
El mié 10 abr 2013 15:04:03 CLST, Křištof Želechovski escribió:
Dnia poniedziałek, 8 kwietnia 2013 14:07:40 Cristian
Rodríguez pisze:
Updating or cleaning them will not make them suddendly less confusing.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On 04/08/2013 02:04 PM, Frederic Crozat wrote:
I do not think we should carry anachronic and confusing RC scripts. Those
should be updated and cleaned up first. Yes and we should carry it, because many of our
users are still using
it. Removing it just for the sake of removing it is absurd.
So we should carry them even when anachronic and confusing ?
12 Apr
12 Apr
3:29 p.m.
On Wed, Apr 10, 2013 at 03:14:20PM -0300, Cristian Rodríguez wrote:
El mié 10 abr 2013 15:04:03 CLST, Křištof Želechovski
escribió:
Don't bee to much off-topic. Frederic and mine are tallking about rcXXX
**symlinks**. Those hides the details about how service is spawned in
sysvinit/systemd and don't need anything in /etc/init.d/ installed,
having /usr/sbin/rcvsftpd -> /sbin/service will simply call systemctl.
I'm pretty sure this is tiny and nice advantage for SUSE users and shall
not be removed.
Regards
Michal Vyskocil
Dnia poniedziałek, 8 kwietnia 2013 14:07:40
Cristian Rodríguez pisze:
Updating or cleaning them will not make them suddendly less confusing. On 04/08/2013 02:04 PM, Frederic Crozat wrote:
I do not think we should carry anachronic and confusing RC scripts. Those
should be updated and cleaned up first. Yes and we should carry it, because many of our
users are still using
it. Removing it just for the sake of removing it is absurd.
So we should carry them even when anachronic and confusing ?
9:40 p.m.
El 12/04/13 10:29, Michal Vyskocil escribió:
Don't bee to much off-topic. Frederic and mine are
tallking about rcXXX
**symlinks**. Those hides the details about how service is spawned in
sysvinit/systemd and don't need anything in /etc/init.d/ installed,
having /usr/sbin/rcvsftpd -> /sbin/service will simply call systemctl.
I am not off-topic, I think I am spot-on though :-)
rcfoo status --> meaningless or confusing when the service depends on a
device that has not been plugged in yet, or when StopWhenUnneeded is set.
rcfoo start|stop
- meaningless or confusing the the unit file has RefuseManualStart or
RefuseManualStop set, I assume you dont want to restrict usage of unit
file options in order to preserve this illusion of compatibility do you ?
BUgzilla will probably speak louder & clearer and will certainly have
more luck being listened to than me.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
10:01 p.m.
On Fri, Apr 12, 2013 at 4:40 PM, Cristian Rodríguez
<crrodriguez(a)opensuse.org> wrote:
rcfoo start|stop
- meaningless or confusing the the unit file has RefuseManualStart or
RefuseManualStop set, I assume you dont want to restrict usage of unit file
options in order to preserve this illusion of compatibility do you ?
Why would it be meaningless?
It would tell you it refused to start|stop. That's all. As would
invoking systemctl would. Is systemctl meaningless because it would
refuse?
In any case, in those cases the package is configured as you say it's
meaningless. We're all assuming discretionary judgement by the
packager.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
10:38 p.m.
El vie 12 abr 2013 17:01:00 CLST, Claudio Freire escribió:
On Fri, Apr 12, 2013 at 4:40 PM, Cristian Rodríguez
<crrodriguez(a)opensuse.org> wrote:
Yeah, but users expect sysvinit behaviour.. where there was no such
thing as refusing to start or stop BECAUSE the init script said so,
distinct from an error, misconfiguration..
This are the return values :
# Return values acc. to LSB for all commands but status:
# 0 - success
# 1 - generic or unspecified error
# 2 - invalid or excess argument(s)
# 3 - unimplemented feature (e.g. "reload")
# 4 - user had insufficient privileges
# 5 - program is not installed
# 6 - program is not configured
# 7 - program is not running
# 8--199 - reserved (8--99 LSB, 100--149 distrib, 150--199 appl)
start , stop cannot fall under 3 "unimplemented" since those are
mandatory under this old arse scenario :-P
rcfoo start|stop
- meaningless or confusing the the unit file has RefuseManualStart or
RefuseManualStop set, I assume you dont want to restrict usage of unit file
options in order to preserve this illusion of compatibility do you ?
Why would it be meaningless?
It would tell you it refused to start|stop. That's all. In any case, in those cases the package is configured
as you say it's
meaningless. We're all assuming discretionary judgement by the
packager.
Problem is rpmlint does not have discretionary judgement.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
11:19 p.m.
On Fri, Apr 12, 2013 at 5:38 PM, Cristian Rodríguez
<crrodriguez(a)opensuse.org> wrote:
Well, yes, expecting strict adherence to sysvinit behavior is ridiculous.
One thing is retaining functionality, and another is getting pedantic
about how that functionality behaves, when the underlying system
behaves different.
My point for rc scripts were, and I think others' too, about broad
functionality, not the specific interface provided by sysvinit, but
the general interface and ability to act on services beyond systemd's
builtin actions, and within systemd's builtin actions, when those make
sense.
If a user script fails because it cannot start a service that is now
forbidden from starting manually, or to perform an action that indeed
cannot be performed now, then that's an underlying failure of the
scripts' assumptions that has to be adapted to the new system, and one
wants that to fail. It's not a simple "this command has been renamed
so I have to change 100 scripts".
Ok, true, but packagers can add an rpmlintrc, so packagers do have
discretionary judgement.
The transition can be handled with warnings, increasing badness, whatever works.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Why would it
be meaningless?
It would tell you it refused to start|stop. That's all.
Yeah, but users expect sysvinit behaviour.. where there was no such thing as
refusing to start or stop BECAUSE the init script said so,
distinct from an error, misconfiguration.. In any case,
in those cases the package is configured as you say it's
meaningless. We're all assuming discretionary judgement by the
packager.
Problem is rpmlint does not have discretionary judgement.
8 Apr
8 Apr
7:33 p.m.
On Mon, Apr 8, 2013 at 2:04 PM, Frederic Crozat <fcrozat(a)suse.com> wrote:
Not only that, rc scripts, when scripts and not just symlinks, provide
a much-needed standardized way of getting to figure out the "extended
status" of some services. Init scripts provided them when SysVinit was
the only way, but I agree pegging extra functionality into SysVinit
scripts was... dubious. However, having rc scripts provide said extra
functionality makes a lot of sense.
And by extended status I mean something beyond systemd's "yeah, I
started it - it ought to be running". Just try rcapparmor status on
12.2 to see how useless asking systemctl is.
More than completion, I'd like to see systemctl accepting
"abbreviated" service names, as in without the ".service" which is so
very redundant, for starters.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
- rcxxx
symlinks were not part of sysvinit, it is yet another SUSE
extension.
Yes and we should carry it, because many of our users are still using
it. Removing it just for the sake of removing it is absurd. - systemctl
has bash/zsh/etc completion for people that do not want to
type larger commands.
Of course, I encourage people to use systemctl, but it is not the point
here. 
7:39 p.m.
- systemctl has bash/zsh/etc completion for people
that do not want to
type larger commands.
Of course, I encourage people to use systemctl, but it is not the point
here.
7:48 p.m.
On Mon, Apr 8, 2013 at 2:39 PM, Dimstar / Dominique Leuenberger
<dimstar(a)opensuse.org> wrote:
More than completion, I'd like to see systemctl accepting
"abbreviated" service names, as in without the ".service" which is
so
very redundant, for starters.
You must love the speed we implement your wishes!
Frederic went ahead and commited your wish like... 6 months ago or so :)
Since we have systemd 193 (first shipped in 12.3 I think), you no longer
have to specify the .service suffix.
Lol, and I did test before writing it, but I'm now in 12.2. Kuddos :D
So yeah, I do love that wish-granting speed. I wish I was as fast at
embracing those (ie, zypper dup).
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
- systemctl has bash/zsh/etc completion for people
that do not want to
type larger commands.
Of course, I encourage people to use systemctl, but it is not the point
here.
9 Apr
9 Apr
9:55 a.m.
Le lundi 08 avril 2013 à 19:39 +0200, Dimstar / Dominique Leuenberger a
écrit :
More than completion, I'd like to see systemctl accepting
"abbreviated" service names, as in without the ".service" which is
so
very redundant, for starters.
You must love the speed we implement your wishes!
Frederic went ahead and commited your wish like... 6 months ago or so :)
Since we have systemd 193 (first shipped in 12.3 I think), you no longer
have to specify the .service suffix.
For the record, upstream did this but I couldn't backport it for
released distro (too invasive).
--
Frederic Crozat <fcrozat(a)suse.com>
SUSE
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
- systemctl
has bash/zsh/etc completion for people that do not want to
type larger commands.
Of course, I encourage people to use systemctl, but it is not the point
here.
8 Apr
8 Apr
8:18 p.m.
On 04/08/2013 02:33 PM, Claudio Freire wrote:
On Mon, Apr 8, 2013 at 2:04 PM, Frederic Crozat
<fcrozat(a)suse.com> wrote:
Not only that, rc scripts, when scripts and not just symlinks,
As far as I am concerned is just a bunch of confusing unnecesary hacks
that people apparently have an emotional attachment to.
Currently service much more than "running", "stopped".. the can be
activated (and stopped) in a variety of ways.
provide
- rcxxx
symlinks were not part of sysvinit, it is yet another SUSE
extension.
Yes and we should carry it, because many of our users are still using
it. Removing it just for the sake of removing it is absurd. a much-needed standardized way of getting to figure
out the "extended
status" of some services. Init scripts provided them when SysVinit was
the only way, but I agree pegging extra functionality into SysVinit
scripts was... dubious. However, having rc scripts provide said extra
functionality makes a lot of sense.
What do you mean ? systemctl does report the service status..
And by extended status I mean something beyond systemd's "yeah, I
started it - it ought to be running". Just try rcapparmor status on
12.2 to see how useless asking systemctl is.
apparmor has to be hooked up to systemd the same way they other LSMs
already are, nobody has done the required work though (unlike redhat or
intel that paid people to do the work upstream)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
9:11 p.m.
On Mon, Apr 8, 2013 at 3:18 PM, Cristian Rodríguez
<crrodriguez(a)opensuse.org> wrote:
Ok, maybe an LSM does indeed need to be supported by systemd specifically.
But how does this rationale apply to other stuff? Just for an example
I had to search for among all rc scripts... "rcntp ntptimeset".
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On 04/08/2013 02:33 PM, Claudio Freire wrote:
Strip emotional, because that adjective is added by you without base
of fact. You cannot know whether the attachment is emotional or of
some other kind, since you do not share it.
But there is attachment, and attachment to some workflow must not be
ignored, for it usually means it's a good workflow at some level.
That the mistake, that is happening all over the place, with Gnome3
for instance, but not only, and is creating all sorts of uproar.
Because people's workflow attachments are meaningful, no matter what
an "enlightened developer" might think.
In this case, as rcscript functionality gets broken more and more by
symlinking to systemctl, yeah, attachment will end up being emotional
in the end, because none of the functionality that made it a rational
kind of attachment remains.
But the point is, that when rc scripts add functionality, that is
good, especially notably because people's attachment to them proves
it's good.
And notice the conditiona. *When rc scripts add functionality*. By
symlinking to systemctl, the only functionality left in them are as an
alias. Might be a good functionality to keep if that prevents sysadmin
scripts from breaking, but it's far less valuable than being able to
quickly interact with services in a more complex manner than systemd
understands.
On Mon, Apr 8, 2013 at 2:04 PM, Frederic Crozat <fcrozat(a)suse.com> wrote:
Not only that, rc scripts, when scripts and not just symlinks,
As far as I am concerned is just a bunch of confusing unnecesary hacks that
people apparently have an emotional attachment to.
- rcxxx symlinks were not part of sysvinit, it is yet another SUSE
extension.
Yes and we should carry it, because many of our users are still using
it. Removing it just for the sake of removing it is absurd. Currently service much more than "running",
"stopped".. the can be activated
(and stopped) in a variety of ways.
Not sure what you mean here.
And by
extended status I mean something beyond systemd's "yeah, I
started it - it ought to be running". Just try rcapparmor status on
12.2 to see how useless asking systemctl is.
apparmor has to be hooked up to systemd the same way they other LSMs already
are, nobody has done the required work though (unlike redhat or intel that
paid people to do the work upstream)
9:21 p.m.
On Mon 08 Apr 2013 04:11:07 PM CLST, Claudio Freire wrote:
"rcntp ntptimeset".
ntptimeset --> timedatectl(1)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
9:41 p.m.
* Cristian Rodríguez <crrodriguez(a)opensuse.org> [04-08-13 15:24]:
On Mon 08 Apr 2013 04:11:07 PM CLST, Claudio Freire
wrote:
"rcntp ntptimeset".
ntptimeset --> timedatectl(1)
There appears to be some minor difficulty here also, left hand not knowing
what right hand is doing????
15:37 Crash: ~ # timedatectl
Local time: Mon, 2013-04-08 15:37:24 EDT
Universal time: Mon, 2013-04-08 19:37:24 UTC
RTC time: Mon, 2013-04-08 19:37:24
Timezone: America/Indiana/Indianapolis
NTP enabled: no
NTP synchronized: no
RTC in local TZ: no
15:37 Crash: ~ # systemctl status ntp
ntp.service - LSB: Network time protocol daemon (ntpd)
Loaded: loaded (/etc/init.d/ntp)
Active: active (running) since Sat, 2013-03-30 19:34:45 EDT; 1 weeks and 1 days
ago
CGroup: name=systemd:/system/ntp.service
└ 4178 /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u ntp:ntp -i
/var/lib/ntp -c /etc/ntp.conf
Mar 30 19:34:45 Crash ntpd[4178]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
Mar 30 19:34:45 Crash ntpd[4178]: Listen and drop on 1 v6wildcard :: UDP 123
Mar 30 19:34:45 Crash ntpd[4178]: Listen normally on 2 lo 127.0.0.1 UDP 123
Mar 30 19:34:45 Crash ntpd[4178]: Listen normally on 3 eth0 192.168.1.10 UDP 123
Mar 30 19:34:45 Crash ntpd[4178]: Listen normally on 4 lo ::1 UDP 123
Mar 30 19:34:45 Crash ntpd[4178]: Listen normally on 5 eth0 fe80::7271:bcff:fee9:3c0 UDP
123
Mar 30 19:34:45 Crash ntpd[4178]: peers refreshed
Mar 30 19:34:45 Crash ntpd[4178]: Listening on routing socket on fd #22 for interface
updates
Mar 30 19:34:45 Crash ntp[4062]: Starting network time protocol daemon (NTPD)..done
Mar 30 19:34:45 Crash systemd[1]: Started LSB: Network time protocol daemon (ntpd).
NTP not enabled/sync'ed or is it?
--
(paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711
http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2
http://en.opensuse.org openSUSE Community Member
Registered Linux User #207535 @ http://linuxcounter.net
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
9:48 p.m.
On 04/08/2013 04:41 PM, Patrick Shanahan wrote:
* Cristian Rodríguez <crrodriguez(a)opensuse.org>
[04-08-13 15:24]:
On Mon 08 Apr 2013 04:11:07 PM CLST, Claudio
Freire wrote:
"rcntp ntptimeset".
ntptimeset --> timedatectl(1)
There appears to be some minor difficulty here also, left hand not knowing
what right hand is doing???? NTP not enabled/sync'ed or is it?
yes, this is a side effect of the ntp daemon not been hooked up with the
timedatectl functionality (lack of native units files and following the
spec)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
9:36 p.m.
* Claudio Freire <klaussfreire(a)gmail.com> [04-08-13 15:13]:
[...]
Ok, maybe an LSM does indeed need to be supported by
systemd specifically.
But how does this rationale apply to other stuff? Just for an example
I had to search for among all rc scripts... "rcntp ntptimeset".
Using systemctl, I wonder how one would issue:
rcapache2 graceful
or:
reload|graceful - do a graceful restart by sending a SIGUSR1, or
start if not running
stop-graceful - stop httpd (sending SIGWINCH to parent)
configtest - do a configuration syntax test
extreme-configtest - try to run httpd as nobody (detects more errors
by actually loading the configuration, but cannot
read SSL certificates)
probe - probe for the necessity of a reload, give
out the argument which is required for a reload.
(by comparing conf files with pidfile timestamp)
full-server-status - dump a full status screen; requires lynx or w3m
and mod_status enabled
server-status - dump a short status screen; requires lynx or w3m
and mod_status enabled
I do use systemd/systemctl but I also use rcapache2 for above function(s)
and afaics, systemctl does not provide these. full-server-status
And have not seen it discussed in the opensuse lists.
- dump a
--
(paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711
http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2
http://en.opensuse.org openSUSE Community Member
Registered Linux User #207535 @ http://linuxcounter.net
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
9:46 p.m.
On 04/08/2013 04:36 PM, Patrick Shanahan wrote:
* Claudio Freire <klaussfreire(a)gmail.com>
[04-08-13 15:13]:
[...]
Ok, maybe an LSM does indeed need to be supported
by systemd specifically.
But how does this rationale apply to other stuff? Just for an example
I had to search for among all rc scripts... "rcntp ntptimeset".
Using systemctl, I wonder how one would issue:
rcapache2 graceful I do use systemd/systemctl but I also use rcapache2
for above function(s)
and afaics, systemctl does not provide these. full-server-status
And have not seen it discussed in the opensuse lists.
- dump a
It is implemented the following way..
systemctl restart apache2 --> is graceful restart
systemctl stop apache2 --> is graceful stop (when stopping systemd will
issue TERM if the service refused to go down nicely after a timeout)
which is what you really want..
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
9:37 p.m.
On 04/08/2013 04:11 PM, Claudio Freire wrote:
I mean that the system no longer works the way rcxxx will produce
meaninful output in many cases, many services will start on-demand, udev
or desktop environments will ask for them when needed and will be
garbage collected when unused.
There are oneshot services on which started/running/stopped does not
make sense or static ones where any of those operations may not yield
any meaning either.
Same thing with chkconfig for example, there are services that do not
belong to any particular target/runlevel and hence reporting "on" or
"off" is context,hardware or environment dependant (think containers,
virtual machines, hotplugged devices) "being off" does not mean it will
not start and being "on" is no indication of the reverse either.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Currently
service much more than "running", "stopped".. the can be activated
(and stopped) in a variety of ways.
Not sure what you mean here.
10:33 p.m.
On Mon, Apr 8, 2013 at 4:37 PM, Cristian Rodríguez
<crrodriguez(a)opensuse.org> wrote:
On 04/08/2013 04:11 PM, Claudio Freire wrote:
I mean that the system no longer works the way rcxxx will produce meaninful
output in many cases, many services will start on-demand, udev or desktop
environments will ask for them when needed and will be garbage collected
when unused.
There are oneshot services on which started/running/stopped does not make
sense or static ones where any of those operations may not yield any meaning
either.
I don't think that any of that matters for this conversation.
Rc scripts handle all those kinds of services, because rc scripts are
tailored to the service, and options are added to them besides the
standard start/stop. That's one point of rc scripts. They're the
epitome of flexibility, even when that comes with a maintainership
cost. But it's not the point I was trying to make.
Systemd has lots of holes understanding many of those kinds of
services that don't just start/stop. Many of them that I've seen
wrongfully treated as one-shot services, which is wrong, but
nevertheless that doesn't mean systemd can't or shouldn't be taught
about them.
No, my point wasn't about the service execution model, although I have
mentioned the service execution model when ranting against systemd
before.
My point this time was that there are lots of tasks related to
services that don't pertain to starting or stopping them, and there's
no hope of adding those to systemctl since they're so varied, nor
would it be correct, and this is where rc scripts shine. They act as a
central hub to general service administration, and it's good to have
such a hub. It eases the sysadmin's task.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Currently
service much more than "running", "stopped".. the can be
activated
(and stopped) in a variety of ways.
Not sure what you mean here.
11:36 p.m.
On 04/08/2013 05:33 PM, Claudio Freire wrote:
Rc scripts handle all those kinds of services, because
rc scripts are
tailored to the service, and options are added to them besides the
standard start/stop.
That was a distribution extension of init scripts.
Systemd has lots of holes understanding many of those
kinds of
services that don't just start/stop.
No, however there is a massive hole of misunderstanding about how it
works (or how it should work)
My point this time was that there are lots of tasks
related to
services that don't pertain to starting or stopping them, and there's
no hope of adding those to systemctl since they're so varied, nor
would it be correct, and this is where rc scripts shine. They act as a
central hub to general service administration, and it's good to have
such a hub. It eases the sysadmin's task.
The problem is, they were built for a model that does not exists
anymore, it will just confuse sysadmins and will result in endless
reports and rants about it.
As Im pretty sure I am right and this idea is wrong,I will just sit and
watch the show, time will surely force the proponents to accept that you
cannot keep an illusion alive for very long. unfortunately that also
means it is gonna break badly sooner or later.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
9 Apr
9 Apr
2 a.m.
On Mon, Apr 8, 2013 at 6:36 PM, Cristian Rodríguez
<crrodriguez(a)opensuse.org> wrote:
Perhaps. Time will tell.
Motivation or origin doesn't matter. The merit of the tool itself
does. And it's useful to be able to "rcservice what" or even just
"rcservice" and be told about what you can do with it, beyond
start/stop. Even "man service" would work. Thing is, "man service"
rarely lists all the ways of starting and stopping the service which
involve, sadly, mixing systemd, service-specific tools and/or sending
signals to certain processes.
Furthermore, it's good to be able to "rcservice something" from
scripts, and if the way of doing that somthing changes, the script
won't break. That's called interface specification, something
completely lacking of services in general, which rc scripts fill, and
something every developer should know is needed.
Systemd has
lots of holes understanding many of those kinds of
services that don't just start/stop.
No, however there is a massive hole of misunderstanding about how it works
(or how it should work) My point this
time was that there are lots of tasks related to
services that don't pertain to starting or stopping them, and there's
no hope of adding those to systemctl since they're so varied, nor
would it be correct, and this is where rc scripts shine. They act as a
central hub to general service administration, and it's good to have
such a hub. It eases the sysadmin's task.
The problem is, they were built for a model that does not exists anymore, it
will just confuse sysadmins and will result in endless reports and rants
about it. As Im pretty sure I am right and this idea is wrong,I
will just sit and
watch the show, time will surely force the proponents to accept that you
cannot keep an illusion alive for very long. unfortunately that also means
it is gonna break badly sooner or later.
Great talking to you.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
8 Apr
8 Apr
10:42 p.m.
Hello,
Am Montag, 8. April 2013 schrieb Cristian Rodríguez:
On 04/08/2013 02:33 PM, Claudio Freire wrote:
> And by extended status I mean something beyond systemd's "yeah, I
> started it - it ought to be running". Just try rcapparmor status on
> 12.2 to see how useless asking systemctl is.
Indeed. I'm still waiting (maybe praying helps?) for ExecStatus...
apparmor has to be hooked up to systemd the same way
they other LSMs
already are, nobody has done the required work though (unlike redhat
or intel that paid people to do the work upstream)
Thinking about who could do or pay that - let me have a short look at
the history of AppArmor...
Long time ago, Novell bought Immunix, renamed their "SubDomain" to
"AppArmor" and had a new feature for SuSE Linux [1] and SLE. Some years
later, interests changed (for whatever reason) and the AppArmor team was
fired. Later some of them were hired by Canonical/Ubuntu, and that's
where most of AppArmor development happens currently. Too bad that
Ubuntu uses upstart...
If the systemd integration can be done in a scripting language (perl,
bash etc.) and you want to pay me... ;-)
Otherwise someone @SUSE might be the perfect candidate to do it [2][3].
Regards,
Christian Boltz
[1] I didn't check, but I'm quite sure this happened in the
"SuSE with lowercase u" timeframe
[2] Maybe someone is still looking for a hackweek project?
[3] <BoFH> I wonder how it will work in SLE12 ;-) </BoFH>
--
Naja... wo ein Maildir ist, ist auch ein Dateisystem... also ein
kleines Shellscript kochen (Gewürze: sed, awk, bash, evtl. auch
einfach nur perl) [Sven Schumacher in postfixbuch-users]
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
9 Apr
9 Apr
9:57 a.m.
Le lundi 08 avril 2013 à 14:33 -0300, Claudio Freire a écrit :
On Mon, Apr 8, 2013 at 2:04 PM, Frederic Crozat
<fcrozat(a)suse.com> wrote:
Not only that, rc scripts, when scripts and not just symlinks, provide
a much-needed standardized way of getting to figure out the "extended
status" of some services. Init scripts provided them when SysVinit was
the only way, but I agree pegging extra functionality into SysVinit
scripts was... dubious. However, having rc scripts provide said extra
functionality makes a lot of sense.
And by extended status I mean something beyond systemd's "yeah, I
started it - it ought to be running". Just try rcapparmor status on
12.2 to see how useless asking systemctl is.
Try it on 12.3 for initscripts which have a non-standard status output
and you'll get both the "initscript" status + systemctl one.
But this stuff shouldn't be in initscript anyway.
--
Frederic Crozat <fcrozat(a)suse.com>
SUSE
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
- rcxxx
symlinks were not part of sysvinit, it is yet another SUSE
extension.
Yes and we should carry it, because many of our users are still using
it. Removing it just for the sake of removing it is absurd.
8 Apr
8 Apr
8:38 p.m.
On 04/08/2013 10:20 AM, Andreas Jaeger wrote:
After some discussion with Sascha, we agreed that we
have the following
goals:
* Supporting building with SLE 11 which comes with
SysV init
What about just asking people to create a different spec file instead of
cluttering the actual ones with endless %if ? have you seen the mess
this creates ? have you noticed that all this conditions are always
added but never removed ?
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
9:59 p.m.
Hello,
Am Montag, 8. April 2013 schrieb Cristian Rodríguez:
On 04/08/2013 10:20 AM, Andreas Jaeger wrote:
A separate spec file? No thanks.
The %if might be annoying, but having multiple copies of the spec is
like calling for problems. Those files _will_ get out of sync.
Been there, done that. Not with spec files, but with PHP code. The
previous programmer used cp instead of if(). The result was that there
were up to 4 copies of (nearly) the same code, but each copy came with a
different set of bugs (typically bugs were fixed only in one place, the
other copies still had the bug)...
Regards,
Christian Boltz
--
After some discussion with Sascha, we agreed that
we have the
following goals:
* Supporting building with SLE 11 which comes with SysV init
What about just asking people to create a different spec file instead
of cluttering the actual ones with endless %if ? have you seen the
mess this creates ? have you noticed that all this conditions are
always added but never removed ? A "wait and see" attitude is definitely
called for instead of
"headless chicken" mode.
Ha ha.. come on... headless chicken mode is so
much more entertaining
to watch though :-) [Henne Vogelsang and Clayton in opensuse]
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
7 Apr
7 Apr
12:03 p.m.
Hi Andi
Andreas Jaeger <aj(a)suse.com> schrieb:
I don't see this guideline as a law but as
guidance. So, let's talk
about exceptions. And if you have a suggestion for a better wording
then please propose one.
As we have many guidelines for our packages, but less "laws", I always follow
this direction when I review packages for factory:
* submission violates the law: reject (including hint or URL as reason)
* submission violates the guideline: accept (including hint or URL to the guideline asking
to think about for next submission)
* submission does not violate anything above, but I have a bad feeling: ask other
reviewers - or discuss directly with the packager. In worst case: reject
* submission does not violate anything above, but I have a hint for the packager: accept,
including my hint
* …
My feeling is now that I am not a good reviewer as I accept too many packages. My hope
is/was that packagers read my comments even if their package gets accepted for Factory. If
this assumption is wrong, we should discuss what I can do instead.
Currently I do not like the idea to reject packages because of guideline violations, but
if my notes are not read if I accept a package, than I should adapt to a better strategy.
Suggestions welcome!
Lars
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
9:14 p.m.
On Sun, Apr 7, 2013 at 7:03 AM, Lars Vogdt <lrupp(a)suse.de> wrote:
My feeling is now that I am not a good reviewer as I
accept too many packages. My hope is/was that packagers read my comments even if their
package gets accepted for Factory. If this assumption is wrong, we should discuss what I
can do instead.
Currently I do not like the idea to reject packages because of guideline violations, but
if my notes are not read if I accept a package, than I should adapt to a better strategy.
Suggestions welcome!
It may not be at all bad to reject, if it's a guideline and it is
clear that compliance is optional, the one that submitted can decide
to reopen with a comment on why we would not comply. Either a
compelling reason not to comply, or maybe something along the lines of
"it would be too much work and it's better to push this fix sooner
rather than later" would still be very informative.
It's a pity OBS doesn't let you add a comment without either accepting
or rejecting.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
8 Apr
8 Apr
1:43 p.m.
On Sunday, April 07, 2013 12:03:10 Lars Vogdt wrote:
Hi Andi
Andreas Jaeger <aj(a)suse.com> schrieb:
There's always a line for interpretation - e.g. if the guidelines get
updated, I would not enforce it necessarily for old submissions.
I don't see this guideline as a law but as
guidance. So, let's talk
about exceptions. And if you have a suggestion for a better wording
then please propose one.
As we have many guidelines for our packages, but less "laws", I always
follow this direction when I review packages for factory:
* submission violates the law: reject (including hint or URL as
reason)
* submission violates the guideline: accept (including hint or URL to
the guideline asking to think about for next submission)
* submission does not violate anything above, but I have a bad
feeling: ask other reviewers - or discuss directly with the packager.
In worst case: reject
* submission does not violate anything above, but I have a hint for
the packager: accept, including my hint
* …
My feeling is now that I am not a good reviewer as I accept too many
packages. My hope is/was that packagers read my comments even if
their package gets accepted for Factory. If this assumption is wrong,
we should discuss what I can do instead. Currently I do not like the idea to reject packages
because of
guideline violations, but if my notes are not read if I accept a
package, than I should adapt to a better strategy. Suggestions
welcome!
I might be a bit more willing to reject submissions but IMO it's
important to know that review is not final - if anybody disagrees with
the review, reopening the request and adding a comment or mailing me
directly is always fine.
I see a challenge with the notes if A submits to a devel projects, B
accepts and forwards it - will A get your note - or only B? Packagers,
are these review notes helpfull - or should we direct directly?
Andreas
--
Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
11:08 p.m.
Hello,
Am Montag, 8. April 2013 schrieb Andreas Jaeger:
On Sunday, April 07, 2013 12:03:10 Lars Vogdt wrote:
> * submission violates the guideline: accept (including hint or URL
> to the guideline asking to think about for next submission)
That sounds like a good way, especially if the SR touches an area that
has nothing to do with the violated guideline.
I see a challenge with the notes if A submits to a
devel projects, B
accepts and forwards it - will A get your note - or only B?
AFAIK only B.
I'd prefer if A also gets a note - not only for a declined SR, but also
when it's forwarded and when the forwarded request is accepted.
Sometimes I'd even want to CC on a "foreign" SR so that I'm updated
about its status, but I didn't find a way how to do this.
Packagers,
are these review notes helpfull - or should we direct directly?
IMHO the notes are helpful and a good idea - and less frustrating than
declining the SR [1]. OTOH the notes might get lost, while a declined SR
stays on the TODO list. It's probably a question of personal taste ;-)
Regards,
Christian Boltz
[1] you know what can happen - you declined one of my SRs some months
ago, and the result were bugreports for two innocent developers ;-)
--
alles drumherum ist Schrott... Natürlich nur, wenn Du nicht wieder eine
deiner revolutionären Ideen hast. :-) Vielleicht eine chroot-Umgebung
pro compare-Prozess mit /tmp in einer initrd? :-))))
[Ratti in fontlinge-devel]
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
24 Apr
24 Apr
1:56 p.m.
On 03/29/2013 06:43 PM, Andreas Jaeger wrote:
Since we moved to systemd completely, I suggest that
newly added files
will contain service files - and not init scripts anymore.
So, please only add service files to new packages and if you change your
init file, consider using a service file and dropping the init file,
Andreas
So we now have several people creating/copying service files for various
packages with varying mileage. For instance, rabbitmq-server got one
which forget some stuff present in the init script. While that is all
fixable, I urge everyone to actually test those *.service files since
they take precedence over init scripts.
--
With kind regards,
Sascha Peilicke
SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
2:04 p.m.
Le mercredi 24 avril 2013 à 13:56 +0200, Sascha Peilicke a écrit :
On 03/29/2013 06:43 PM, Andreas Jaeger wrote:
We are also planning to initiate a cross-distribution .service pool,
when services aren't upstreamed, to share files which are being written
in various distributions.
It isn't announced yet (and help would be welcome to create a script to
extract the various .service we have in the distribution) but it will be
hosted on https://github.com/teg/systemd-units/
--
Frederic Crozat <fcrozat(a)suse.com>
SUSE
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Since we moved to systemd completely, I suggest
that newly added files
will contain service files - and not init scripts anymore.
So, please only add service files to new packages and if you change your
init file, consider using a service file and dropping the init file,
Andreas
So we now have several people creating/copying service files for various
packages with varying mileage. For instance, rabbitmq-server got one
which forget some stuff present in the init script. While that is all
fixable, I urge everyone to actually test those *.service files since
they take precedence over init scripts. 
25 Apr
25 Apr
10:38 a.m.
Le Wednesday 24 April 2013 à 13:56 +0200, Sascha Peilicke a écrit :
So we now have several people creating/copying service
files for various
packages with varying mileage. For instance, rabbitmq-server got one
which forget some stuff present in the init script. While that is all
fixable, I urge everyone to actually test those *.service files since
they take precedence over init scripts.
Oh yeah. See for example:
Bug 810344 - fancontol not starting
https://bugzilla.novell.com/show_bug.cgi?id=810344
which was caused by an incomplete conversion of an init script to a
service file.
Oh, I must push the fix as a maintenance update, BTW, thanks Sascha for
the reminder.
--
Jean Delvare
Suse L3
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
2824
days inactive
2851
days old
140 comments
29 participants
participants (29)
-
Alin M Elena -
Alin Marin Elena
-
Andreas Jaeger -
Andrey Borzenkov -
Christian Boltz -
Claudio Freire -
Cristian Rodríguez -
Dimstar / Dominique Leuenberger -
Frederic Crozat -
Jean Delvare -
Johannes Meixner -
Jon Nelson -
Křištof Želechovski -
Lars Vogdt -
Ludwig Nussel -
Marcus Meissner -
Michael Matz -
Michal Kubecek -
Michal Kubeček
-
Michal Vyskocil -
Olav Vitters -
Patrick Shanahan -
Raymond Wooninck -
Sascha Peilicke -
Srinidhi B -
Stefan Seyfried -
Stephan Kulow -
Togan Muftuoglu -
Yamaban