Re: f15 libchamplain bump
On Fri, 2011-04-08 at 17:53 +0200, Michael Schwendt wrote: > Is there a releng ticket for the koji buildroot override? Any news on this? - Andreas -- BrandAss Andreas Bierfert, M.Sc. | phone: +49 6897 1721738 | GPG: C58CF1CB andreas.bierf...@lowlatency.de | fax: +49 6897 1722828 | signed/encrypted http://lowlatency.de | cell: +49 170 9665206 | mail preferred signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thursday, April 14, 2011 19:54:36 Lennart Poettering wrote: > On Thu, 14.04.11 16:15, "Jóhann B. Guðmundsson" (johan...@gmail.com) wrote: > > > > > On 04/14/2011 03:36 PM, Lennart Poettering wrote: > > >> In man systemd.unit > > >> > > > >> > BindTo= > > >> > Configures requirement dependencies, very similar in > > >> > style > > >> > to Requires=, however in addition to this behaviour it also > > >> > declares that this unit is stopped when any of the units > > >> > listed suddenly disappears. Units can suddenly, unexpectedly > > >> > disappear if a service terminates on its own choice, a > > >> > device is unplugged or a mount point unmounted without involvement of > > >> > systemd. > > >> > > > >> > ExecStop=-/bin/systemctl stop upsd-device.service > > >> > ExecStop=-/bin/systemctl stop upsd-monitor.service > > > Why ExecStop= here? > > > > It was meant as an either or. > > > > The BindTo= reference in the man page does not mention that it will take > > down with it any service bound to it when the service is stop. > > Requires= and BindTo= both do that. > > The difference between the two switches is mostly an ordering issue: > > Let's say you have a unit A and a unit B. B requires A, and should be > started after A is up. So in B you say: > > Requires=A > After=A Why is "After=" required here? If B Requires A it seem obvious that B should be started After A (if there is no socket magic). > > now, if you shut down A with "systemctl stop A", this will also stop B, > and it will do so in the inverse starting order. i.e. stop B first, stop > A second. BindTo= would do exactly the same here. The difference now > comes if for some reason A dies independently of anybody running > "systemctl stop A": should we then shut down B retroactviely? The > ordering would normally suggest that B goes down before A, but if A just > goes away on its own, then should we still shut down B? If you use > BindTo= that's what would happen. If you use Requires= it wouldn't. That's not exactly what I'd like to know. Lets say there are services A and B. When B is started, A must be running, so B requires A, but when B is stopped, it should stop A. So A is started only on demand, but it should not be running if there is nothing that requires it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] F-15 Beta RC2 Validation Test Recap
Greetings testers, As you've known that Beta has been declared gold, validation tests were being executed to guarantee that Beta RC2 could finally meet the beta release criteria[1]. During the tests, as expected, no beta blockers were found and the results were summarized as below: Installation * F15Beta-NTH(657619): 692135 ON_QA - Image failed media check * F15Blocker(617261): 695280 NEW - Installer unable to find correct dvd from nfsiso repository containing a set of images 696320 NEW - After text-mode iSCSI install and boot, firstboot-text and getty are both running - unable to login on console * Warnings: 695054 NEW - Fail to exercise the addition of a FTP-based package repository during installation. 585006 NEW - syslinux's isohybrid utility creates ISOs with incorrect ISO size in their header (affects Fedora's netinst and live images) Desktop Bug 265350[*] - Can't extend panel to full screen size when multiple monitors are different sizes In addition, special thanks to robatino for his great leadership and the ones who participated in Beta testing, I hereby listed individual test contributions(aka the number of submit results and the contributor's ID) which we really appreciated: * Beta_TC1+RC1+RC2_Install: 120 robatino 9 redwolfe 6 ajwerkman 5 bsfmig 1 cpuobsessed * Beta_TC1_RC1+RC2_Desktop: 20 cra 9 vhumpa 1 jreiser If your bug(or name btw:)) is not listed, next time please remember to mark your results onto the result page so that we can collect your data and keep tracking your issues. See ya in pre-final tests! Thanks, Hurry [1] https://fedoraproject.org/wiki/Fedora_15_Beta_Release_Criteria [*] https://bugs.kde.org/show_bug.cgi?id=265350 -- Contacts Hurry FAS Name: Rhe Timezone: UTC+8 TEL: 86-010-62608141 IRC nick: rhe #fedora-qa #fedora-zh ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Fri, 2011-04-15 at 00:23 +0200, Lennart Poettering wrote: > Note however that while some settings override others some act as > additions. Example: A later User=foo will override an earlier User=bar, > but a later Requires=foo will be added to an earlier Requires=bar, so > that you effectively have "Requires=foo bar". But I think it's kinda > obvious in most cases which settings are those with work as an addition > and which ones override. Is that as obvious as: 1. If the parameter can be used only once (single value), a later usage will override it 2. If the parameter can be used multiple times (list of values), a later usage will be appended Or is there some special inclusion/inheritance magic? -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-15 Branched report: 20110414 changes
Compose started at Thu Apr 14 13:15:51 UTC 2011 Broken deps for x86_64 -- collectd-mysql-4.10.2-2.fc15.x86_64 requires libmysqlclient.so.16()(64bit) collectd-mysql-4.10.2-2.fc15.x86_64 requires libmysqlclient.so.16(libmysqlclient_16)(64bit) cpm-0.23-0.3.beta.fc12.x86_64 requires libdotconf-1.0.so.0()(64bit) db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 dbmail-3.0.0-0.3.rc1.fc15.x86_64 requires libevent-1.4.so.2()(64bit) dbmail-auth-ldap-3.0.0-0.3.rc1.fc15.x86_64 requires libevent-1.4.so.2()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper eog-plugins-2.91.90-1.fc15.x86_64 requires libchamplain-gtk-0.10.so.0()(64bit) eog-plugins-2.91.90-1.fc15.x86_64 requires libchamplain-0.10.so.0()(64bit) 1:fife-0.3.2-1.fc15.i686 requires libboost_regex.so.1.44.0 1:fife-0.3.2-1.fc15.i686 requires libboost_system.so.1.44.0 1:fife-0.3.2-1.fc15.i686 requires libboost_filesystem.so.1.44.0 1:fife-0.3.2-1.fc15.x86_64 requires libboost_regex.so.1.44.0()(64bit) 1:fife-0.3.2-1.fc15.x86_64 requires libboost_system.so.1.44.0()(64bit) 1:fife-0.3.2-1.fc15.x86_64 requires libboost_filesystem.so.1.44.0()(64bit) file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::ScrolledWindow) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Dialog) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Toolbar) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::TreeView) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::MenuBar) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::VBox) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Window) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::MessageDialog) glom-1.16.1-2.fc15.x86_64 requires libgdamm-4.0.so.12()(64bit) glom-libs-1.16.1-2.fc15.i686 requires libgdamm-4.0.so.12 glom-libs-1.16.1-2.fc15.x86_64 requires libgdamm-4.0.so.12()(64bit) glunarclock-0.34.1-1.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-bubblemon-2.0.15-1.fc13.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-cpufire-1.6-3.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-globalmenu-0.7.9-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-grandr-0.4.1-2.fc12.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-music-2.5.1-5.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-sensors-2.2.7-4.fc15.i686 requires libpanel-applet-2.so.0 gnome-applet-sensors-2.2.7-4.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-sshmenu-3.18-3.fc15.noarch requires ruby(panelapplet2) gnome-applet-window-picker-0.5.8-2.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) 1:gnome-applets-2.32.0-3.fc15.x86_64 requires libpanel-applet-3.so.0()(64bit) 1:gnome-applets-2.32.0-3.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) 1:gnome-applets-2.32.0-3.fc15.x86_64 requires libgweather.so.1()(64bit) gnome-netstatus-2.28.2-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires libgpilotd.so.5()(64bit) gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires libgpilotdcm.so.4()(64bit) gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires libgpilotdconduit.so.3()(64bit) gnome-python2-applet-2.32.0-1.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevview.so.3()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevdocument.so.3()(64bit) gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-gdl-2.25.3-22.fc15.x86_64 requires libgdl-1.so.3()(64bit) gnome-python2-totem-2.32.0-1.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gnome-rdp-0.2.3-6.fc12.x86_64 requires mono(Mono.Data.SqliteClient) = 0:2.0.0.0 gnome-themes-2.32.0-5.fc15.noarch requires gtk-theme-engine-clearlooks gnomeradio-1.8-9.fc15.x86_64 requires libgtk-3.0.so.0()(64bit) gnomeradio-1.8-9.fc15.x86_64 requires libgdk-3.0.so.0()(64bit) gnotime-2.3.0-8.fc15.x86_64 requires libgtkhtml-3.15.so.19()(64bit) gnubiff-2.2.13-4.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnustep-back-0.18.0-4.fc14.x86_64 requires libobjc.so.2()(64bit) gnustep-back-0.18.0-4.fc14.x86_64 requires libgnustep-base.so.1.20()(64bit) gnustep-examples-1.3.0-4.fc15.x86_64 re
Re: Systemd unit file implementation questions (ypbind)
On Thu, 14.04.11 15:48, Simo Sorce (sso...@redhat.com) wrote:
> On Thu, 14 Apr 2011 20:35:07 +0200
> Miloslav Trmač wrote:
>
> > On Thu, Apr 14, 2011 at 8:21 PM, Lennart Poettering
> > wrote:
> > > On Thu, 14.04.11 13:05, Chris Adams (cmad...@hiwaay.net) wrote:
> > >> Since they are config files (unlike the init scripts themselves),
> > >> changing them doesn't leave you with RPM wanting to replace them on
> > >> every package update either.
> > >
> > > Yupp, and this is much much prettier in systemd. After you copied
> > > the service file from /lib to /etc they are out of the package
> > > manager territory and will always override what has been configured
> > > by the distro packager.
> > Separating the program that integrates software into the distribution
> > (/etc/init.d/*) and user's configuration that is managed via
> > .rpm{save,new} is actually valuable.
> >
> > If upstream changes how the program should be invoked and the Fedora
> > packager updates /etc/init.d/*, this change is transparent to users,
> > as long as the chang doesn't affect the specifics of user's
> > configuration in /etc/sysconfig - and even if it does, the user has
> > .rpm{save,new} and can figure out what has happened.
> >
> > Copying the service file from /lib to /etc seems to lose this property
> > - if the /etc file "hides" the /lib file, the service will just break
> > with no indication that something needs to be updated. Or does
> > systemd support "inheritance" of configuration from /lib to /etc so
> > that the user can only make the minimal changes necessary?
> > Mirek
>
> I was going to make exactly the same objection.
> Now rpm scripts will have to check and possibly have to muck with the
> copies in /etc or risk that the service in question will fail to work
> after a major update.
>
> Sounds like trading one set of issues for another set of
> potentially bigger issues.
Well, it's quite a bit different. Because an init script is a complex
fragile beast you probably end up updating it quite often. OTOH a
systemd unit file is just a few lines usually, which means there is much
less to update. And due to magic stuff like socket and bus activation
most deps don't have to be configured, so things are much more robus anyway...
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thu, 14.04.11 20:35, Miloslav Trmač (m...@volny.cz) wrote:
>
> On Thu, Apr 14, 2011 at 8:21 PM, Lennart Poettering
> wrote:
> > On Thu, 14.04.11 13:05, Chris Adams (cmad...@hiwaay.net) wrote:
> >> Since they are config files (unlike the init scripts themselves),
> >> changing them doesn't leave you with RPM wanting to replace them on
> >> every package update either.
> >
> > Yupp, and this is much much prettier in systemd. After you copied the
> > service file from /lib to /etc they are out of the package manager
> > territory and will always override what has been configured by the
> > distro packager.
> Separating the program that integrates software into the distribution
> (/etc/init.d/*) and user's configuration that is managed via
> .rpm{save,new} is actually valuable.
>
> If upstream changes how the program should be invoked and the Fedora
> packager updates /etc/init.d/*, this change is transparent to users,
> as long as the chang doesn't affect the specifics of user's
> configuration in /etc/sysconfig - and even if it does, the user has
> .rpm{save,new} and can figure out what has happened.
Well, the simple fact is that systemd unit files aren't really
code. They are just config. So doing code updates on a sysv init script
does not really translate to systemd, because there is nothing to
update.
> Copying the service file from /lib to /etc seems to lose this property
> - if the /etc file "hides" the /lib file, the service will just break
> with no indication that something needs to be updated. Or does
> systemd support "inheritance" of configuration from /lib to /etc so
> that the user can only make the minimal changes necessary?
Yes, you can use ".include /lib/systemd/system/foo.service" to import
another file, and then override selected settings.
Note however that while some settings override others some act as
additions. Example: A later User=foo will override an earlier User=bar,
but a later Requires=foo will be added to an earlier Requires=bar, so
that you effectively have "Requires=foo bar". But I think it's kinda
obvious in most cases which settings are those with work as an addition
and which ones override.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thu, 14 Apr 2011 20:35:07 +0200
Miloslav Trmač wrote:
> On Thu, Apr 14, 2011 at 8:21 PM, Lennart Poettering
> wrote:
> > On Thu, 14.04.11 13:05, Chris Adams (cmad...@hiwaay.net) wrote:
> >> Since they are config files (unlike the init scripts themselves),
> >> changing them doesn't leave you with RPM wanting to replace them on
> >> every package update either.
> >
> > Yupp, and this is much much prettier in systemd. After you copied
> > the service file from /lib to /etc they are out of the package
> > manager territory and will always override what has been configured
> > by the distro packager.
> Separating the program that integrates software into the distribution
> (/etc/init.d/*) and user's configuration that is managed via
> .rpm{save,new} is actually valuable.
>
> If upstream changes how the program should be invoked and the Fedora
> packager updates /etc/init.d/*, this change is transparent to users,
> as long as the chang doesn't affect the specifics of user's
> configuration in /etc/sysconfig - and even if it does, the user has
> .rpm{save,new} and can figure out what has happened.
>
> Copying the service file from /lib to /etc seems to lose this property
> - if the /etc file "hides" the /lib file, the service will just break
> with no indication that something needs to be updated. Or does
> systemd support "inheritance" of configuration from /lib to /etc so
> that the user can only make the minimal changes necessary?
> Mirek
I was going to make exactly the same objection.
Now rpm scripts will have to check and possibly have to muck with the
copies in /etc or risk that the service in question will fail to work
after a major update.
Sounds like trading one set of issues for another set of
potentially bigger issues.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thu, Apr 14, 2011 at 8:21 PM, Lennart Poettering
wrote:
> On Thu, 14.04.11 13:05, Chris Adams (cmad...@hiwaay.net) wrote:
>> Since they are config files (unlike the init scripts themselves),
>> changing them doesn't leave you with RPM wanting to replace them on
>> every package update either.
>
> Yupp, and this is much much prettier in systemd. After you copied the
> service file from /lib to /etc they are out of the package manager
> territory and will always override what has been configured by the
> distro packager.
Separating the program that integrates software into the distribution
(/etc/init.d/*) and user's configuration that is managed via
.rpm{save,new} is actually valuable.
If upstream changes how the program should be invoked and the Fedora
packager updates /etc/init.d/*, this change is transparent to users,
as long as the chang doesn't affect the specifics of user's
configuration in /etc/sysconfig - and even if it does, the user has
.rpm{save,new} and can figure out what has happened.
Copying the service file from /lib to /etc seems to lose this property
- if the /etc file "hides" the /lib file, the service will just break
with no indication that something needs to be updated. Or does
systemd support "inheritance" of configuration from /lib to /etc so
that the user can only make the minimal changes necessary?
Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thu, 14.04.11 13:05, Chris Adams (cmad...@hiwaay.net) wrote: > > Once upon a time, Lennart Poettering said: > > The place for system configuration is /etc. I have yet to see a really > > convincing example why /etc/sysconfig/ or /etc/default would win us > > anything. > > /etc/sysconfig is essentially configuration for the init system managing > daemons. Command-line options, which sub-bits to run, etc. that are not > settable in the daemon configuration files themselves. Yes, but all of that can be configured in a much nicer way in systemd: Copy /lib/systemd/system/foobar.service to /etc/systemd/system/foobar.service, and edit it there. You will have a short, easy to understand, super-flexible, very well documented way to edit service defaults. You can edit command lines, you may set a specific user id to run something as, you may set the CPU affinity or you can adjust the capability bounding set as you wish (among a lot of other stuff). You have the full range of configuration options systemd offers you, all in a very simple ini file. Now, let's look at /etc/sysconfig/xxx. What you see is that only options that the init script explicitly supports you can change. On one service you might be able to change the command line arguments with this, on a different one you may change the user id, on a third one you may change the CPU affinity and a fourht one might allow you to the caps bounding set. But you do not find a single sysconfig file where you could actually configure all of these options. Also, the options tend to have different names even if they do the same, and slightly different behaviour. systemd streamlines this. If you want to change the configuration of a specific service, you can do so with very minimal effort and great flexibility, and all of that without creating a completely new configuration language for it, or without needing specific support in the service startup logic. The configuration language for the admin and for upstream is the *same*. Looking at the history of this: the reason /etc/sysconfig/xxx was created in the first place is that while /etc/init.d/xxx was initially more like configuration (and thus located in /etc) it ended up being more like actual code (which it is after all). So in order to avoid having to edit code to make configuration changes, and to not confuse the package manager /etc/sysconfig/xxx was split out of the actual sysv init scripts. In systemd that split is not necessary, and we should just embrace that instead of keeping /etc/sysconfig/xxx alive without need. > I think having them in a sub-directory is much cleaner (and makes them > easier to distinguish from the "regular" daemon config files). I don't > think /etc/default is a good name (if that indeed is what Debian uses), > because they are options you change to get non-default behavior. I have trouble seeing in which way /etc/nsswitch.conf was in any way more "regular" than /etc/nsswitch.conf, > > I am pretty sure that the vast majority of files in there are > > pretty much unnecessary and their configuration could be solved in a > > different way much nicer. > > I've used a bunch of them to change the ways various daemons run, so I > would definately say they are not "pretty much unnecessary". They are > also shell scripts that are sourced by init scripts, so there is > flexibility to make changes that may not have even been anticipated by > the init script authors. Yeah, and that's the nice thing in systemd, if you want to make a change to a service file, just take it, edit it and enjoy the full power that systemd puts in your hands! > Since they are config files (unlike the init scripts themselves), > changing them doesn't leave you with RPM wanting to replace them on > every package update either. Yupp, and this is much much prettier in systemd. After you copied the service file from /lib to /etc they are out of the package manager territory and will always override what has been configured by the distro packager. And if you want to return to the default settings you can just remove your file from /etc again and voila! Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
Once upon a time, Lennart Poettering said: > The place for system configuration is /etc. I have yet to see a really > convincing example why /etc/sysconfig/ or /etc/default would win us > anything. /etc/sysconfig is essentially configuration for the init system managing daemons. Command-line options, which sub-bits to run, etc. that are not settable in the daemon configuration files themselves. I think having them in a sub-directory is much cleaner (and makes them easier to distinguish from the "regular" daemon config files). I don't think /etc/default is a good name (if that indeed is what Debian uses), because they are options you change to get non-default behavior. > I am pretty sure that the vast majority of files in there are > pretty much unnecessary and their configuration could be solved in a > different way much nicer. I've used a bunch of them to change the ways various daemons run, so I would definately say they are not "pretty much unnecessary". They are also shell scripts that are sourced by init scripts, so there is flexibility to make changes that may not have even been anticipated by the init script authors. Since they are config files (unlike the init scripts themselves), changing them doesn't leave you with RPM wanting to replace them on every package update either. > So yeah, I'd push for phasing /etc/sysconfig out for most services, not > standardize it. I'd be 180 degrees from that. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 696725] New: RPM doesn't create /var/run/amavisd
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: RPM doesn't create /var/run/amavisd https://bugzilla.redhat.com/show_bug.cgi?id=696725 Summary: RPM doesn't create /var/run/amavisd Product: Fedora Version: 15 Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: medium Priority: unspecified Component: amavisd-new AssignedTo: st...@silug.org ReportedBy: night...@hotmail.com QAContact: extras...@fedoraproject.org CC: st...@silug.org, fedora-perl-devel-l...@redhat.com, kana...@kanarip.com Classification: Fedora Story Points: --- Description of problem: The RPM doesn't create /var/run/amavisd, the amvaisd.pid file gets created here at runtime. This directory needs to be created with g+w permissions with group amavis for this package to work correctly. Version-Release number of selected component (if applicable): amavisd-new-2.6.4-3.fc15.noarch -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Systemd unit file implementation questions (ypbind)
On Thu, 14.04.11 16:15, "Jóhann B. Guðmundsson" (johan...@gmail.com) wrote: > > On 04/14/2011 03:36 PM, Lennart Poettering wrote: > >> In man systemd.unit > >> > > >> > BindTo= > >> > Configures requirement dependencies, very similar in style > >> > to Requires=, however in addition to this behaviour it also > >> > declares that this unit is stopped when any of the units > >> > listed suddenly disappears. Units can suddenly, unexpectedly > >> > disappear if a service terminates on its own choice, a > >> > device is unplugged or a mount point unmounted without involvement of > >> > systemd. > >> > > >> > ExecStop=-/bin/systemctl stop upsd-device.service > >> > ExecStop=-/bin/systemctl stop upsd-monitor.service > > Why ExecStop= here? > > It was meant as an either or. > > The BindTo= reference in the man page does not mention that it will take > down with it any service bound to it when the service is stop. Requires= and BindTo= both do that. The difference between the two switches is mostly an ordering issue: Let's say you have a unit A and a unit B. B requires A, and should be started after A is up. So in B you say: Requires=A After=A now, if you shut down A with "systemctl stop A", this will also stop B, and it will do so in the inverse starting order. i.e. stop B first, stop A second. BindTo= would do exactly the same here. The difference now comes if for some reason A dies independently of anybody running "systemctl stop A": should we then shut down B retroactviely? The ordering would normally suggest that B goes down before A, but if A just goes away on its own, then should we still shut down B? If you use BindTo= that's what would happen. If you use Requires= it wouldn't. So where is this interesting? If A is a device and B is a service, then normally B should start after A is plugged in and be killed before A is unplugged. By using BindTo= you can also make it be killed if A is unplugged with B still running. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thu, 14.04.11 18:40, Michał Piotrowski (mkkp...@gmail.com) wrote: > > 2011/4/14 "Jóhann B. Guðmundsson" : > > On 04/14/2011 04:19 PM, Tomasz Torcz wrote: > >>> /etc/sysconfig/xxx is mostly a Fedora/Red Hat idiom. I am pretty sure > >>> > the Debian version of the boot scripts do not honour this request. > >> Debian has mostly identical /etc/default/xxx. > >> > > > > Perhaps the same team that look at /run changes can come back together > > and discuss this problem reach consciousness amongst distro about the > > right path and everbody fix it accordingly... > > I am afraid that something like that will not be possible in this case > - I expect much resistance from the users :) > > Of course, one common directory i.e /etc/services_config (or anything > else with a better name) in all major distributions would be nice > thing. The place for system configuration is /etc. I have yet to see a really convincing example why /etc/sysconfig/ or /etc/default would win us anything. I am pretty sure that the vast majority of files in there are pretty much unnecessary and their configuration could be solved in a different way much nicer. So yeah, I'd push for phasing /etc/sysconfig out for most services, not standardize it. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
2011/4/14 "Jóhann B. Guðmundsson" : > On 04/14/2011 04:19 PM, Tomasz Torcz wrote: >>> /etc/sysconfig/xxx is mostly a Fedora/Red Hat idiom. I am pretty sure >>> > the Debian version of the boot scripts do not honour this request. >> Debian has mostly identical /etc/default/xxx. >> > > Perhaps the same team that look at /run changes can come back together > and discuss this problem reach consciousness amongst distro about the > right path and everbody fix it accordingly... I am afraid that something like that will not be possible in this case - I expect much resistance from the users :) Of course, one common directory i.e /etc/services_config (or anything else with a better name) in all major distributions would be nice thing. > > JBG > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On 04/14/2011 04:19 PM, Tomasz Torcz wrote: >> /etc/sysconfig/xxx is mostly a Fedora/Red Hat idiom. I am pretty sure >> > the Debian version of the boot scripts do not honour this request. >Debian has mostly identical /etc/default/xxx. > Perhaps the same team that look at /run changes can come back together and discuss this problem reach consciousness amongst distro about the right path and everbody fix it accordingly... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thu, Apr 14, 2011 at 05:31:35PM +0200, Lennart Poettering wrote: > On Thu, 14.04.11 16:35, Michal Hlavinka (mhlav...@redhat.com) wrote: > > > > > On Thursday, April 14, 2011 15:48:09 Lennart Poettering wrote: > > > On Thu, 14.04.11 14:51, Michal Hlavinka (mhlav...@redhat.com) wrote: > > > > > > > > > > > On Thursday, April 14, 2011 13:26:02 Michal Schmidt wrote: > > > > > On 04/14/2011 11:14 AM, Michal Hlavinka wrote: > > > > > > d) split it to more service files and make dependency there > > > > > > > > > > > > this would be incompatible change in configuration and hard to do, > > > > > > > > > > Hard maybe, but solvable. Incompatibility happens from time to time. > > > > > That's what release notes are for. > > > > > > > > Upstream has their cross-distribution packaging "guidelines" / effort / > > > > ... > > > > (I can't find the proper description.) Making configuration work > > > > different > > > > way then on other systems won't make anyone happy. If there is a way to > > > > keep current configuration working, then it's the way it will be done. > > > > Option c) > > > > would work, I'm just looking for another possibility to make it work > > > > the same > > > > way but also more systemd-like way. > > > > > > I presume their guidelines just cover SysV-style bootups? > > > > It's not only about SysV, but also says something like: when user starts > > nut, it should > > start exactly those services that are needed based on > > /etc/sysconfig/nut MODE=? option > > /etc/sysconfig/xxx is mostly a Fedora/Red Hat idiom. I am pretty sure > the Debian version of the boot scripts do not honour this request. Debian has mostly identical /etc/default/xxx. > > Also I don't see how is this different from for example dovecot (pop3 and > > imap server) > > where master process starts auth, imapd, pop3d,... there just is no master > > process. > > This was handled by init script, because it was sufficient for this job. So > > it seems that > > systemd is not capable of doing this and "master" script will solve > > this. > > Dovecot upstream actually comes with systemd support including socket > activation. I haven't tried it myself but it sounds as if dovecot is > perfectly compatible with systemd ;-) I'm using F15 dovecot package on F14. Works perfectly. (F14 dovecot package omits unit files). -- Tomasz Torcz ,,(...) today's high-end is tomorrow's embedded processor.'' xmpp: zdzich...@chrome.pl -- Mitchell Blank on LKML -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On 04/14/2011 03:36 PM, Lennart Poettering wrote: >> In man systemd.unit >> > >> > BindTo= >> > Configures requirement dependencies, very similar in style >> > to Requires=, however in addition to this behaviour it also >> > declares that this unit is stopped when any of the units >> > listed suddenly disappears. Units can suddenly, unexpectedly >> > disappear if a service terminates on its own choice, a >> > device is unplugged or a mount point unmounted without involvement of >> > systemd. >> > >> > ExecStop=-/bin/systemctl stop upsd-device.service >> > ExecStop=-/bin/systemctl stop upsd-monitor.service > Why ExecStop= here? It was meant as an either or. The BindTo= reference in the man page does not mention that it will take down with it any service bound to it when the service is stop. The man page only states that if any of the service bound to it for one reason or another fails the service will be stopped at least that's the meaning I get when reading the BindTo= section in systemd.unit JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
W dniu 14 kwietnia 2011 17:53 użytkownik Reindl Harald napisał: > > Am 14.04.2011 17:38, schrieb Michał Piotrowski: > >> I hope that it works this way only on NTFS and do not attempt to free >> unused Ext4 space :) > > why should the FS matter for the physical layer under the FS? How you want to know which block can be freed without the knowledge about blocks allocated by file system? > > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
2011/4/14 Bryn M. Reeves : > On 04/14/2011 04:38 PM, Michał Piotrowski wrote: >> 2011/4/14 Jason D. Clinton : >>> 2011/4/14 Bruno Wolff III On Thu, Apr 14, 2011 at 16:53:00 +0200, Michał Piotrowski wrote: > "Fixed a rare condition that could cause the drive to reset and clear > the data" > > I begin to wonder if it was the right decision to change main drive to > SSD :) > > Maybe it's time to start using data=journal If you want to read some scary stuff some SSDs do take a look at the following comment from LWN: http://lwn.net/Articles/437467/ >>> >>> All the "compacting" firmwares on all SSD's do this. >>> >>> >> >> I hope that it works this way only on NTFS and do not attempt to free >> unused Ext4 space :) >> > > Dan Berrangé and I were just wondering how it "knows" it's NTFS; what happens > for e.g. if you put an image of an NTFS volume inside an ext4 volume on one of > these things? Good question. It would be good if it was possible to disable such "feature". > > Kinda brings back memories of reiserfsck fun. > > Regards, > Bryn. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
Am 14.04.2011 17:38, schrieb Michał Piotrowski: > I hope that it works this way only on NTFS and do not attempt to free > unused Ext4 space :) why should the FS matter for the physical layer under the FS? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
2011/4/14 Adam Williamson : > On Thu, 2011-04-14 at 09:15 +0200, Michał Piotrowski wrote: >> Hi, >> >> I experienced a small loss of power during commiting to a git repo. > > I can't resist...how does a 'small' loss of power differ from a 'large' > loss of power? :) 'small' is for a few milliseconds/seconds 'large' is for a few minutes/hours :) > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org > http://www.happyassassin.net > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
On 04/14/2011 04:38 PM, Adam Williamson wrote: > On Thu, 2011-04-14 at 09:15 +0200, Michał Piotrowski wrote: >> Hi, >> >> I experienced a small loss of power during commiting to a git repo. > > I can't resist...how does a 'small' loss of power differ from a 'large' > loss of power? :) Haha only-serious but in my (probably outdated dead-tree :) book: Small loss of power: Enough to get the smoothing caps draining and kick up some wobble on the rails (might make your DRAMs go nuts). Aka a brownout. Large loss of power: Fetch the candles! (a blackout!). ;) Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
On 04/14/2011 04:38 PM, Michał Piotrowski wrote: > 2011/4/14 Jason D. Clinton : >> 2011/4/14 Bruno Wolff III >>> >>> On Thu, Apr 14, 2011 at 16:53:00 +0200, >>> Michał Piotrowski wrote: "Fixed a rare condition that could cause the drive to reset and clear the data" I begin to wonder if it was the right decision to change main drive to SSD :) Maybe it's time to start using data=journal >>> >>> If you want to read some scary stuff some SSDs do take a look at the >>> following >>> comment from LWN: http://lwn.net/Articles/437467/ >> >> All the "compacting" firmwares on all SSD's do this. >> >> > > I hope that it works this way only on NTFS and do not attempt to free > unused Ext4 space :) > Dan Berrangé and I were just wondering how it "knows" it's NTFS; what happens for e.g. if you put an image of an NTFS volume inside an ext4 volume on one of these things? Kinda brings back memories of reiserfsck fun. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
On Thu, 2011-04-14 at 09:15 +0200, Michał Piotrowski wrote: > Hi, > > I experienced a small loss of power during commiting to a git repo. I can't resist...how does a 'small' loss of power differ from a 'large' loss of power? :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
2011/4/14 Jason D. Clinton : > 2011/4/14 Bruno Wolff III >> >> On Thu, Apr 14, 2011 at 16:53:00 +0200, >> Michał Piotrowski wrote: >> > "Fixed a rare condition that could cause the drive to reset and clear >> > the data" >> > >> > I begin to wonder if it was the right decision to change main drive to >> > SSD :) >> > >> > Maybe it's time to start using data=journal >> >> If you want to read some scary stuff some SSDs do take a look at the >> following >> comment from LWN: http://lwn.net/Articles/437467/ > > All the "compacting" firmwares on all SSD's do this. > > I hope that it works this way only on NTFS and do not attempt to free unused Ext4 space :) -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thu, 14.04.11 14:57, "Jóhann B. Guðmundsson" (johan...@gmail.com) wrote: > > On 04/14/2011 02:35 PM, Michal Hlavinka wrote: > > If I use Requires= directive, it starts driver for upsd, but is it possible > > to specify to > > stop the driver when upsd stops? > > > > I think that you would use BindTo= instead of Requires= in upsd.service > ( that is if uspd is depend upon them being running = ) along with ExecStop= > > In man systemd.unit > > BindTo= > Configures requirement dependencies, very similar in style > to Requires=, however in addition to this behaviour it also > declares that this unit is stopped when any of the units > listed suddenly disappears. Units can suddenly, unexpectedly > disappear if a service terminates on its own choice, a > device is unplugged or a mount point unmounted without involvement of > systemd. > > ExecStop=-/bin/systemctl stop upsd-device.service > ExecStop=-/bin/systemctl stop upsd-monitor.service Why ExecStop= here? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thu, 14.04.11 16:35, Michal Hlavinka (mhlav...@redhat.com) wrote: > > On Thursday, April 14, 2011 15:48:09 Lennart Poettering wrote: > > On Thu, 14.04.11 14:51, Michal Hlavinka (mhlav...@redhat.com) wrote: > > > > > > > > On Thursday, April 14, 2011 13:26:02 Michal Schmidt wrote: > > > > On 04/14/2011 11:14 AM, Michal Hlavinka wrote: > > > > > d) split it to more service files and make dependency there > > > > > > > > > > this would be incompatible change in configuration and hard to do, > > > > > > > > Hard maybe, but solvable. Incompatibility happens from time to time. > > > > That's what release notes are for. > > > > > > Upstream has their cross-distribution packaging "guidelines" / effort / > > > ... > > > (I can't find the proper description.) Making configuration work > > > different > > > way then on other systems won't make anyone happy. If there is a way to > > > keep current configuration working, then it's the way it will be done. > > > Option c) > > > would work, I'm just looking for another possibility to make it work the > > > same > > > way but also more systemd-like way. > > > > I presume their guidelines just cover SysV-style bootups? > > It's not only about SysV, but also says something like: when user starts nut, > it should > start exactly those services that are needed based on > /etc/sysconfig/nut MODE=? option /etc/sysconfig/xxx is mostly a Fedora/Red Hat idiom. I am pretty sure the Debian version of the boot scripts do not honour this request. > Also I don't see how is this different from for example dovecot (pop3 and > imap server) > where master process starts auth, imapd, pop3d,... there just is no master > process. > This was handled by init script, because it was sufficient for this job. So > it seems that > systemd is not capable of doing this and "master" script will solve > this. Dovecot upstream actually comes with systemd support including socket activation. I haven't tried it myself but it sounds as if dovecot is perfectly compatible with systemd ;-) > > If upsd strictly requires ups driver, then a Requires= directive in its > > unit file is a good idea. > > If I use Requires= directive, it starts driver for upsd, but is it possible > to specify to > stop the driver when upsd stops? Yes, as was pointed out BindTo= can do that for you. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On 04/14/2011 03:14 PM, Michał Piotrowski wrote: > I had such situation when I worked on shorewall scripts conversion. I > just didn't converted main shorewall-init script. At that time, I just > did not have idea how to run bash loop in systemd service:) Using bash loop within systemd is and should be only done because of absolute necessity for oddball cases and is a clear indicator if used that something needs fixing. If upstream is unwilling to do the necessary work to fix the broken behaviour in their service then it's better to not convert the files to systemd et all and just use continue to use the sysv script as is. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
2011/4/14 Bruno Wolff III > On Thu, Apr 14, 2011 at 16:53:00 +0200, > Michał Piotrowski wrote: > > "Fixed a rare condition that could cause the drive to reset and clear the > data" > > > > I begin to wonder if it was the right decision to change main drive to > SSD :) > > > > Maybe it's time to start using data=journal > > If you want to read some scary stuff some SSDs do take a look at the > following > comment from LWN: http://lwn.net/Articles/437467/ > All the "compacting" firmwares on all SSD's do this. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
On Thu, Apr 14, 2011 at 16:53:00 +0200, Michał Piotrowski wrote: > "Fixed a rare condition that could cause the drive to reset and clear the > data" > > I begin to wonder if it was the right decision to change main drive to SSD :) > > Maybe it's time to start using data=journal If you want to read some scary stuff some SSDs do take a look at the following comment from LWN: http://lwn.net/Articles/437467/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
Hi, 2011/4/14 Michal Hlavinka : > On Thursday, April 14, 2011 14:46:01 Jóhann B. Guðmundsson wrote: >> On 04/14/2011 12:51 PM, Michal Hlavinka wrote: >> > >> >> Can you elaborate on this? >> > a) ups driver - runs when you have ups attached to that host >> > b) upsd - runs when you have ups attached to that host >> > c) upsmon (master/slave mode) - usualy runs on machine where you have ups, >> > but it can run >> > on machine without ups or work with different ups than the attached one >> > >> >> Looking at the old sysv it only does 2 things... > > As I said above - don't look at init script for analyzation because there > are some options > missing right now, there was going to be some change to support other use > cases. > It's better to focus on theoretical situation where you have 3 daemons > started by one script based on one option in config file. That's all I had such situation when I worked on shorewall scripts conversion. I just didn't converted main shorewall-init script. At that time, I just did not have idea how to run bash loop in systemd service :) > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thursday, April 14, 2011 14:46:01 Jóhann B. Guðmundsson wrote: > On 04/14/2011 12:51 PM, Michal Hlavinka wrote: > > > >> Can you elaborate on this? > > a) ups driver - runs when you have ups attached to that host > > b) upsd - runs when you have ups attached to that host > > c) upsmon (master/slave mode) - usualy runs on machine where you have ups, > > but it can run > > on machine without ups or work with different ups than the attached one > > > > Looking at the old sysv it only does 2 things... As I said above - don't look at init script for analyzation because there are some options missing right now, there was going to be some change to support other use cases. It's better to focus on theoretical situation where you have 3 daemons started by one script based on one option in config file. That's all -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On 04/14/2011 02:35 PM, Michal Hlavinka wrote: > If I use Requires= directive, it starts driver for upsd, but is it possible > to specify to > stop the driver when upsd stops? > I think that you would use BindTo= instead of Requires= in upsd.service ( that is if uspd is depend upon them being running = ) along with ExecStop= In man systemd.unit BindTo= Configures requirement dependencies, very similar in style to Requires=, however in addition to this behaviour it also declares that this unit is stopped when any of the units listed suddenly disappears. Units can suddenly, unexpectedly disappear if a service terminates on its own choice, a device is unplugged or a mount point unmounted without involvement of systemd. ExecStop=-/bin/systemctl stop upsd-device.service ExecStop=-/bin/systemctl stop upsd-monitor.service JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
W dniu 14 kwietnia 2011 15:59 użytkownik Eric Sandeen napisał: > On 4/14/11 8:50 AM, Michał Piotrowski wrote: >> W dniu 14 kwietnia 2011 15:42 użytkownik Eric Sandeen >> napisał: > > > ... > > >>> What kind of SSD is it? >> >> OCZ Vertex 2 with firmware 1.25 (this is not the latest version, but I >> did not have too much courage to update it :)) > > Ok. We (the ext4 list) had a report a year ago or so where someone had > really debugged some odd behavior with one ssd and its firmware, but not this > one :) > > So not the same thing exactly, at least. > >> [ 1.548188] ata3.00: ATA-8: OCZ-VERTEX2, 1.25, max UDMA/133 >> [ 1.548196] ata3.00: 97696368 sectors, multi 16: LBA48 NCQ (depth 0/32) >> [ 1.586184] ata3.00: configured for UDMA/133 >> [ 1.586599] scsi 2:0:0:0: Direct-Access ATA OCZ-VERTEX2 >> 1.25 PQ: 0 ANSI: 5 >> [ 1.587295] sd 2:0:0:0: Attached scsi generic sg0 type 0 >> [ 1.587354] sd 2:0:0:0: [sda] 97696368 512-byte logical blocks: >> (50.0 GB/46.5 GiB) >> [ 1.587835] sd 2:0:0:0: [sda] Write Protect is off >> [ 1.587844] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00 >> >> So far, I have not any problems with this drive (not counting not >> working S.M.A.R.T. log). >> >>> SSDs being rather new beasts, with various different firmware >>> implementations it's also possible that a barrier was ignored, etc... >>> but hard to say. >> >> Do the barriers are somehow dependent on the hardware? Maybe I need to >> look in the SSD documentation to find out if proper commands are >> supported? > > I don't think you'll find that sort of thing; it's a question of implementing > the spec properly, really. All I meant is that it is -possible- for hardware > to be broken or noncompliant, so it's -possible- that that's what you're > seeing. I'm NOT saying that the OCZ-VERTEX2 -is- broken, just musing that > the hardware needs to exhibit proper behavior as much as the application > needs to issue the right data integrity syscalls. :) I think I'll try to update firmware on this drive over the weekend. When I read things like that in firmware release notes "Fixed rare corner case that could cause the drive to reset and clear user data" "Fixed a rare condition that could cause the drive to reset and clear the data" I begin to wonder if it was the right decision to change main drive to SSD :) Maybe it's time to start using data=journal > > -Eric > >>> >>> -Eric > -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On 04/14/2011 12:51 PM, Michal Hlavinka wrote:
>
>> Can you elaborate on this?
> a) ups driver - runs when you have ups attached to that host
> b) upsd - runs when you have ups attached to that host
> c) upsmon (master/slave mode) - usualy runs on machine where you have ups,
> but it can run
> on machine without ups or work with different ups than the attached one
>
Looking at the old sysv it only does 2 things...
if the $SERVER = yes in /etc/sysconfig/ups then start upsd driver upsd
and upsd monitor.
If the $SERVER != yes in /etc/sysconfig/ups then only start the monitor
service
start() {
if [ "$SERVER" = "yes" ]; then
echo -n $"Starting UPS driver controller: "
daemon /sbin/upsdrvctl start > /dev/null 2>&1 &&
success || failure
RETVAL=$?
echo
prog="upsd"
echo -n $"Starting $prog: "
daemon /usr/sbin/upsd $UPSD_OPTIONS > /dev/null 2>&1 &&
success || failure
if [ "$RETVAL" = 0 ]; then
RETVAL=$?
fi
echo
echo -n $"Starting UPS monitor (master): "
daemon --pidfile /var/run/nut/upsmon.pid
/usr/sbin/upsmon > /dev/null 2>&1 && success || failure
if [ "$RETVAL" = 0 ]; then
RETVAL=$?
fi
echo
else
echo -n $"Starting UPS monitor (slave): "
daemon --pidfile /var/run/nut/upsmon.pid
/usr/sbin/upsmon > /dev/null 2>&1 && success || failure
echo
fi
[ "$RETVAL" = 0 ] && touch /var/lock/subsys/ups
}
The only difference between usps-monitor in master mode and slave mode
is the "echo (master)"/"echo (slave)"
Now I've splitted this into three systemd services upsd.service
upsd-driver.service and upsd-monitor
upsd.service which if run will start uspd upsd-driver and the
upsd-monitor this is the same behavior as if $SERVER = yes
upsd-driver.service is stand alone and can be started stopped etc all by
it self
upsd-monitor.service is stand alone and can be started stopped etc all
by it self.
Starting this service on it's own is the exact same behaviour if $SERVER
!= yes
This is as close and as correct transfer to systemd as it gets.
The $SERVER variable in /etc/sysconfig/ups is obsoleted
If end users wants the uspd server ( which by the way defaulted to yes
so this even is not a breakage in default behaviour ) they only need to run
service upsd start or systemctl start upsd.service just ast they did before.
If they just want to use the monitor they just start the UPS Monitor
service
And now they can even start the UPS driver controller only which they
could not before.
JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thursday, April 14, 2011 15:48:09 Lennart Poettering wrote: > On Thu, 14.04.11 14:51, Michal Hlavinka (mhlav...@redhat.com) wrote: > > > > > On Thursday, April 14, 2011 13:26:02 Michal Schmidt wrote: > > > On 04/14/2011 11:14 AM, Michal Hlavinka wrote: > > > > d) split it to more service files and make dependency there > > > > > > > > this would be incompatible change in configuration and hard to do, > > > > > > Hard maybe, but solvable. Incompatibility happens from time to time. > > > That's what release notes are for. > > > > Upstream has their cross-distribution packaging "guidelines" / effort / ... > > (I can't find the proper description.) Making configuration work different > > way then on other systems won't make anyone happy. If there is a way to > > keep current configuration working, then it's the way it will be done. > > Option c) > > would work, I'm just looking for another possibility to make it work the > > same > > way but also more systemd-like way. > > I presume their guidelines just cover SysV-style bootups? It's not only about SysV, but also says something like: when user starts nut, it should start exactly those services that are needed based on /etc/sysconfig/nut MODE=? option In old script one just say he wants to use mode foo and script starts required services (one of the free). Also I don't see how is this different from for example dovecot (pop3 and imap server) where master process starts auth, imapd, pop3d,... there just is no master process. This was handled by init script, because it was sufficient for this job. So it seems that systemd is not capable of doing this and "master" script will solve this. > > > > > > What kind of dependencies exist between the three services? Are they 3 > > > separate daemons? How exactly do they communicate with each other? > > > > upsd requires ups driver, upsmon requires upsd (but can be upsd from > > different machine), > > on machine where upsd and ups driver run there usualy is upsmon, but > > it can be on different machine. > > If upsd strictly requires ups driver, then a Requires= directive in its > unit file is a good idea. If I use Requires= directive, it starts driver for upsd, but is it possible to specify to stop the driver when upsd stops? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [perl] Filter *.so at the start of spec.
> When you do an update for F-15, please add the following builds to it, > which remove the bogus perl(UNIVERSAL) provides: > > perl-UNIVERSAL-exports-0.05-11.fc15 > perl-UNIVERSAL-moniker-0.08-14.fc15 > perl-UNIVERSAL-require-0.13-6.fc15 > > If they were pushed before the perl update, there'd be nothing left to > provide perl(UNIVERSAL). > > Paul. https://admin.fedoraproject.org/updates/perl-UNIVERSAL-require-0.13-6.fc15,perl-UNIVERSAL-moniker-0.08-14.fc15,perl-UNIVERSAL-exports-0.05-11.fc15,perl-5.12.3-157.fc15 -- Marcela Mašláňová BaseOS team Brno -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
On 4/14/11 8:50 AM, Michał Piotrowski wrote: > W dniu 14 kwietnia 2011 15:42 użytkownik Eric Sandeen > napisał: ... >> What kind of SSD is it? > > OCZ Vertex 2 with firmware 1.25 (this is not the latest version, but I > did not have too much courage to update it :)) Ok. We (the ext4 list) had a report a year ago or so where someone had really debugged some odd behavior with one ssd and its firmware, but not this one :) So not the same thing exactly, at least. > [1.548188] ata3.00: ATA-8: OCZ-VERTEX2, 1.25, max UDMA/133 > [1.548196] ata3.00: 97696368 sectors, multi 16: LBA48 NCQ (depth 0/32) > [1.586184] ata3.00: configured for UDMA/133 > [1.586599] scsi 2:0:0:0: Direct-Access ATA OCZ-VERTEX2 > 1.25 PQ: 0 ANSI: 5 > [1.587295] sd 2:0:0:0: Attached scsi generic sg0 type 0 > [1.587354] sd 2:0:0:0: [sda] 97696368 512-byte logical blocks: > (50.0 GB/46.5 GiB) > [1.587835] sd 2:0:0:0: [sda] Write Protect is off > [1.587844] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00 > > So far, I have not any problems with this drive (not counting not > working S.M.A.R.T. log). > >> SSDs being rather new beasts, with various different firmware >> implementations it's also possible that a barrier was ignored, etc... >> but hard to say. > > Do the barriers are somehow dependent on the hardware? Maybe I need to > look in the SSD documentation to find out if proper commands are > supported? I don't think you'll find that sort of thing; it's a question of implementing the spec properly, really. All I meant is that it is -possible- for hardware to be broken or noncompliant, so it's -possible- that that's what you're seeing. I'm NOT saying that the OCZ-VERTEX2 -is- broken, just musing that the hardware needs to exhibit proper behavior as much as the application needs to issue the right data integrity syscalls. :) -Eric >> >> -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thu, 14.04.11 09:51, Simo Sorce (sso...@redhat.com) wrote: > Systemd needs to offer a way to handle these situation until most > distributions decide to adopt systemd. Because upstream has to deal > primarily with sysvinit, and many will not care about systemd until it > is widespread. The way it looks from the big names only Ubuntu ist left which is not working on systemd adoption in their distro. > You cannot expect package maintainers to heavily patch software and > even change how it behaves or how it is configured just because Fedora > decided to use systemd. Well, you can always continue to use sysv scripts if you want sysv behaviour. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thu, 14 Apr 2011 15:28:28 +0200 Lennart Poettering wrote: > On Thu, 14.04.11 12:55, Michal Hlavinka (mhlav...@redhat.com) wrote: > > > > > On Thursday, April 14, 2011 09:54:59 Jóhann B. Guðmundsson wrote: > > > > > > > Is there a good solution for this? > > > > > > Which service ( file ) is this. > > > > > > I can take a look at to see which way is best to approach it. > > > > It's package nut : /etc/init.d/ups, there are 3 services: driver, > > upsd and upsmon. All three services usually run on the same > > machine, but it's not the only use case. There is going to be > > slight change for yet another use case. Better not to get inspired > > by init script, but think about situation where there are three > > services and some/all of them should be started based on variable > > in config file (so existing configuration works). > > I think it is a good idea to enable/disable services only at once > place, the init system, instead of adding additional per-service > layers of disabling. An admin should not have to know how each > service is specifically configured in detail just to enable or > disable it. While this make sense in abstract, it may fall short when it comes to specific cases. It really comes down to defining "service". For an admin "service" is generally a (set of) program(s) that performs a function. Whether the service requires one or three daemons is generally not really interesting for the admin unless he wants to dig the details. In particular having to know which of three daemons to enable given a specific configuration is burdensome, as the admin now have to learn which one is required depending on the configuration. For some services this may be straightforward, for others not. And being forced to learn that is not really nice, esp. if it was not necessary before. It is particularly obnoxious if you have to remember to change a different configuration (the init system) if you are just changing your service configuration. > That means: if the admin enabels a service in systemd, the startup > script should not refuse starting just because it is disabled in > another config layer. That would be very confusing. And yet the contrary is also true, see above. Systemd needs to offer a way to handle these situation until most distributions decide to adopt systemd. Because upstream has to deal primarily with sysvinit, and many will not care about systemd until it is widespread. You cannot expect package maintainers to heavily patch software and even change how it behaves or how it is configured just because Fedora decided to use systemd. Where it is possible to easily switch to systmed, I am all for providing specific configuration and adaptation, but systemd needs to cater for the needs of software that is developed primarily on sysvinit based systems. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
W dniu 14 kwietnia 2011 15:42 użytkownik Eric Sandeen
napisał:
> On 4/14/11 4:27 AM, Michał Piotrowski wrote:
>> W dniu 14 kwietnia 2011 11:19 użytkownik Andreas Schwab
>> napisał:
>>> Michał Piotrowski writes:
>>>
W dniu 14 kwietnia 2011 11:04 użytkownik Andreas Schwab
napisał:
> Michał Piotrowski writes:
>
>> But the question remains - should enabled barriers protect against
>> such data loss/breakage? Or I just had a big bad luck?
>
> It could also be a bug in git, perhaps it needs to take more care to
> create the ref file atomically.
Should I report it to upstream or in bugzilla.redhat.com?
>>>
>>> Looking closer it seems like git already does the right thing
>>> (open("master.lock"), write(sha1), rename("master.lock", "master")), so
>>> it appears to be a barriers issue.
>>
>> Do you see something unusual here?
>>
>> [ 3.926076] EXT4-fs (sda1): INFO: recovery required on readonly filesystem
>> [ 3.926084] EXT4-fs (sda1): write access will be enabled during recovery
>> [ 4.655780] EXT4-fs (sda1): orphan cleanup on readonly fs
>> [ 4.655813] EXT4-fs (sda1): ext4_orphan_cleanup: deleting
>> unreferenced inode 269578
>> [ 4.656046] EXT4-fs (sda1): ext4_orphan_cleanup: deleting
>> unreferenced inode 131130
>> [ 4.656179] EXT4-fs (sda1): ext4_orphan_cleanup: deleting
>> unreferenced inode 13
>> [ 4.656250] EXT4-fs (sda1): ext4_orphan_cleanup: deleting
>> unreferenced inode 271833
>> [ 4.656380] EXT4-fs (sda1): ext4_orphan_cleanup: deleting
>> unreferenced inode 271832
>> [ 4.656455] EXT4-fs (sda1): ext4_orphan_cleanup: deleting
>> unreferenced inode 269763
>> [ 4.656633] EXT4-fs (sda1): ext4_orphan_cleanup: deleting
>> unreferenced inode 131082
>> [ 4.656696] EXT4-fs (sda1): 7 orphan inodes deleted
>> [ 4.656701] EXT4-fs (sda1): recovery complete
>> [ 4.667494] EXT4-fs (sda1): mounted filesystem with ordered data
>> mode. Opts: (null)
>>
>
> No, that's all normal recovery.
>
> What kind of SSD is it?
OCZ Vertex 2 with firmware 1.25 (this is not the latest version, but I
did not have too much courage to update it :))
[1.548188] ata3.00: ATA-8: OCZ-VERTEX2, 1.25, max UDMA/133
[1.548196] ata3.00: 97696368 sectors, multi 16: LBA48 NCQ (depth 0/32)
[1.586184] ata3.00: configured for UDMA/133
[1.586599] scsi 2:0:0:0: Direct-Access ATA OCZ-VERTEX2
1.25 PQ: 0 ANSI: 5
[1.587295] sd 2:0:0:0: Attached scsi generic sg0 type 0
[1.587354] sd 2:0:0:0: [sda] 97696368 512-byte logical blocks:
(50.0 GB/46.5 GiB)
[1.587835] sd 2:0:0:0: [sda] Write Protect is off
[1.587844] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
So far, I have not any problems with this drive (not counting not
working S.M.A.R.T. log).
> SSDs being rather new beasts, with various different firmware
> implementations it's also possible that a barrier was ignored, etc... but
> hard to say.
Do the barriers are somehow dependent on the hardware? Maybe I need to
look in the SSD documentation to find out if proper commands are
supported?
>
> -Eric
>
>>
>>>
It seems to me that the repairing git repo without a deep knowledge of
it can be rather difficult.
>>>
>>> gitrepository-layout(5)
>>
>> Thanks for the pointer
>>
>>>
>>> Andreas.
>>>
>>> --
>>> Andreas Schwab, sch...@redhat.com
>>> GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
>>> "And now for something completely different."
>>>
>>
>>
>>
>
>
--
Best regards,
Michal
http://eventhorizon.pl/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dependencies on mod_perl-devel in rawhide
On 11/04/11 22:28, Michael Schwendt wrote: > On Mon, 11 Apr 2011 11:00:07 +0200, Marcela wrote: > >>> mod_perl-devel erroneously provides perl(warnings), which means that >>> anything containing a perl script with "use warnings;" in it is liable >>> to pull it in. Should be easily fixable - I'll get on it. >>> >>> Paul. >> Fixed in mod_perl-2.0.5-3.fc16 > > Not the only one: > > perl-CPAN -> 'perl(base)' -> libgtk-java-devel > > libgtk-java-devel also provides tons of 'perl(...)' stuff. Fixed in libgtk-java-2.10.2-5.fc15. Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thu, 14.04.11 14:51, Michal Hlavinka (mhlav...@redhat.com) wrote: > > On Thursday, April 14, 2011 13:26:02 Michal Schmidt wrote: > > On 04/14/2011 11:14 AM, Michal Hlavinka wrote: > > > d) split it to more service files and make dependency there > > > > > > this would be incompatible change in configuration and hard to do, > > > > Hard maybe, but solvable. Incompatibility happens from time to time. > > That's what release notes are for. > > Upstream has their cross-distribution packaging "guidelines" / effort / ... > (I can't find the proper description.) Making configuration work different > way then on other systems won't make anyone happy. If there is a way to > keep current configuration working, then it's the way it will be done. Option > c) > would work, I'm just looking for another possibility to make it work the same > way but also more systemd-like way. I presume their guidelines just cover SysV-style bootups? Ideally the systemd unit files are shipped with the upstream packages. In this case if upstream is interested in keeping things identical among distributions it might be easy to convince them to integrate such a patch which gets things right? > > > > > > because dependency can change with configuration > > > > Can you elaborate on this? > > a) ups driver - runs when you have ups attached to that host > b) upsd - runs when you have ups attached to that host > c) upsmon (master/slave mode) - usualy runs on machine where you have ups, > but it can run > on machine without ups or work with different ups than the attached one > > > > > What kind of dependencies exist between the three services? Are they 3 > > separate daemons? How exactly do they communicate with each other? > > upsd requires ups driver, upsmon requires upsd (but can be upsd from > different machine), > on machine where upsd and ups driver run there usualy is upsmon, but > it can be on different machine. If upsd strictly requires ups driver, then a Requires= directive in its unit file is a good idea. > Somehow, but you still need to decide whether to start upsmon (which maybe > starts > upsd and the driver) or start just upsd and driver "manualy" without > upsmon. Levae that to the user by invoking "systemctl enable" on either both or just one of the units. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
On 4/14/11 4:27 AM, Michał Piotrowski wrote:
> W dniu 14 kwietnia 2011 11:19 użytkownik Andreas Schwab
> napisał:
>> Michał Piotrowski writes:
>>
>>> W dniu 14 kwietnia 2011 11:04 użytkownik Andreas Schwab
>>> napisał:
Michał Piotrowski writes:
> But the question remains - should enabled barriers protect against
> such data loss/breakage? Or I just had a big bad luck?
It could also be a bug in git, perhaps it needs to take more care to
create the ref file atomically.
>>>
>>> Should I report it to upstream or in bugzilla.redhat.com?
>>
>> Looking closer it seems like git already does the right thing
>> (open("master.lock"), write(sha1), rename("master.lock", "master")), so
>> it appears to be a barriers issue.
>
> Do you see something unusual here?
>
> [3.926076] EXT4-fs (sda1): INFO: recovery required on readonly filesystem
> [3.926084] EXT4-fs (sda1): write access will be enabled during recovery
> [4.655780] EXT4-fs (sda1): orphan cleanup on readonly fs
> [4.655813] EXT4-fs (sda1): ext4_orphan_cleanup: deleting
> unreferenced inode 269578
> [4.656046] EXT4-fs (sda1): ext4_orphan_cleanup: deleting
> unreferenced inode 131130
> [4.656179] EXT4-fs (sda1): ext4_orphan_cleanup: deleting
> unreferenced inode 13
> [4.656250] EXT4-fs (sda1): ext4_orphan_cleanup: deleting
> unreferenced inode 271833
> [4.656380] EXT4-fs (sda1): ext4_orphan_cleanup: deleting
> unreferenced inode 271832
> [4.656455] EXT4-fs (sda1): ext4_orphan_cleanup: deleting
> unreferenced inode 269763
> [4.656633] EXT4-fs (sda1): ext4_orphan_cleanup: deleting
> unreferenced inode 131082
> [4.656696] EXT4-fs (sda1): 7 orphan inodes deleted
> [4.656701] EXT4-fs (sda1): recovery complete
> [4.667494] EXT4-fs (sda1): mounted filesystem with ordered data
> mode. Opts: (null)
>
No, that's all normal recovery.
What kind of SSD is it? SSDs being rather new beasts, with various different
firmware implementations it's also possible that a barrier was ignored,
etc... but hard to say.
-Eric
>
>>
>>> It seems to me that the repairing git repo without a deep knowledge of
>>> it can be rather difficult.
>>
>> gitrepository-layout(5)
>
> Thanks for the pointer
>
>>
>> Andreas.
>>
>> --
>> Andreas Schwab, sch...@redhat.com
>> GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
>> "And now for something completely different."
>>
>
>
>
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thu, 14.04.11 12:55, Michal Hlavinka (mhlav...@redhat.com) wrote: > > On Thursday, April 14, 2011 09:54:59 Jóhann B. Guðmundsson wrote: > > > > > Is there a good solution for this? > > > > Which service ( file ) is this. > > > > I can take a look at to see which way is best to approach it. > > It's package nut : /etc/init.d/ups, there are 3 services: driver, upsd and > upsmon. > All three services usually run on the same machine, but it's not the only use > case. > There is going to be slight change for yet another use case. > Better not to get inspired by init script, but think about situation where > there are > three services and some/all of them should be started based on variable in > config > file (so existing configuration works). I think it is a good idea to enable/disable services only at once place, the init system, instead of adding additional per-service layers of disabling. An admin should not have to know how each service is specifically configured in detail just to enable or disable it. That means: if the admin enabels a service in systemd, the startup script should not refuse starting just because it is disabled in another config layer. That would be very confusing. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thu, 14.04.11 11:14, Michal Hlavinka (mhlav...@redhat.com) wrote:
>
> Hi,
>
> I have similar question (sorry for stealing this thread). I have package
> that has 3 services (they somehow depend on each other). Based on
> configuration in /etc/sysconfig/.. file it starts 2 or 3 services. This is
> handled by init script, but I don't know how to do it in systemd service
> file.
> AFAIK:
> a)
> EnvironmentFile=...
> ExecStart=[ -n "$DRIVER" ] && /start/driver/...
> ExecStart=[ -n "$BACKEND" ] && /start/backend/...
> ExecStart=[ -n "$MONITOR" ] && /start/monitor/...
In a systemd world we try to normalize how services are maintained and
managed. Ideally that means that you have a 1:1 mapping between service
files and actual daemons. So instead of having three daemons spawned
from a single sysv init script I'd encourage you to have three unit
files spawning three daemons.
This normalizes behaviour in many ways, for example the user can
individually enable/disable them, without an extra layer of enabling in
an extra config file.
We want a single place where services can be enabled/disabled, not
multiple at different layers.
Also, stuff like automatic restart and so on can only work correctly if
you maintain each daemon in a seperate systemd service.
> won't work, because ExecStart must be path, not shell command
>
> b)
> ExecStart=/usr/libexec/%{name}/startifset "$DRIVER" /start/driver
> ExecStart=/usr/libexec/%{name}/startifset "$BACKEND" /start/backend
> ExecStart=/usr/libexec/%{name}/startifset "$MONITOR" /start/monitor
>
> won't work, because there ExecStart can't be used more than once,
> except with type=oneshot, which does not work here
Yes, ExecStart= is for the "main" process of a service, the one which
determines the lifetime of it.
> d) split it to more service files and make dependency there
>
> this would be incompatible change in configuration and hard to do, because
> dependency can change with configuration
Yes, d)!
Our primary goal with systemd is to get things right and
normalized. Support the exact same behaviour as in SysV is not our top
goal, because well, we aren't sysvinit and to sport 100% identical
behaviour you'd have to be sysvinit.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thursday, April 14, 2011 13:26:02 Michal Schmidt wrote: > On 04/14/2011 11:14 AM, Michal Hlavinka wrote: > > d) split it to more service files and make dependency there > > > > this would be incompatible change in configuration and hard to do, > > Hard maybe, but solvable. Incompatibility happens from time to time. > That's what release notes are for. Upstream has their cross-distribution packaging "guidelines" / effort / ... (I can't find the proper description.) Making configuration work different way then on other systems won't make anyone happy. If there is a way to keep current configuration working, then it's the way it will be done. Option c) would work, I'm just looking for another possibility to make it work the same way but also more systemd-like way. > > > because dependency can change with configuration > > Can you elaborate on this? a) ups driver - runs when you have ups attached to that host b) upsd - runs when you have ups attached to that host c) upsmon (master/slave mode) - usualy runs on machine where you have ups, but it can run on machine without ups or work with different ups than the attached one > > What kind of dependencies exist between the three services? Are they 3 > separate daemons? How exactly do they communicate with each other? upsd requires ups driver, upsmon requires upsd (but can be upsd from different machine), on machine where upsd and ups driver run there usualy is upsmon, but it can be on different machine. > Can > they be patched to use socket activation? Because then you could simply > stop thinking about expressing the dependencies manually. Somehow, but you still need to decide whether to start upsmon (which maybe starts upsd and the driver) or start just upsd and driver "manualy" without upsmon. And as I said above, this must be done the way that won't break existing configuration. > Also note that there are two distinct kinds of dependencies: > requirements and ordering. I don't think ordering dependencies change > depending on the configuration, or do they? Somehow. Upsmon can require upsd or not based on configuration, but it does not say anything whether upsd should run or not (if it is not required). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On 04/14/2011 09:14 AM, Michal Hlavinka wrote: > Is there a good solution for this? The right solution is to split this into three service files as I have done in bug 696611 then simply run systemctl start/stop/restart/reload/enable upsd-master.service # for master ( which start the upsd-master and the upsd-driver service as was being done in the init script it will conflict with upsd-slave if it's running ) systemct start/stop/restart/reload/enable upsd-slave.service # for slave ( which will not start the upsd-driver service as was being done in the init script ) The upsd-driver should have been a seperate sysv service from the start from my pov but this is not the worst oddball I've come across... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 15 Virtualization Test Day -- Thu. April 14th
On Thu, Apr 14, 2011 at 14:00, Justin M. Forbes wrote: > This is just a reminder that today, April 14 is Fedora Virtualization > test day. Test plans and more information for the event can be found on > the Fedora Project Wiki at: > https://fedoraproject.org/wiki/Test_Day:2011-04-14_Virtualization > > IRC for the event on freenode in #fedora-test-day. Please come lend a > hand, we can use as many testers as possible. If you cannot make it > on Thursday, please feel free to run through test plans as you have > time,the feedback is still relevant and helps to make Fedora a better > platform for virtualization. The testcase pages for Spice seem to be empty. See for example: https://fedoraproject.org/wiki/QA:Testcase_Virtualization_Spice_VirtManager_Setup Maxim Burgerhout ma...@wzzrd.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Fedora 15 Virtualization Test Day -- Thu. April 14th
This is just a reminder that today, April 14 is Fedora Virtualization test day. Test plans and more information for the event can be found on the Fedora Project Wiki at: https://fedoraproject.org/wiki/Test_Day:2011-04-14_Virtualization IRC for the event on freenode in #fedora-test-day. Please come lend a hand, we can use as many testers as possible. If you cannot make it on Thursday, please feel free to run through test plans as you have time,the feedback is still relevant and helps to make Fedora a better platform for virtualization. Thanks, Justin ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
On 04/14/2011 05:19 AM, Andreas Schwab wrote:
> Michał Piotrowski writes:
>
>> W dniu 14 kwietnia 2011 11:04 użytkownik Andreas Schwab
>> napisał:
>>> Michał Piotrowski writes:
>>>
But the question remains - should enabled barriers protect against
such data loss/breakage? Or I just had a big bad luck?
>>> It could also be a bug in git, perhaps it needs to take more care to
>>> create the ref file atomically.
>> Should I report it to upstream or in bugzilla.redhat.com?
> Looking closer it seems like git already does the right thing
> (open("master.lock"), write(sha1), rename("master.lock", "master")), so
> it appears to be a barriers issue.
If the files exist, but do not have newly written data, you will still need an
fsync() in there somewhere I think
Barriers are responsible for meta-data, apps still need fsync() or fdatasync()
to commit the new user data.
Ric
>> It seems to me that the repairing git repo without a deep knowledge of
>> it can be rather difficult.
> gitrepository-layout(5)
>
> Andreas.
>
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On 04/14/2011 11:14 AM, Michal Hlavinka wrote: > d) split it to more service files and make dependency there > > this would be incompatible change in configuration and hard to do, Hard maybe, but solvable. Incompatibility happens from time to time. That's what release notes are for. I can imagine a %triggerun script looking at the old configuration file and then enabling the new services as required. > because dependency can change with configuration Can you elaborate on this? What kind of dependencies exist between the three services? Are they 3 separate daemons? How exactly do they communicate with each other? Can they be patched to use socket activation? Because then you could simply stop thinking about expressing the dependencies manually. Also note that there are two distinct kinds of dependencies: requirements and ordering. I don't think ordering dependencies change depending on the configuration, or do they? Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning irda-utils
As I have neither hardware to test nor time to give the package the needed love (i.e. init scripts) I've given up ownership of the irda-utils package. It's a package with 5 open bugs, two of them man page fixes, the other three initscript stuff that needs some work/testing. Karsten -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thursday, April 14, 2011 09:54:59 Jóhann B. Guðmundsson wrote: > > > Is there a good solution for this? > > Which service ( file ) is this. > > I can take a look at to see which way is best to approach it. It's package nut : /etc/init.d/ups, there are 3 services: driver, upsd and upsmon. All three services usually run on the same machine, but it's not the only use case. There is going to be slight change for yet another use case. Better not to get inspired by init script, but think about situation where there are three services and some/all of them should be started based on variable in config file (so existing configuration works). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
> Is there a good solution for this? Which service ( file ) is this. I can take a look at to see which way is best to approach it. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
W dniu 14 kwietnia 2011 11:19 użytkownik Andreas Schwab
napisał:
> Michał Piotrowski writes:
>
>> W dniu 14 kwietnia 2011 11:04 użytkownik Andreas Schwab
>> napisał:
>>> Michał Piotrowski writes:
>>>
But the question remains - should enabled barriers protect against
such data loss/breakage? Or I just had a big bad luck?
>>>
>>> It could also be a bug in git, perhaps it needs to take more care to
>>> create the ref file atomically.
>>
>> Should I report it to upstream or in bugzilla.redhat.com?
>
> Looking closer it seems like git already does the right thing
> (open("master.lock"), write(sha1), rename("master.lock", "master")), so
> it appears to be a barriers issue.
Do you see something unusual here?
[3.926076] EXT4-fs (sda1): INFO: recovery required on readonly filesystem
[3.926084] EXT4-fs (sda1): write access will be enabled during recovery
[4.655780] EXT4-fs (sda1): orphan cleanup on readonly fs
[4.655813] EXT4-fs (sda1): ext4_orphan_cleanup: deleting
unreferenced inode 269578
[4.656046] EXT4-fs (sda1): ext4_orphan_cleanup: deleting
unreferenced inode 131130
[4.656179] EXT4-fs (sda1): ext4_orphan_cleanup: deleting
unreferenced inode 13
[4.656250] EXT4-fs (sda1): ext4_orphan_cleanup: deleting
unreferenced inode 271833
[4.656380] EXT4-fs (sda1): ext4_orphan_cleanup: deleting
unreferenced inode 271832
[4.656455] EXT4-fs (sda1): ext4_orphan_cleanup: deleting
unreferenced inode 269763
[4.656633] EXT4-fs (sda1): ext4_orphan_cleanup: deleting
unreferenced inode 131082
[4.656696] EXT4-fs (sda1): 7 orphan inodes deleted
[4.656701] EXT4-fs (sda1): recovery complete
[4.667494] EXT4-fs (sda1): mounted filesystem with ordered data
mode. Opts: (null)
>
>> It seems to me that the repairing git repo without a deep knowledge of
>> it can be rather difficult.
>
> gitrepository-layout(5)
Thanks for the pointer
>
> Andreas.
>
> --
> Andreas Schwab, sch...@redhat.com
> GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
> "And now for something completely different."
>
--
Best regards,
Michal
http://eventhorizon.pl/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
Michał Piotrowski writes:
> W dniu 14 kwietnia 2011 11:04 użytkownik Andreas Schwab
> napisał:
>> Michał Piotrowski writes:
>>
>>> But the question remains - should enabled barriers protect against
>>> such data loss/breakage? Or I just had a big bad luck?
>>
>> It could also be a bug in git, perhaps it needs to take more care to
>> create the ref file atomically.
>
> Should I report it to upstream or in bugzilla.redhat.com?
Looking closer it seems like git already does the right thing
(open("master.lock"), write(sha1), rename("master.lock", "master")), so
it appears to be a barriers issue.
> It seems to me that the repairing git repo without a deep knowledge of
> it can be rather difficult.
gitrepository-layout(5)
Andreas.
--
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
"And now for something completely different."
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
W dniu 14 kwietnia 2011 11:04 użytkownik Andreas Schwab napisał: > Michał Piotrowski writes: > >> But the question remains - should enabled barriers protect against >> such data loss/breakage? Or I just had a big bad luck? > > It could also be a bug in git, perhaps it needs to take more care to > create the ref file atomically. Should I report it to upstream or in bugzilla.redhat.com? I have no problems with doing backups and restoring from them, but if it's a git problem, then someone in the future may be less fortunate. It seems to me that the repairing git repo without a deep knowledge of it can be rather difficult. > > Andreas. > > -- > Andreas Schwab, sch...@redhat.com > GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E > "And now for something completely different." > -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
Hi,
I have similar question (sorry for stealing this thread). I have package
that has 3 services (they somehow depend on each other). Based on
configuration in /etc/sysconfig/.. file it starts 2 or 3 services. This is
handled by init script, but I don't know how to do it in systemd service
file.
AFAIK:
a)
EnvironmentFile=...
ExecStart=[ -n "$DRIVER" ] && /start/driver/...
ExecStart=[ -n "$BACKEND" ] && /start/backend/...
ExecStart=[ -n "$MONITOR" ] && /start/monitor/...
won't work, because ExecStart must be path, not shell command
b)
ExecStart=/usr/libexec/%{name}/startifset "$DRIVER" /start/driver
ExecStart=/usr/libexec/%{name}/startifset "$BACKEND" /start/backend
ExecStart=/usr/libexec/%{name}/startifset "$MONITOR" /start/monitor
won't work, because there ExecStart can't be used more than once,
except with type=oneshot, which does not work here
c)
ExecStart=/usr/libexec/nut/startthemall
this is only workable solution I know (for now), but I don't know if it's the
best one
d) split it to more service files and make dependency there
this would be incompatible change in configuration and hard to do, because
dependency can change with configuration
Is there a good solution for this?
Michal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
Michał Piotrowski writes: > But the question remains - should enabled barriers protect against > such data loss/breakage? Or I just had a big bad luck? It could also be a bug in git, perhaps it needs to take more care to create the ref file atomically. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different." -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
W dniu 14 kwietnia 2011 10:42 użytkownik Andreas Schwab napisał: > Michał Piotrowski writes: > >> But I don't have this file in the repo that I restored from the backup. > > You do, in .git/packed-refs. You're right. But the question remains - should enabled barriers protect against such data loss/breakage? Or I just had a big bad luck? > > Andreas. > > -- > Andreas Schwab, sch...@redhat.com > GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E > "And now for something completely different." > -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
Michał Piotrowski writes: > But I don't have this file in the repo that I restored from the backup. You do, in .git/packed-refs. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different." -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
W dniu 14 kwietnia 2011 10:29 użytkownik Andreas Schwab napisał: > Michał Piotrowski writes: > >> Also git log says >> fatal: bad default revision 'HEAD' > > Looks like the only issue is that .git/refs/heads/master has been lost. Indeed, the file is empty. But I don't have this file in the repo that I restored from the backup. > > Andreas. > > -- > Andreas Schwab, sch...@redhat.com > GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E > "And now for something completely different." > -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
Michał Piotrowski writes: > Also git log says > fatal: bad default revision 'HEAD' Looks like the only issue is that .git/refs/heads/master has been lost. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different." -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
2011/4/14 Andreas Schwab : > Michał Piotrowski writes: > >> After turning system on I noticed that repo is totally broken. > > How do you define "totally broken"? All files in repo looks like added to commit, but not commited. # # Initial commit # # Changes to be committed: # (use "git rm --cached ..." to unstage) # list of over 5000 files to commit... Also git log says fatal: bad default revision 'HEAD' > > Andreas. > > -- > Andreas Schwab, sch...@redhat.com > GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E > "And now for something completely different." > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
Michał Piotrowski writes: > After turning system on I noticed that repo is totally broken. How do you define "totally broken"? Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different." -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
RE: Firefox releases, going forward
-Original Message- Sent: Thursday, April 14, 2011 9:55 AM Subject: Re: Firefox releases, going forward On Tue, Apr 12, 2011 at 12:20 PM, Chris Smart wrote: > Given that Mozilla is dramatically changing the development of Firefox > and making releases much more frequent - i.e. Firefox 5 due in July, 6 Further: http://blog.mozilla.com/blog/2011/04/13/new-channels-for-firefox-rapid-relea ses/ -c ** I reckon this is fantastic news for Firefox users. My only hope is that various Linux distributions can keep up with faster cycle of Firefox releases and include the updates in their repos. Because I can see that the current Firefox inclusion model, not only for Fedora but Ubuntu too, is seriously going to generate issues when Mozilla speeds up the release cycle of Firefox. Regards Chris Jones -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
Hi, I experienced a small loss of power during commiting to a git repo. After turning system on I noticed that repo is totally broken. Should barriers=1 protect from such a situation? (Fortunately I made a backup yesterday, so I just lost a couple of minutes :)) -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
