Re: [systemd-devel] Why does sysv generator translate Required-Start keyword into an After= ordering dep only ?

[Lukáš Nykrýn]

Francis Moreau píše v Po 07. 03. 2016 v 08:04 +0100:
> Hello,
> 
> Sorry for the long delay.
> 
> On Fri, Feb 26, 2016 at 5:05 AM, Andrei Borzenkov <
> arvidj...@gmail.com> wrote:
> > 26.02.2016 00:55, Francis Moreau пишет:
> > > 
> > > But now I'm wondering how the following case is handled: a
> > > sysinit
> > > script "a" has "Required-Start: b". But "b" is a native systemd
> > > service. I don't think the tool that enable/disable sysv services
> > > can
> > > enable and order correctly the native service.
> > > 
> > 
> > What difference does it make?
> 
> The difference is that in my current understanding nothing will pull
> "b" in.
> 
> Indeed "a" will have "After=b" ordering dep but that's not sufficient
> to start "b". And since "b" is native it will not have a "SXXb"
> installed by insserv.

IIRC the behavior is still the same as it always was. Chkconfig on (at
least rhel-based systems) did not enable the dependencies for the
service. It only assured that the services will be started in the
correct order.

The only script that cared about enabled dependencies was the
install_initd, which refused to install the initscript if its
requirements were not met.

If you want that behavior to change you should file a RFE to your
chkconfig/install_initd/systemd-sysv-install implementation.

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

Re: [systemd-devel] Proposal: Add biosdevname naming scheme to systemd

[Lukáš Nykrýn]

Jordan Hargrave píše v Čt 04. 02. 2016 v 13:24 -0600:
> 
> 
> On Tue, Oct 20, 2015 at 10:04 PM, Jordan Hargrave 
> wrote:
> > On Tue, Oct 20, 2015 at 3:02 PM, Andrei Borzenkov <
> > arvidj...@gmail.com> wrote:
> > > 20.10.2015 17:30, Jordan Hargrave пишет:
> > >
> > >> On Tue, Oct 20, 2015 at 1:15 AM, Andrei Borzenkov <
> > arvidj...@gmail.com>
> > >> wrote:
> > >>>
> > >>> On Tue, Oct 20, 2015 at 7:46 AM, Jordan Hargrave <
> > jhar...@gmail.com>
> > >>> wrote:
> > 
> >  On Mon, Mar 2, 2015 at 1:17 PM, Tom Gundersen 
> > wrote:
> > >
> > > Hi Jordan,
> > >
> > > On Mon, Mar 2, 2015 at 4:45 PM, Jordan Hargrave <
> > jhar...@gmail.com>
> > > wrote:
> > >>
> > >> There are currently two competing naming mechanisms for
> > network cards,
> > >> biosdevname and systemd.  Systemd currently has some
> > limitations on
> > >> naming
> > >> cards that use network partitioning or support SR-IOV.
> > >
> > >
> > > Could you point to an example so we can fix it? I thought all
> > bug
> > > reports had been handled, but maybe I lost track of
> > something.
> > >
> > 
> >  I have a quad-port NIC:
> >  :40:00.0 = PCIE bridge (SMBIOS Slot 2)
> >  :41:00.0 = Ethernet Device (port1)
> >  :41:00.1 = Ethernet Device (port2)
> >  :42:00.0 = Ethernet Device (port3)
> >  :42:00.1 = Ethernet Device (port4)
> > 
> >  biosdevname would name these p2p1, p2p2, p2p3, p2p4
> > respectively.
> > 
> > >>>
> > >>> How does it determine that 41 and 42 are the same device? I.e.
> > how
> > >>> does it differ from real bridge with two independent two-port
> > cards
> > >>> behind? Could you explain what information it is using? Is it
> > exported
> > >>> in sysfs?
> > >>>
> > >>> ...
> > >>
> > >>
> > >> It knows they are on the same slot as the parent device has
> > SMBIOS
> > >> Slot#2 (Type 9).  So all child devices of a physical slot are on
> > the
> > >> same card.  I'm currently using a patch to systemd that reads
> > SMBIOS
> > >> type 9.  There isn't a kernel sysfs variable that displays this.
> > >>
> > >
> > > This gives us slot ID, but how do we know which of function 0 on
> > this slot
> > > ID is port 0 and which is port 2? There is nothing in SMBIOS
> > description of
> > > Type 9 that answers it.
> > 
> > 
> Looking for a resolution for this.. adding port numbers to systemd
> enumeration of devices in PCI slots.
> 
> Systemd still doesn't have the concept of a 'Port' number, so multi
> -port NICs get named with enpsf instead of
> ensp.
> 
> There needs to be a way to generate systemd names that have the
> following variables for add-in cards:
>   Slot Number
>   Port Number
>   Instance Number (for SR-IOV or Network Partitioned devices)
> 
> It is possible to calculate the port number without any knowledge of
> sibling devices.  Requires knowledge of device PCI ID, parent tree
> and 'dev_port' attribute (for mellanox cards). Then the devices could
> be named ensSLOTpPORT

Aren't we already doing that with:

s[f][d] -- hotplug slot index number

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

Re: [systemd-devel] [packaging] split of systemd package

[Lukáš Nykrýn]

Zbigniew Jędrzejewski-Szmek píše v So 14. 11. 2015 v 02:14 +:
> Hi,
> 
> implementing the split in Fedora deserves a Changes page,
> because of the need to coordinate with other components of the
> distribution (comps, some packages, anaconda):
> https://fedoraproject.org/wiki/Changes/systemd_package_split
> 
> All the details are described on the Change page. If anything
> is missing/unclear, please let me know.

Hi,
I'm not currently near my laptop so I can't test it, but how are the
virtualization tools working without machined installed?

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

Re: [systemd-devel] [packaging] split of systemd package

[Lukáš Nykrýn]

Zbigniew Jędrzejewski-Szmek píše v Čt 12. 11. 2015 v 06:13 +:
> I prepared a package for rawhide with [1,2] the following
> subpackages:
> systemd-journal-remote (remote, upload, gatewayd)
> systemd-container (nspawn, machinectl, machined, importd, pull, var
> -lib-machines.mount)
> systemd-udev (udevd, udevadm, udev rules, hwdb).
> 
> The first two are uncontroversial (systemd-journal-remote already
> existed
> as systemd-journal-gateway for a long time).
> The last is somewhat controversial: while people seem to agree about
> the split,
> it's not necessary clear whether udevd should be in the subpackage or
> not.
> I went with "yes", to see how that works out. I think this makes more
> sense this way, but maybe not.

I would like to see the hwdb in its own package. I can imagine a use
-case where user wants to use udev, but wants to provide its own
smaller hwdb (or hwdb.bin).


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

Re: [systemd-devel] [packaging] split of systemd package

[Lukáš Nykrýn]

Zbigniew Jędrzejewski-Szmek píše v Čt 12. 11. 2015 v 05:42 +:
> On Wed, Nov 11, 2015 at 02:33:52PM +0100, Lukáš Nykrýn wrote:
> > > > systemd-firstboot (firstboot,sysusers?,factory stuff?)
> > > 
> > > I'd really not bother with this stuff. This should be in the
> > > base,
> > > and
> > > it is tiny. Plese leave this in the main package.
> > 
> > The only reason was that it pulls in libcrypt.
> libcrypt is provided by glibc, which is always installed, so
> splitting
> this out does not lead to any savings.
> 
> Zbyszek
> 

Yep I was probably wrong here. My reasoning was, that we have some
database of used crypto functionality in packages in rhel and we don't
use firstboot there, so for me it would be nice to drop this
dependency. But this is my specific usecase and we should push our
 firstboot in upstream more.

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

Re: [systemd-devel] [packaging] split of systemd package

[Lukáš Nykrýn]

> I thought the conscious was not recommending downstream to split
> systemd 
> into subpackages?
> 

I think the previous discussion was more about if we should split core
components of systemd like systemd-logind, which still should stay in
the main package. 

And most of distributions split their packages already, so it would be
nice to have some general recommendations.

Lukas


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

[systemd-devel] [packaging] split of systemd package

[Lukáš Nykrýn]

Hi,

During systemd.conf we have discussed some recommendation for
downstreams, how they could split systemd to subpackages, so lets
continue that discussion here.

Personally I don't think it makes sense to split the package to get a
smaller core package. Most of our binaries are just few KBs. Only
exception here is /usr/lib/udev/hwdb.d which, on fedora rawhide, has
about 5,2 MB (15% of the whole package).

Other aspect would be minimizing external dependencies. I have made a
list of libraries and which binaries pulls them in [1] and from that
point of view it would make sense to put follow binaries to subpackage:
systemd-pull
systemd-journal-gatewayd
systemd-journal-remote
systemd-journal-upload
systemd-firstboot
systemd-networkd

So I suggest following scheme

systemd
systemd-libs
systemd-devel
systemd-journal-remote (so gatewayd,remote,upload)
systemd-networkd (maybe also with resolved?)
systemd-machine (machined,nspawn,importd)
systemd-firstboot (firstboot,sysusers?,factory stuff?)
systemd-hwdb


Regards

Lukas


[1] https://gist.github.com/lnykryn/bd5de7d9ed39986d5147

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

Re: [systemd-devel] Backport git notes

[Lukáš Nykrýn]

Lennart Poettering píše v Čt 27. 08. 2015 v 18:02 +0200:
> Heya,
> 
> I used to add "Backport: bugfix" style "git notes" to systemd commits
> I deemed backport-worthy. These headers have not been added to any
> commits since we moved to github (primarily, because the notes 
> weren't
> ported over for quite some time). Nobody complained about this. Which
> makes me wonder if anyone actually cares.
> 
> Zbigniew, Michael, Martin, Lukasz, Michal, do you actually care for
> these git notes? Did you ever use them? Did you even know about them?
> 
> If nobody cares I can stop doing the work for them, of course, and
> less work I always like.
> 
> The git notes usage in our repo is documented here:
> 
> https://wiki.freedesktop.org/www/Software/systemd/Backports/
> 
> Lennart
> 

We have never did "mass backport", because most of them were irrelevant
for our ancient systemd in rhel. It is handy when I am looking for some
bugfix in upstream and the first step was to go through such patches.

By the way it might be a good topic for the conference to talk about
systemd and LTS distributions. Our 208 was quite un-maintainable just
after two years. Maybe LTS ubuntus and Debian stable will have similar
issues.

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

Re: [systemd-devel] SysVInit service migration to systemd

[Lukáš Nykrýn]

Lesley Kimmel píše v Pá 26. 06. 2015 v 08:15 -0500:
 Hi all;
 
 I've been working with RHEL5/6 for the past several years and have
 developed many init scripts/services which generally use lock files
 and PID files to allow for tracking of the service status. We are
 moving to RHEL7 (systemd) in the near future and I am looking for
 instruction or tutorials on how to effectively migrate these scripts
 to work with systemd. 

http://0pointer.de/blog/projects/systemd-for-admins-3.html

 
 I found https://wiki.archlinux.org/index.php/Systemd#Service_types
 which seems somewhat promising but it is fairly high-level. It looks
 like I may be able to use the 'forking' type with the 'pidfile'
 parameter to somewhat mimic what the scripts to today. However, I have
 a couple of questions:
 
 -How does systemd track whether it should be stopping a service at
 shutdown (analogous to the /var/lock/subsys files in SysVInit)?

Systemd tracks the services using cgroups, so it knows that the service
is running and needs to be stopped.

 -Are there merits to using the notify or dbus types? If so does anyone
 know of a tutorial I could use to get to that point? (FYI, I'm not a
 developer but I learn complicated things quickly).
 -If the current service logs to a custom, dedicated log is there a way
 to get systemd to provide the same type of output that it does for the
 built-in system services or must I make some modifications to
 integrate with journald?

Look at the Administrators Blog Series and Developers Series
https://wiki.freedesktop.org/www/Software/systemd/

 
 Thanks ahead of time,
 Lesley Kimmel, RHCE
 Linux/Unix Systems Engineer
 
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Regards
Lukas


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

Re: [systemd-devel] remote-fs dependency/ordering on network

[Lukáš Nykrýn]

Jan Synacek píše v Út 23. 06. 2015 v 15:39 +0200:
 Lennart Poettering lenn...@poettering.net writes:
 
  On Mon, 22.06.15 14:49, Jan Synacek (jsyna...@redhat.com) wrote:
 
  Lukáš Nykrýn lnyk...@redhat.com writes:
  
   Jan Synáček píše v Čt 18. 06. 2015 v 15:41 +0200:
   Is remote-fs.target somehow dependent/ordered on network.target or
   network-online.target? I can't find anything that would suggest it
   actually is.
   
   Cheers,
  
   If I am not mistaken remote-fs.target should be after all netdev mounts
   and netdev mounts should be after network-online.target.
  
  I'm sure it should, but I don't see any evidence that it really is. My
  mnt-nfs.mount that was generated by the fstab generator is ordered
  before remote-fs.target, which is correct. However, I can't find any
  dependency between remote-fs.target, and network*. I'm quite puzzled how
  NFS mounts mounted on boot can actually work correctly right now.
 
  There's also remote-fs-pre.target. That's ordered before all NFS
  mounts, and that's what the online stuff should be ordered before.
 
 All seems to be in order when the system is booting up. However, during
 shutdown, the order in which network* and remote* are taken down seems
 to be incorrect. If you could take a look at [1], that would help a bit,
 since I'm really clueless right now.
 
 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1214466
 
 Cheers,

There is something messed up on that system.

Jun 23 07:30:56 acer.greshko.com systemd[1523]: Fixing conflicting jobs
-.slice/start,-.slice/stop by deleting job -.slice/stop
Jun 23 07:30:56 acer.greshko.com systemd[1523]: Fixing conflicting jobs
shutdown.target/stop,shutdown.target/start by deleting job
shutdown.target/stop
Jun 23 07:30:56 acer.greshko.com systemd[1523]: Deleting job
-.slice/start as dependency of job shutdown.target/stop
Jun 23 07:30:56 acer.greshko.com systemd[1546]: Fixing conflicting jobs
shutdown.target/stop,shutdown.target/start by deleting job
shutdown.target/stop

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

Re: [systemd-devel] remote-fs dependency/ordering on network

[Lukáš Nykrýn]

Jan Synáček píše v Čt 18. 06. 2015 v 15:41 +0200:
 Is remote-fs.target somehow dependent/ordered on network.target or
 network-online.target? I can't find anything that would suggest it
 actually is.
 
 Cheers,

If I am not mistaken remote-fs.target should be after all netdev mounts
and netdev mounts should be after network-online.target.

Lukas

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

Re: [systemd-devel] [PATCH v2 1/2] systemctl: drop hardcoded chkconfig invocation

[Lukáš Nykrýn]

Lennart Poettering píše v Čt 28. 05. 2015 v 13:05 +0200:
 On Wed, 27.05.15 18:08, Martin Pitt (martin.p...@ubuntu.com) wrote:
 
  Hello again,
  
  as discussed previously this second variant of un-hardcoding chkconfig
  now uses the proposed /usr/lib/systemd/systemd-sysv-install
  abstraction.
  
  I also added a reference implementation for chkconfig which gets
  installed with --enable-chkconfig, so on Fedora this should be no
  net change.
 
 Nah, please remove this part. We should not ship that upstream. THis
 is something that Fedora's initscripts.rpm should provide eventually,
 and should be neither shipped with systemd upstream nor systemd.rpm in
 Fedora.

+1
I will patch chkconfig to handle this similarly as the install_initd.

 
  This doesn't have a manpage yet (as it's not an user-callable
  program); where should this be documented? Just adding to README?
 
 Well, you could put it on some fdo wiki page maybe and link this up
 from the source and from NEWS.
 
 Doesn't have to be too formal...
 
 Patch looks fine otherwise: just remove any trace of chkconfig.
 
 Lennart
 


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

Re: [systemd-devel] [PATCH 1/1] Ensure that /run/systemd/network exists

[Lukáš Nykrýn]

Lennart Poettering píše v St 27. 05. 2015 v 15:01 +0200:
 On Wed, 27.05.15 14:34, Martin Pitt (martin.p...@ubuntu.com) wrote:
 
  Hey Peter,
  
  Peter Lemenkov [2015-05-27 15:30 +0300]:
   This directory is used for storing transient/generated network service
   files. Unfortunately it doesn't generated during systemd-networkd
   startup. Let's fix that.
   ---
src/network/networkd.c | 3 +++
1 file changed, 3 insertions(+)
   
   diff --git a/src/network/networkd.c b/src/network/networkd.c
   index 543a4e4..a98855f 100644
   --- a/src/network/networkd.c
   +++ b/src/network/networkd.c
   @@ -67,6 +67,9 @@ int main(int argc, char *argv[]) {
if (r  0)
log_warning_errno(r, Could not create runtime directory 
   'lldp': %m);

   +/* Create a directory for the generated transient network 
   services */
   +mkdir_p(/run/systemd/network, 0755);
  
  Should that perhaps go into /usr/lib/tmpfiles.d/systemd.conf instead,
  together with the related
  
d /run/systemd/netif 0755 systemd-network systemd-network -
d /run/systemd/netif/links 0755 systemd-network systemd-network -
d /run/systemd/netif/leases 0755 systemd-network systemd-network -
  
  ?
 
 This would not suffice, as networkd can run in early-boot, but
 tmpfiles only runs after /var and friends have been mounted.
 
 Lennart

For some cases we need that directory really soon. For example for a
generator which creates a .link file that renames a device.

Lukas


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

Re: [systemd-devel] abstracting chkconfig vs. update-rc.d [was: non-merged /usr changes]

[Lukáš Nykrýn]

Lennart Poettering píše v St 27. 05. 2015 v 15:22 +0200:
 On Wed, 27.05.15 15:17, Martin Pitt (martin.p...@ubuntu.com) wrote:
 
  Hey Lennart,
  
  Lennart Poettering [2015-05-27 15:08 +0200]:
  /usr/lib/lsb/install_initd /etc/init.d/example.com-coffeed
  /usr/lib/lsb/remove_initd /etc/init.d/example.com-coffeed

So we could make systemctl just call this if it's available, and
otherwise do nothing for init.d scripts.
   
   Sounds OK to use something like this, that already exists.
   
   However, we actually need not only enabling/disabling, but also
   is-enabled support, and idea on that?
  
  My current version of the patch keeps the chkconfig implementation for
  now; I suppose we don't want to needlessly enforce a lockstep
  situation where you can't use systemd git on Fedora until these
  scripts exist.
 
 We barely have any init scripts left, this isn't really a big issue
 hence. I think it's no problem to require an update in lockstep for
 this for Fedora.
 
  LSB does not define an interface for checking whether an init.d script
  is enabled, and e. g. Debian's update-rc.d does not currently either
  (https://bugs.debian.org/705254).
  
  We certainly know whether an init.d script is enabled, as we check
  exactly that in the sysv-generator (and if it's disabled we don't
  create a .service for it). However, right now the systemctl is-enabled
  command will just give you a not supported with sysvinit error with
  --disable-chkconfig.
 
 I think it should be the hook that generates that error, not systemctl...
 
  
   Also, I'd like to keep Lukas Nykryn in the loop on this, our
   initscripts maintainer.
  
  Did you mean to CC: him?
 
 That was my intention, and I could bet I did add him.
 
 Lukas, I added you now, can you have a look at branch of the thread
 please?
 
 Lennart
 

We already have /usr/lib/lsb/install_initd in fedora and rhel, it is in 
redhat-lsb-core, but basically it is just a symlink to chkconfig.

But I would be careful about it. The main problem is, that according to
LSB install_initd requires that lsb dependencies are satisfied and
refuses to install an initscript if they are not.

Lukas



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

Re: [systemd-devel] abstracting chkconfig vs. update-rc.d [was: non-merged /usr changes]

[Lukáš Nykrýn]

Martin Pitt píše v St 27. 05. 2015 v 17:45 +0200:
 Hey Lukáš,
 
 Lukáš Nykrýn [2015-05-27 17:32 +0200]:
  We already have /usr/lib/lsb/install_initd in fedora and rhel, it is in
  redhat-lsb-core, but basically it is just a symlink to chkconfig.
 
 Ah, that's not technically correct, as
 /usr/lib/lsb/{install,remove}_initd have a different CLI.

In that case our chkconfig behaves differently:
https://git.fedorahosted.org/cgit/chkconfig.git/tree/chkconfig.c#n683

 
 But anyway, this is moot. We won't call those from systemd after all,
 but instead introduce /usr/lib/systemd/systemd-sysv-install.

Yep it probably make sense, in fedora we can do it as yet another alias
for chkconfig.

 
 Thanks!
 
 Martin

Lukas


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

Re: [systemd-devel] [PATCH] mount: don't run quotaon only for network filesystems

[Lukáš Nykrýn]

Lennart Poettering píše v Út 31. 03. 2015 v 19:30 +0200:
 On Mon, 30.03.15 14:42, Lukas Nykryn (lnyk...@redhat.com) wrote:
 
  If you havei for example ext4 on iscsi devices it is possible to setup
  qoutas there. Unfortunatelly because such fstab entry contains _netdev,
  systemd will not add dependency to quotaon.service.
 
 I think this really needs a comment next to this in the sources,
 otherwise this is likely to be changed back again the next time
 somebody reworks the code, because he doesn't realize this...
 
 Can you add a comment, please? Otherwise looks fine!
Added and pushed.

Thanks
Lukas

 
  ---
   src/core/mount.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
  
  diff --git a/src/core/mount.c b/src/core/mount.c
  index 1251c94..f7633b7 100644
  --- a/src/core/mount.c
  +++ b/src/core/mount.c
  @@ -102,7 +102,7 @@ static bool mount_is_auto(const MountParameters *p) {
   static bool needs_quota(const MountParameters *p) {
   assert(p);
   
  -if (mount_is_network(p))
  +if (p-fstype  fstype_is_network(p-fstype))
   return false;
   
   if (mount_is_bind(p))
  -- 
  1.8.3.1
  
  ___
  systemd-devel mailing list
  systemd-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/systemd-devel
 
 
 Lennart
 


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

Re: [systemd-devel] [PATCH] systemctl: list-units -r should not fail with older systemd in container

[Lukáš Nykrýn]

Lennart Poettering píše v Út 31. 03. 2015 v 19:28 +0200:
 On Tue, 31.03.15 16:10, Lukas Nykryn (lnyk...@redhat.com) wrote:
 
  Older version of systemd does not have d-bus method ListUnitsFiltered,
  so systemctl -r will fail just with:
 
 I think I'd really prefer if we'd simply fall back to ListUnits() in
 this case, and do the filtering client side only. In fact that's
 probably what we should have done in the first place anyway.
 
 I figure the patch to make this happen shouldn't be too complex,
 especially given that the original code did just that?
 
 Lennart
 
I am not sure if I understand your suggestion correctly, fall back in
the case that the machine does not haveListUnitsFiltered or basically
revert the original patch, which changed that (but leave the new dbus
method)?

Lukas

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

Re: [systemd-devel] experiments with 'minimal build'

[Lukáš Nykrýn]

Alison Chaiken píše v St 18. 03. 2015 v 00:07 -0700:
 After reading about the 'minimal build' on the systemd wiki, I decided
 to experiment.
 
 0. WIth basically all options turned on, in a Fedora 21 Qemu, systemd
 used about 300 MB of memory according to 'sudo memstat -p 1'.
 
 1. With ./configure --disable-gtk-doc --disable-seccomp
 --disable-selinux --disable-apparmor --disable-xz --disable-zlib
 --disable-pam --disable-acl --disable-smack --disable-gcrypt
 --disable-audit --disable-elfutils --disable-libcryptsetup
 --disable-qrencode --disable-microhttpd --disable-gnutls
 --disable-libcurl --disable-libidn  --disable-quotacheck
 --disable-vconsole --disable-logind --disable-machined
 --disable-importd --disable-hostnamed --disable-timedated
 --disable-localed --disable-polkit --disable-resolved
 --disable-networkd --disable-efi --disable-manpages
 --disable-hibernate --disable-tests
 
 [achaiken@localhost systemd (master)]$ ./systemd --version
 systemd 219
 -PAM -AUDIT -SELINUX +IMA -APPARMOR -SMACK +SYSVINIT +UTMP
 -LIBCRYPTSETUP -GCRYPT -GNUTLS -ACL -XZ -LZ4 -SECCOMP +BLKID -ELFUTILS
 +KMOD -IDN
 
 In this case, 'memstat -p 1' says systemd uses about 119 MB of memory.
 
 2. Reducing even further,
 
 ./configure --disable-gtk-doc --disable-seccomp --disable-selinux
 --disable-apparmor --disable-xz --disable-zlib --disable-pam
 --disable-acl --disable-smack --disable-gcrypt --disable-audit
 --disable-elfutils --disable-libcryptsetup --disable-qrencode
 --disable-microhttpd --disable-gnutls --disable-libcurl
 --disable-libidn  --disable-quotacheck --disable-vconsole
 --disable-logind --disable-machined --disable-importd
 --disable-hostnamed --disable-timedated --disable-localed
 --disable-polkit --disable-resolved --disable-networkd --disable-efi
 --disable-manpages --disable-hibernate --disable-tests  --disable-nls
 --disable-python-devel --disable-utmp --disable-xkbcommon
 --disable-ima --disable-blkid --disable-binfmt --disable-tmpfiles
 --disable-sysusers --disable-firstboot --disable-randomseed
 --disable-backlight --disable-rfkill --disable-timesyncd
 --disable-coredump --disable-myhostname
 [achaiken@localhost systemd (master)]$ ./systemd --version
 systemd 219
 -PAM -AUDIT -SELINUX -IMA -APPARMOR -SMACK +SYSVINIT -UTMP
 -LIBCRYPTSETUP -GCRYPT -GNUTLS -ACL -XZ -LZ4 -SECCOMP -BLKID -ELFUTILS
 +KMOD -IDN
 
 Now Qemu doesn't boot because Dependency failed for /boot
 Dependency failed for /home.   From emergency shell, 'journalctl -p
 err' shows 5 udev failures and 8 systemd ones.   /boot and /home are
 empty because fedora-home and the UUID-labelled object are absent in
 /dev/mapper.   The last successful target is Swap.
 
 Hypothesis: the failure happened because I turned BLKID off.   Does
 that sound right?   Does systemd not work without BLKID?   Would it
 work with BLKID off it it hadn't previously been on at installation?
 
You can run you system without blkid, just change fstab to use /dev/sd*
instead of UUIDs.


 Obviously this was a sandbox experiment and nothing valuable was lost,
 but nonetheless I'm curious.   I assume that turning off KMOD and
 perhaps SYSVINIT isn't safe either?
 
 Thanks for any suggestions,
 Alison
 
 


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

Re: [systemd-devel] [PATCH] console-getty.service: don't start when /dev/console is missing

[Lukáš Nykrýn]

Thanks for review. Applied.

Lukas

Zbigniew Jędrzejewski-Szmek píše v Po 16. 03. 2015 v 03:32 +0100:
 Looks reasonable.
 
 Zbyszek
 
 On Fri, Mar 13, 2015 at 12:57:18PM +0100, Lukas Nykryn wrote:
  From: Jan Pazdziora jpazdzi...@redhat.com
  
  Create minimal image which runs systemd
  
 FROM rhel7.1
 RUN yum install -y /usr/bin/ps
 ENV container docker
 CMD [ /usr/sbin/init ]
  
  When you run the container without -t, the process
  
 /sbin/agetty --noclear --keep-baud console 115200 38400 9600
  
  is not happy and checking the journal in the container, there is a stream of
  
  Mar 13 04:50:15 11bf07f59fff agetty[66]: /dev/console: No such file or 
  directory
  Mar 13 04:50:25 11bf07f59fff systemd[1]: console-getty.service holdoff time 
  over, scheduling restart.
  Mar 13 04:50:25 11bf07f59fff systemd[1]: Stopping Console Getty...
  Mar 13 04:50:25 11bf07f59fff systemd[1]: Starting Console Getty...
  Mar 13 04:50:25 11bf07f59fff systemd[1]: Started Console Getty.
  Mar 13 04:50:25 11bf07f59fff agetty[67]: /dev/console: No such file or 
  directory
  Mar 13 04:50:35 11bf07f59fff systemd[1]: console-getty.service holdoff time 
  over, scheduling restart.
  Mar 13 04:50:35 11bf07f59fff systemd[1]: Stopping Console Getty...
  Mar 13 04:50:35 11bf07f59fff systemd[1]: Starting Console Getty...
  Mar 13 04:50:35 11bf07f59fff systemd[1]: Started Console Getty.
  Mar 13 04:50:35 11bf07f59fff agetty[74]: /dev/console: No such file or 
  directory
  Mar 13 04:50:45 11bf07f59fff systemd[1]: console-getty.service holdoff time 
  over, scheduling restart.
  Mar 13 04:50:45 11bf07f59fff systemd[1]: Stopping Console Getty...
  Mar 13 04:50:45 11bf07f59fff systemd[1]: Starting Console Getty...
  ---
   units/console-getty.service.m4.in | 1 +
   1 file changed, 1 insertion(+)
  
  diff --git a/units/console-getty.service.m4.in 
  b/units/console-getty.service.m4.in
  index 8ac51a4..413d940 100644
  --- a/units/console-getty.service.m4.in
  +++ b/units/console-getty.service.m4.in
  @@ -9,6 +9,7 @@
   Description=Console Getty
   Documentation=man:agetty(8)
   After=systemd-user-sessions.service plymouth-quit-wait.service
  +ConditionPathExists=/dev/console
   m4_ifdef(`HAVE_SYSV_COMPAT',
   After=rc-local.service
   )m4_dnl
  -- 
  1.8.3.1
  
  ___
  systemd-devel mailing list
  systemd-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/systemd-devel


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

Re: [systemd-devel] newer systemd for rhel7/centos7

[Lukáš Nykrýn]

Rahul Sundaram píše v Čt 20. 11. 2014 v 20:20 -0500:
 Hi
 
 On Thu, Nov 20, 2014 at 11:24 AM, Lukáš Nykrýn wrote:
 Hi,
 
 rhel7 / centos7 is shipped with heavily patched systemd 208,
 which does
 not contain new interesting features and for us it is a
 backporting
 nightmare.
 
 I have prepared an experimental repo with newer version of
 systemd for
 epel7.
 
 
 I don't mind doing that if the goal here is eventually rebase in
 RHEL/CentOS.  If not, I won't be investing time on it
 
Unfortunately this is not completely up to me. But personally I would
like to see it in rhel/centos soon.

Lukas 
 
 Rahul
 
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel


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

[systemd-devel] newer systemd for rhel7/centos7

[Lukáš Nykrýn]

Hi,

rhel7 / centos7 is shipped with heavily patched systemd 208, which does
not contain new interesting features and for us it is a backporting
nightmare.

I have prepared an experimental repo with newer version of systemd for
epel7. Currently it is based on 217 from Fedora rawhide and final goal
should be 218.

If you are interested, here is a COPR build. Feedback and bug reports
are as always highly appreciated.

https://copr.fedoraproject.org/coprs/lnykryn/systemd/

Lukas

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

Re: [systemd-devel] newer systemd for rhel7/centos7

[Lukáš Nykrýn]

Jóhann B. Guðmundsson píše v Čt 20. 11. 2014 v 18:10 +:
 On 11/20/2014 04:24 PM, Lukáš Nykrýn wrote:
  Hi,
 
  rhel7 / centos7 is shipped with heavily patched systemd 208, which does
  not contain new interesting features and for us it is a backporting
  nightmare.
 
  I have prepared an experimental repo with newer version of systemd for
  epel7. Currently it is based on 217 from Fedora rawhide and final goal
  should be 218.
 
  If you are interested, here is a COPR build. Feedback and bug reports
  are as always highly appreciated.
 
  https://copr.fedoraproject.org/coprs/lnykryn/systemd/
 
  Lukas
 
 Wont you break your RHEL support if you run this?

Yes if you will use it on you rhel, it is not supported. 

But this was not my point. I am downstream maintainer and I am just
thinking if it is possible to rebase systemd in relatively conservative
distribution. So I wanted to ask upstream where can I except potential
issues. 

I thought that this could be an interesting topics for upstream because
I think that no distribution have  tried to do such huge rebase in one
major version.

An maybe this could be helpful for other distribution (is debian still
using 208? :) ).

Lukas

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

Re: [systemd-devel] newer systemd for rhel7/centos7

[Lukáš Nykrýn]

intrigeri píše v Čt 20. 11. 2014 v 21:40 +0100:
 Lukáš Nykrýn wrote (20 Nov 2014 20:35:05 GMT) :
  (is debian still using 208? :) ).
 
 Nope, we have v215 in Debian testing/sid :)
 
 Cheers!
 --
 intrigeri
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Ah sorry for that, I have old information. You will definitely have less
headaches than us. Damn you, sd_bus rewrite.

Lukas

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

Re: [systemd-devel] [PATCH] shell-completion/bash: add add-wants and add-requires

[Lukáš Nykrýn]

Zbigniew Jędrzejewski-Szmek píše v So 18. 10. 2014 v 16:42 +0200:
 On Thu, Oct 16, 2014 at 09:41:02AM +0200, Lukas Nykryn wrote:
  ---
   shell-completion/bash/systemctl.in | 12 
   1 file changed, 12 insertions(+)
  
  diff --git a/shell-completion/bash/systemctl.in 
  b/shell-completion/bash/systemctl.in
  index afa80da..30ba668 100644
  --- a/shell-completion/bash/systemctl.in
  +++ b/shell-completion/bash/systemctl.in
  @@ -74,6 +74,7 @@ __get_disabled_units () { __systemctl $1 list-unit-files  
  \
   | { while read -r a b c  ; do [[ $b == disabled ]]  echo  
  $a; done; }; }
   __get_masked_units   () { __systemctl $1 list-unit-files  \
   | { while read -r a b c  ; do [[ $b == masked   ]]  echo  
  $a; done; }; }
  +__get_all_unit_files () { { __systemctl $1 list-unit-files; } | { while 
  read -r a b; do echo  $a; done; }; }
   
   _systemctl () {
   local cur=${COMP_WORDS[COMP_CWORD]} 
  prev=${COMP_WORDS[COMP_CWORD-1]}
  @@ -139,6 +140,7 @@ _systemctl () {
[ISOLATABLE_UNITS]='isolate'
[RELOADABLE_UNITS]='reload condreload reload-or-try-restart 
  force-reload'
   [RESTARTABLE_UNITS]='restart reload-or-restart'
  + [TARGET_AND_UNITS]='add-wants add-requires'
[MASKED_UNITS]='unmask'
[JOBS]='cancel'
   [SNAPSHOTS]='delete'
  @@ -217,6 +219,16 @@ _systemctl () {
   comps=$( __get_masked_units $mode )
   compopt -o filenames
   
  +elif __contains_word $verb ${VERBS[TARGET_AND_UNITS]}; then
  +if __contains_word $prev ${VERBS[TARGET_AND_UNITS]} \
  +|| __contains_word $prev ${OPTS[STANDALONE]}; then
  +comps=$( __systemctl $mode list-unit-files --type 
  target --full --all \
 
 __systemctl includes --full already.
ok, removed
  +| { while read -r a b; do echo  $a; done; } )
  +else
  +comps=$( __get_all_unit_files $mode )
  +fi
  +compopt -o filenames
  +
   elif __contains_word $verb ${VERBS[STANDALONE]} ${VERBS[NAME]}; 
  then
   comps=''
 
 Please push. What about zsh?
 Zbyszek

Thanks for review. Pushed. And I am not familiar with zsh, so I will
leave that to someone else.

Lukas


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

Re: [systemd-devel] [PATCH v2] environment: append unit_id to error messages regarding EnvironmentFile

[Lukáš Nykrýn]

Zbigniew Jędrzejewski-Szmek píše v Pá 17. 10. 2014 v 15:40 +0200:
 On Fri, Oct 17, 2014 at 11:46:01AM +0200, Lukas Nykryn wrote:
  ---
  
  I have swapped parameters in test-fileio in previous version
   src/core/execute.c | 6 +++---
   src/core/execute.h | 2 +-
   src/shared/env-util.c  | 7 ---
   src/shared/env-util.h  | 2 +-
   src/test/test-fileio.c | 2 +-
   5 files changed, 10 insertions(+), 9 deletions(-)
 Looks good.
 
 Zbyszek

Thanks for review, pushed

Lukas

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

Re: [systemd-devel] [PATCH v4] systemctl: add add-wants and add-requires verbs

[Lukáš Nykrýn]

Zbigniew Jędrzejewski-Szmek píše v Út 07. 10. 2014 v 23:11 +0200:
 On Tue, Oct 07, 2014 at 05:46:48PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
  On Tue, Oct 07, 2014 at 02:09:37PM +0200, Lukas Nykryn wrote:
   ---
   Changes in v4
   - renamed install_dependency - dependency
   - removed the enum with dependencies and used the general one instead
  This part should really be a separate commit. It moves a lot of code
  around and makes it harder to see what is going on.
done
  
   - add an error meesage in the case that --root is used and it fails
   - changes in manpage
  Looks good, please push.
done
 Jan Synacek's patch f7101b7368 adds a check to unit_file_enable().
 An identical check should be applied to the code path you are adding.
done
 
 Zbyszek

Thanks for reviews!
Lukas

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

Re: [systemd-devel] [PATCHi v2] systemctl: add add-wants and add-requires verbs

[Lukáš Nykrýn]

Zbigniew Jędrzejewski-Szmek píše v St 24. 09. 2014 v 18:15 +0200:
 
 I don't understand the name method_add_install_dependency_unit_files.
 Why not just method_add_dependencies? After all, this is not like install,
 and does not work on the level of unit files, but units.
 
 Similarly for the dbus method name AddInstallDependencyUnitFiles.
   
This works with unit files, similarly as 'enable', so I would really
like to keep the UnitFiles part there. And the same for Install
part, I wanted to make it obvious that this is somehow an alternative to
[Install] section in unit file.

  -r = unit_file_load(c, info, path, root_dir, 
  allow_symlink);
  +if (load)
  +r = unit_file_load(c, info, path, 
  root_dir, allow_symlink);
  +else
  +r = access(path, F_OK) ? -errno : 0;
 Wouldn't it be nicer to push the 'load' parameter into
 unit_file_load(), and do the check there? I think that with
 your patch the support for root_dir is missing.

Yep you are right, this will not work with --root, but I don't think
that we want to have function unit_file_load(, bool really_load).
Maybe it would be better to add function unit_file_exists.

  + based on preset 
  configuration\n
 Extra line now? ;)

for (int i=0; i100; i++) puts(Will double check my patches before
sending them);

 Zbyszek


But really thanks for review.

Lukas

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

Re: [systemd-devel] Problem when using Cgroups with the Systemd command

[Lukáš Nykrýn]

Wei Yan píše v Út 02. 09. 2014 v 09:05 -0700:
 Hi, guys,
 
 
 I’m trying to get Cgroups working for RHEL7, and has a question on the
 Cgroups. When I started a process using “systemd-run --user command”
 under a user account, I always got an exception that “cannot get
 the dbus connection”. The systemd-run command under root user works
 well. But we cannot always use the root account to start the process.
 
 
 I also looked into the systemd document. It seems that we should
 call “startTransientUnit()” method on systemd on the bus. Is that the
 recommended way? Are there convenient CLI commands that we can call to
 achieve the same?
 
 
 thanks,
 Wei
 
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel

In rhel7 we do not start user instances of systemd for user.

Lukas 

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

Re: [systemd-devel] [PATCH] systemctl: fix broken list-unit-files with --root

[Lukáš Nykrýn]

Lennart Poettering píše v Út 26. 08. 2014 v 20:26 +0200:
 On Tue, 26.08.14 13:36, Lukas Nykryn (lnyk...@redhat.com) wrote:
 
 Looks good! Please commit!
 
  ---
   src/shared/install.c | 7 ++-
   1 file changed, 6 insertions(+), 1 deletion(-)
  
  diff --git a/src/shared/install.c b/src/shared/install.c
  index 4b09a69..3ef995a 100644
  --- a/src/shared/install.c
  +++ b/src/shared/install.c
  @@ -2072,6 +2072,7 @@ int unit_file_get_list(
   for (;;) {
   _cleanup_(unit_file_list_free_onep) UnitFileList 
  *f = NULL;
   struct dirent *de;
  +_cleanup_free_ char *path = NULL;
   
   errno = 0;
   de = readdir(d);
  @@ -2121,7 +2122,11 @@ int unit_file_get_list(
   goto found;
   }
   
  -r = unit_file_can_install(paths, root_dir, 
  f-path, true);
  +path = path_make_absolute(de-d_name, *i);
  +if (!path)
  +return -ENOMEM;
  +
  +r = unit_file_can_install(paths, root_dir, path, 
  true);
   if (r == -EINVAL ||  /* Invalid setting? */
   r == -EBADMSG || /* Invalid format? */
   r == -ENOENT /* Included file not found? 
  */)
 
 
 Lennart
 

Thanks for checking! Applied.

Lukas 

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

Re: [systemd-devel] [PATCH] sysv: order initscripts which provide $network before network.target

[Lukáš Nykrýn]

Since there was no comment I have pushed it to the git, we need that
patch in fedora.

Lukas

Lukas Nykryn píše v St 23. 07. 2014 v 13:04 +0200:
 Due to recent changes where $network maps to network-online.target
 it is not guaranteed that initscript which provides networking will
 be terminated after network.target during shutdown which is against LSB.
 ---
  src/sysv-generator/sysv-generator.c | 5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/src/sysv-generator/sysv-generator.c 
 b/src/sysv-generator/sysv-generator.c
 index 5206279..9a869ba 100644
 --- a/src/sysv-generator/sysv-generator.c
 +++ b/src/sysv-generator/sysv-generator.c
 @@ -482,6 +482,11 @@ static int load_sysv(SysvStub *s) {
  r = strv_extend(s-wants, 
 m);
  if (r  0)
  return log_oom();
 +if (streq(m, 
 SPECIAL_NETWORK_ONLINE_TARGET)) {
 +r = 
 strv_extend(s-before, SPECIAL_NETWORK_TARGET);
 +if (r  0)
 +return 
 log_oom();
 +}
  }
  
  if (r  0)


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

Re: [systemd-devel] Setting bridge parameters

[Lukáš Nykrýn]

poma píše v Pá 20. 06. 2014 v 13:36 +0200:
 On 20.06.2014 13:31, Tom Gundersen wrote:
  On Thu, Jun 19, 2014 at 1:37 PM, Vladimir Elisseev vo...@vovan.nl wrote:
  Simple question: is there a way to set bridge parameters (bridge forward 
  delay, bridge hello time, etc) using systemd networking units?
 
  This is still on the TODO. Last I heard Lukas was looking into this,
  so maybe we'll get that soon :)
 
  Cheers,
 
  Tom
 
 Ping.
 Simple question: was Lukas looking into bonding params also? :)
 
 
 poma

I have started with bonding params, but it's not looking promising.
Except mode all calls end with something like Could not append
IFLA_BOND_PRIMARY_RESELEC attribute: Operation not supported, even on
latest kernel which is in rawhide.
And setting mode does not show any error, but does not work either.
If anybody wants to look at it, here is my patch for mode
http://pastebin.com/qz1XQ9DA

and here is a earlier version which tried to setup everything.
http://pastebin.com/dzsDQqYF

Lukas


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

Re: [systemd-devel] [PATCH 1/2] EnvironmentFile: don't drop backslashes inside single quotes

[Lukáš Nykrýn]

Čt 10. duben 2014, 15:52:56 CEST, Zbigniew Jędrzejewski-Szmek napsal:

On Thu, Apr 10, 2014 at 03:17:20PM +0200, Lukas Nykryn wrote:

---
  src/shared/fileio.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/shared/fileio.c b/src/shared/fileio.c
index f101269..0eb131d 100644
--- a/src/shared/fileio.c
+++ b/src/shared/fileio.c
@@ -446,11 +446,12 @@ static int parse_env_file_internal(
  state = SINGLE_QUOTE_VALUE;

  if (!strchr(newline, c)) {
-if (!greedy_realloc((void**) value, 
value_alloc, n_value+2)) {
+if (!greedy_realloc((void**) value, 
value_alloc, n_value+3)) {
  r = -ENOMEM;
  goto fail;
  }

+value[n_value++] = '\\';
  value[n_value++] = c;

Can you please add a unit test for this?

Zbyszek


Hmm, actually this patch breaks some current cases. Maybe there should 
be a different approach.


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

Re: [systemd-devel] Netconsole NG

[Lukáš Nykrýn]

Dne 6.4.2014 17:59, poma napsal(a):


/etc/sysconfig/netconsole:
# This is the EnvironmentFile for the netconsole service. Starting this
# service enables the capture of dmesg output on a destination machine.

# Source port
SRC_PORT=12345

# Source IP address
SRC_IP=192.168.1.2

# Source network device
SRC_DEV=enp1s2

# Destination port
DST_PORT=12345

# Destination IP address
DST_IP=192.168.1.1

# Destination ethernet address
DST_EHA=00:11:22:33:44:55


/usr/lib/systemd/system/netconsole.service:
[Unit]
Description=Adds the netconsole module with the configured parameters
After=network.target

[Service]
EnvironmentFile=/etc/sysconfig/netconsole

Type=simple
RemainAfterExit=yes
ExecStart=/usr/sbin/modprobe netconsole
netconsole=${SRC_PORT}@${SRC_IP}/${SRC_DEV},${DST_PORT}@${DST_IP}/${DST_EHA}
ExecStop=/usr/sbin/modprobe -r netconsole

[Install]
WantedBy=multi-user.target


The original SysV netconsole service with related config - still in use,
https://git.fedorahosted.org/cgit/initscripts.git/plain/rc.d/init.d/netconsole
https://git.fedorahosted.org/cgit/initscripts.git/plain/sysconfig/netconsole

Feel free to comment.


poma



The reason why this was not rewritten a long time ago is that the 
initscript tries to figure some of those values by itself (for example 
the MAC address). But yes, we need to do something with netconsole. It 
is a blocker for my initscripts evil plan.


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

Re: [systemd-devel] [PATCH] util: always consider glusterfs as a network filesystem

[Lukáš Nykrýn]

Po 24. březen 2014, 17:12:30 CET, Lennart Poettering napsal:

On Mon, 24.03.14 15:55, Lukas Nykryn (lnyk...@redhat.com) wrote:

Are you sure this does what you think it does? I mean, AFAIR glusterfs
is a fuse FS, and hence will nevershow up like this in fstab nor
/proc/self/mountinfo... Or am I missing something?

Reason for this was https://bugzilla.redhat.com/show_bug.cgi?id=974626 
, it is probably not accessible so in shortcut: In rhel 6 someone is 
using glusterfs,_netdev in fstab and they want me to patch rc.sysinit 
to recognize glusterfs as a network fs by default (so no need for 
_netdev). I don't want to introduce such change in rhel6 and that have 
a regression in rhel7 with systemd.


Lukas


---
  src/shared/util.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/shared/util.c b/src/shared/util.c
index dd67c22..6f73387 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -1500,7 +1500,8 @@ bool fstype_is_network(const char *fstype) {
  nfs\0
  nfs4\0
  gfs\0
-gfs2\0;
+gfs2\0
+glusterfs\0;

  return nulstr_contains(table, fstype);
  }



Lennart


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

Re: [systemd-devel] [PATCH] util: always consider glusterfs as a network filesystem

[Lukáš Nykrýn]

Po 24. březen 2014, 17:48:53 CET, Lennart Poettering napsal:

On Mon, 24.03.14 17:38, Lukáš Nykrýn (lnyk...@redhat.com) wrote:



Po 24. březen 2014, 17:12:30 CET, Lennart Poettering napsal:

On Mon, 24.03.14 15:55, Lukas Nykryn (lnyk...@redhat.com) wrote:

Are you sure this does what you think it does? I mean, AFAIR glusterfs
is a fuse FS, and hence will nevershow up like this in fstab nor
/proc/self/mountinfo... Or am I missing something?


Reason for this was
https://bugzilla.redhat.com/show_bug.cgi?id=974626 , it is probably
not accessible so in shortcut: In rhel 6 someone is using
glusterfs,_netdev in fstab and they want me to patch rc.sysinit to
recognize glusterfs as a network fs by default (so no need for
_netdev). I don't want to introduce such change in rhel6 and that
have a regression in rhel7 with systemd.


Well, but how exactly do those lines look in fstab? Are you sure they
have glusterfs in the fstype field? And not fuse.glusterfs or so?


Lennart



From RH Knowledgebase (again sorry not a public link) 
https://access.redhat.com/site/solutions/204443


Update /etc/fstab and add the _netdev option to the glusterfs mount 
points like this:

HOSTNAME-OR-IPADDRESS:/VOLNAME MOUNTDIR glusterfs defaults,_netdev 0 0
For example:
server1:/test-volume /mnt/glusterfs glusterfs defaults,_netdev 0 0

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

Re: [systemd-devel] [PATCH] util: always consider glusterfs as a network filesystem

[Lukáš Nykrýn]

Po 24. březen 2014, 18:49:34 CET, Lennart Poettering napsal:

On Mon, 24.03.14 18:03, Lukáš Nykrýn (lnyk...@redhat.com) wrote:


Well, but how exactly do those lines look in fstab? Are you sure they
have glusterfs in the fstype field? And not fuse.glusterfs or so?


 From RH Knowledgebase (again sorry not a public link)
https://access.redhat.com/site/solutions/204443

Update /etc/fstab and add the _netdev option to the glusterfs mount
points like this:
HOSTNAME-OR-IPADDRESS:/VOLNAME MOUNTDIR glusterfs defaults,_netdev 0 0
For example:
server1:/test-volume /mnt/glusterfs glusterfs defaults,_netdev 0 0


But that's how it looks in /etc/fstab, which is a userspace interface.

Howe does it look in /proc/self/mountinfo though, i.e. after it is
mounted, in the kernel interface?

Since glusterfs is a FUSE file system I am pretty sure it is called
fuse.gluster or so in /proc/self/mountinfo, right?

Lennart



You are right, it shows up as fuse.glusterfs there. So any suggestions? 
And just drop the patch is also a valid suggestion :).


Lukas

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

Re: [systemd-devel] [PATCH] service: don't create extra cgroup for control process when reloading SysV service

[Lukáš Nykrýn]

St 12. březen 2014, 18:34:11 CET, Uoti Urpala napsal:

On Wed, 2014-03-12 at 16:51 +0100, Lennart Poettering wrote:

On Mon, 10.03.14 15:25, Lukas Nykryn (lnyk...@redhat.com) wrote:


Unfortunately common practice in initscripts is to have reload as an
alias for restart (https://fedoraproject.org/wiki/Packaging:SysVInitScript).
In that case the newly started process will be killed immediately after
the reload process ends and its cgroup is destroyed.




I am not sure I grok why this all would be a problem at all, given that
on Fedora/RHEL we redirect those verbs to systemctl anyway, and
systemctl handles reload/restart on its own anyway... What am I missing?


But systemctl supports using the reload functionality in init scripts,
so that doesn't really make a difference. As I understood the problem
description, this is what happens: someone runs systemctl reload
foo.service for a broken sysv script, systemd sees that the script
seems to support a reload argument and runs /etc/init.d/foo reload
in a temporary cgroup, but the broken script stops the running service
and starts a new one in the temporary cgroup.


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


Exactly. Systemd exec /etc/init.d/foo reload in control subgroup. 
Than the initscript kills the original deamon, starts a new one and 
quits. Systemd sees that the reload process finished and kills 
remaining processes in the control group, thus kills the daemon.


This patch works quite fine when the initscripts is using pid files, 
systemd correctly updates the information about main pid.



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

Re: [systemd-devel] [PATCH] s390/getty-generator: initialize essential system terminals/consoles

[Lukáš Nykrýn]

Dne 31.1.2014 17:08, Hendrik Brueckner napsal(a):

Ensure to start getty programs on all essential system consoles on Linux on
System z.  Add these essential devices to the list of virtualization_consoles
to always generate getty configurations.

For the sake of completion, the list of essential consoles is:

   /dev/sclp_line0 - Operating system messages applet (LPAR)
   /dev/ttysclp0 - Integrated ASCII console applet (z/VM and LPAR)
   /dev/ttyS0 - Already handled by systemd (3215 console on z/VM)
   /dev/hvc0  - Already handled by systemd (IUCV HVC terminal on z/VM)

Depending on the environment, z/VM or LPAR, only a subset of these terminals
are available.

See also RH BZ 860158[1] Cannot login via Operating System Console into RHEL7
instance installed on a LPAR.  This bugzilla actually blocks the installation
of Linux on System z instances in LPAR mode.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=860158
---
  rules/99-systemd.rules.in |2 +-
  src/getty-generator/getty-generator.c |4 +++-
  2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/rules/99-systemd.rules.in b/rules/99-systemd.rules.in
index 0923de5..021359a 100644
--- a/rules/99-systemd.rules.in
+++ b/rules/99-systemd.rules.in
@@ -7,7 +7,7 @@

  ACTION==remove, GOTO=systemd_end

-SUBSYSTEM==tty, KERNEL==tty[a-zA-Z]*|hvc*|xvc*|hvsi*, TAG+=systemd
+SUBSYSTEM==tty, KERNEL==tty[a-zA-Z]*|hvc*|xvc*|hvsi*|ttysclp*|sclp_line*, 
TAG+=systemd

  KERNEL==vport*, TAG+=systemd

diff --git a/src/getty-generator/getty-generator.c 
b/src/getty-generator/getty-generator.c
index aeb6d71..f352a29 100644
--- a/src/getty-generator/getty-generator.c
+++ b/src/getty-generator/getty-generator.c
@@ -97,7 +97,9 @@ int main(int argc, char *argv[]) {
  static const char virtualization_consoles[] =
  hvc0\0
  xvc0\0
-hvsi0\0;
+hvsi0\0
+sclp_line0\0
+ttysclp0\0;

  _cleanup_free_ char *active = NULL;
  const char *j;




Thanks! Applied.

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

Re: [systemd-devel] [PATCH] core: get rid the start job when transitioning to deactivating

[Lukáš Nykrýn]

Dne 18.7.2013 20:02, Lennart Poettering napsal(a):

On Thu, 18.07.13 17:04, Michal Sekletar (msekl...@redhat.com) wrote:


When dependency unit is configured with StopWhenUnneeded=yes and
activation of main unit fails, e.g.  start timeout occurs, then
dependencies are never stopped. This happens because start job for
the main unit is still around.
---
  src/core/unit.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/core/unit.c b/src/core/unit.c
index 0e9329f..d5c89a4 100644
--- a/src/core/unit.c
+++ b/src/core/unit.c
@@ -1461,7 +1461,7 @@ void unit_notify(Unit *u, UnitActiveState os, 
UnitActiveState ns, bool reload_su
  else if (u-job-state == JOB_RUNNING  ns != 
UNIT_ACTIVATING) {
  unexpected = true;
  
-if (UNIT_IS_INACTIVE_OR_FAILED(ns))

+if (UNIT_IS_INACTIVE_OR_FAILED(ns) || 
UNIT_IS_INACTIVE_OR_DEACTIVATING(ns))
  job_finish_and_invalidate(u-job, ns 
== UNIT_FAILED ? JOB_FAILED : JOB_DONE, true);
  }
  

Hmm, so UNIT_IS_INACTIVE_OR_DEACTIVATING() actually tests for a superset
of UNIT_IS_INACTIVE_OR_FAILED(), so oring them is unnecessary.

I am not entirely grokking the patch though. So far the idea was that if
a unit is being deactviated while a start job is queued that we then
simply wait until the deactivation is complete and then execute the
start job. This would break with your patch though...

Hmm, can you eleraborate on the actual problem you are trying to solve=
I don't get it so far ;-)

Thanks,

Lennart



Dne 18.7.2013 20:02, Lennart Poettering napsal(a):

On Thu, 18.07.13 17:04, Michal Sekletar (msekl...@redhat.com) wrote:


When dependency unit is configured with StopWhenUnneeded=yes and
activation of main unit fails, e.g.  start timeout occurs, then
dependencies are never stopped. This happens because start job for
the main unit is still around.
---
  src/core/unit.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/core/unit.c b/src/core/unit.c
index 0e9329f..d5c89a4 100644
--- a/src/core/unit.c
+++ b/src/core/unit.c
@@ -1461,7 +1461,7 @@ void unit_notify(Unit *u, UnitActiveState os, 
UnitActiveState ns, bool reload_su
  else if (u-job-state == JOB_RUNNING  ns != 
UNIT_ACTIVATING) {
  unexpected = true;
  
-if (UNIT_IS_INACTIVE_OR_FAILED(ns))

+if (UNIT_IS_INACTIVE_OR_FAILED(ns) || 
UNIT_IS_INACTIVE_OR_DEACTIVATING(ns))
  job_finish_and_invalidate(u-job, ns 
== UNIT_FAILED ? JOB_FAILED : JOB_DONE, true);
  }
  

Hmm, so UNIT_IS_INACTIVE_OR_DEACTIVATING() actually tests for a superset
of UNIT_IS_INACTIVE_OR_FAILED(), so oring them is unnecessary.

I am not entirely grokking the patch though. So far the idea was that if
a unit is being deactviated while a start job is queued that we then
simply wait until the deactivation is complete and then execute the
start job. This would break with your patch though...

Hmm, can you eleraborate on the actual problem you are trying to solve=
I don't get it so far ;-)

Thanks,

Lennart



Hi,
when service has StopWhenUnneeded=yes and it is requested by forking 
service, which fails during initialization, the first unit is not stopped.


Reproducer:

-bash-4.2# more /etc/systemd/system/test*
::
/etc/systemd/system/test.service
::
[Unit]
Description=aaa
Requires=testb.service

[Service]
Type=forking
ExecStart=/bin/sleep 50
TimeoutStartSec=3

::
/etc/systemd/system/testb.service
::
[Unit]
Description=aaa
StopWhenUnneeded=yes

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/echo hej
ExecStop=/bin/echo hou

-bash-4.2# systemctl status testb test
testb.service - aaa
   Loaded: loaded (/etc/systemd/system/testb.service; static)
   Active: inactive (dead)


test.service - aaa
   Loaded: loaded (/etc/systemd/system/test.service; static)
   Active: inactive (dead)

-bash-4.2# systemctl start test
Job for test.service failed. See 'systemctl status test.service' and 
'journalctl -xn' for details.


-bash-4.2# systemctl status testb test
testb.service - aaa
   Loaded: loaded (/etc/systemd/system/testb.service; static)
   Active: active (exited) since Thu 2013-07-18 15:34:34 CEST; 7s ago
  Process: 45 ExecStart=/bin/echo hej (code=exited, status=0/SUCCESS)

Jul 18 15:34:34 mycontainer systemd[1]: Starting aaa...
Jul 18 15:34:34 mycontainer systemd[1]: Started aaa.

test.service - aaa
   Loaded: loaded (/etc/systemd/system/test.service; static)
   Active: failed (Result: timeout) since Thu 2013-07-18 15:34:37 CEST; 
4s ago

  Process: 46 ExecStart=/bin/sleep 50 (code=killed, signal=TERM)

Jul 18 15:34:34 mycontainer systemd[1]: Starting aaa...
Jul 18 15:34:37 mycontainer systemd[1]: test.service 

Re: [systemd-devel] [PATCH] systemd-delta: add support for drop-in snippets

[Lukáš Nykrýn]

Dne 16.5.2013 02:41, Zbigniew Jędrzejewski-Szmek napsal(a):

On Tue, May 14, 2013 at 05:34:28PM +0200, Lukas Nykryn wrote:

---
  TODO  |   3 -
  man/systemd-delta.xml |   7 ++
  src/delta/delta.c | 182 --
  3 files changed, 170 insertions(+), 22 deletions(-)

Hi Lukas,
thank you for your patience and all those patch versions.
Nevertheless, I still have some doubts:

I created the following extended files, one pair which
creates and override, and the third file which is not
overriden, but is an extended configuration.

== /run/systemd/system/dracut-pre-udev.service ==
[Unit]
Description=dracut pre-udev hook
Documentation=man:dracut-pre-udev.service(8)
...

== /etc/systemd/system/dracut-pre-udev.service.d/0-descr.conf ==
[Unit]
Description=foofoo

== /run/systemd/system/dracut-pre-udev.service.d/0-descr.conf ==
[Unit]
Description=foo

== /run/systemd/system/dracut-pre-udev.service.d/0-descr2.conf ==
[Unit]
Documentation=foo

When I run systemd-delta I see:
./systemd-delta --diff=0 --no-pager systemd/system -t extended
(nothing)

./systemd-delta --diff=0 --no-pager systemd/system
[OVERRIDDEN] /etc/systemd/system/dracut-pre-udev.service.d/0-descr.conf → 
/run/systemd/system/dracut-pre-udev.service.d/0-descr.conf

I would expect to see 0-descr.conf and 0-descr2.conf in the first
case... And also 0-descr2.conf in the second case... Is it actually
supposed to behave like that? It might be nice to extend the
description in the manpage a bit.

Zbyszek

Hello,

Thanks for noticing it and your patient. There was quite stupid mistake 
and I haven't noticed it because I was testing it on unit which was 
overridden.


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

Re: [systemd-devel] [PATCH] condition: add option ConditionArchitecture

[Lukáš Nykrýn]

St 27. březen 2013, 13:21:28 CET, Zbigniew Jędrzejewski-Szmek napsal:

On Wed, Mar 27, 2013 at 08:22:14AM +0100, Tollef Fog Heen wrote:

]] Cristian Rodríguez


El 26/03/13 15:17, Bill Nottingham escribió:

Lukas Nykryn (lnyk...@redhat.com) said:

---
   TODO  |  2 --
   man/systemd.unit.xml.in   |  8 
   src/core/condition.c  | 16 
   src/core/condition.h  |  1 +
   src/core/load-fragment-gperf.gperf.m4 |  1 +
   5 files changed, 26 insertions(+), 2 deletions(-)


Not that this seems wrong, but what is the usage case for this that
can't be solved via package (de)installation?


The patch looks fine to me, what it solves ? well.. there may be
generic image deployments , who contain the same packages but one of
them is only really useful in arch s390 or ppc.. etc..


I think it should be kernel architecture if so, since you might very
well have multiple userland architectures enabled and working at the
same time.  (So it should be ConditionKernelArchitecture to make it
clear.)

Shouldn't this be a glob, like ConditionHost=?

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


I don't think that is necessary, the set of all architectures is quite 
small. But it would just mean to replace

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

Re: [systemd-devel] [PATCH 2/2] log: fix error codes handling in catalog_list_items

[Lukáš Nykrýn]

So if we want to return first error  there should be
-if (r  0)
+if (r == 0)
r = k;

Am I right?

Lukas

St 27. březen 2013, 17:06:27 CET, Zbigniew Jędrzejewski-Szmek napsal:

On Wed, Mar 27, 2013 at 10:44:21AM +0100, Lukas Nykryn wrote:

Previously r was set to zero and so if(r0) was never true. Also it does not 
make sense to print error code from previous loop.


Applied the first one and a half of this one. You're right that k should
be used instead of r, but this is in a loop, so r  0 is possible. The
convention is to return the *first* error.

Zbyszek


---
  src/journal/catalog.c | 10 --
  1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/src/journal/catalog.c b/src/journal/catalog.c
index dacf5c5..96854d7 100644
--- a/src/journal/catalog.c
+++ b/src/journal/catalog.c
@@ -616,9 +616,8 @@ int catalog_list_items(FILE *f, bool oneline, char **items) 
{
  k = sd_id128_from_string(*item, id);
  if (k  0) {
  log_error(Failed to parse id128 '%s': %s,
-  *item, strerror(-r));
-if (r  0)
-r = k;
+  *item, strerror(-k));
+r = k;
  continue;
  }

@@ -626,9 +625,8 @@ int catalog_list_items(FILE *f, bool oneline, char **items) 
{
  if (k  0) {
  log_full(k == -ENOENT ? LOG_NOTICE : LOG_ERR,
   Failed to retrieve catalog entry for '%s': 
%s,
-  *item, strerror(-r));
-if (r  0)
-r = k;
+  *item, strerror(-k));
+r = k;
  continue;
  }

--
1.8.1.4

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




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

Re: [systemd-devel] [PATCH] systemctl: mangle unit name in is-enabled

[Lukáš Nykrýn]

Čt 7. březen 2013, 16:13:17 CET, Lennart Poettering napsal:

On Thu, 07.03.13 16:09, Lukas Nykryn (lnyk...@redhat.com) wrote:

Hmm, don't we need the same for the other unit file verbs such as
enable/disable/mask/unmask, too?


---
  src/systemctl/systemctl.c | 19 +--
  1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 99286cf..72e9c55 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -3982,6 +3982,7 @@ static int unit_is_enabled(DBusConnection *bus, char 
**args) {
  DBusMessage _cleanup_dbus_message_unref_ *reply = NULL;
  bool enabled;
  char **name;
+char *n;

  dbus_error_init(error);

@@ -3996,7 +3997,14 @@ static int unit_is_enabled(DBusConnection *bus, char 
**args) {
  STRV_FOREACH(name, args+1) {
  UnitFileState state;

-state = unit_file_get_state(arg_scope, arg_root, 
*name);
+n = unit_name_mangle(*name);
+if (!n)
+return log_oom();
+
+state = unit_file_get_state(arg_scope, arg_root, n);
+
+free(n);
+
  if (state  0)
  return state;

@@ -4013,6 +4021,10 @@ static int unit_is_enabled(DBusConnection *bus, char 
**args) {
  STRV_FOREACH(name, args+1) {
  const char *s;

+n = unit_name_mangle(*name);
+if (!n)
+return log_oom();
+
  r = bus_method_call_with_reply (
  bus,
  org.freedesktop.systemd1,
@@ -4021,8 +4033,11 @@ static int unit_is_enabled(DBusConnection *bus, char 
**args) {
  GetUnitFileState,
  reply,
  NULL,
-DBUS_TYPE_STRING, name,
+DBUS_TYPE_STRING, n,
  DBUS_TYPE_INVALID);
+
+free(n);
+
  if (r)
  return r;




Lennart



I think that these already work.

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

[systemd-devel] coverity patches

[Lukáš Nykrýn]

0001-systemd-python-add-missing-check-for-return-of-PyDic.patch
Description: Binary data


0002-systemctl-check-if-iterator-was-initialized-succesfu.patch
Description: Binary data


0003-tpmfiles-add-missing-parenthesis.patch
Description: Binary data


0004-systemd-analyze-free-unit_times-only-if-it-is-not-NU.patch
Description: Binary data


0005-manager-print-p-and-then-free-it.patch
Description: Binary data
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] do not ellipsize cgroup members in full status

[Lukáš Nykrýn]

Lennart Poettering píše v Út 25. 09. 2012 v 17:45 +0200:
 On Tue, 25.09.12 15:36, Lukáš Nykrýn (lnyk...@redhat.com) wrote:
 
 Heya,
 
  diff --git a/src/shared/logs-show.h b/src/shared/logs-show.h
  index 3e6b6e0..3b63a5d 100644
  --- a/src/shared/logs-show.h
  +++ b/src/shared/logs-show.h
  @@ -27,26 +27,6 @@
   
   #include util.h
   
  -typedef enum OutputMode {
  -OUTPUT_SHORT,
  -OUTPUT_SHORT_MONOTONIC,
  -OUTPUT_VERBOSE,
  -OUTPUT_EXPORT,
  -OUTPUT_JSON,
  -OUTPUT_JSON_PRETTY,
  -OUTPUT_CAT,
  -_OUTPUT_MODE_MAX,
  -_OUTPUT_MODE_INVALID = -1
  -} OutputMode;
  -
  -typedef enum OutputFlags {
  -OUTPUT_SHOW_ALL   = 1  0,
  -OUTPUT_FOLLOW = 1  1,
  -OUTPUT_WARN_CUTOFF= 1  2,
  -OUTPUT_FULL_WIDTH = 1  3,
  -OUTPUT_COLOR  = 1  4
  -} OutputFlags;
  -
 
 Hmm, I don't think this should be part of util.[ch] really, it's far to
 specific to be considered just a utility. Could you please move this to a new
 file output.h or so?
 
  -int get_process_cmdline(pid_t pid, size_t max_length, bool comm_fallback, 
  char **line) {
  -char *r, *k;
  +int get_process_cmdline(pid_t pid, size_t max_length, bool comm_fallback, 
  char **line, OutputFlags flags) {
  +char *r = NULL, *k;
   int c;
  -bool space = false;
  -size_t left;
   FILE *f;
 
 I don't think this flag really should be passed here, this call is too
 low-level for that. Instead, max_length == 0 could be used as a good
 indicator for as big as needed or so.
 
 Otherwise looks pretty OK!
 
 Lennart
 

Hello,
I completely forget about this patch and there were again some
complaints about this behavior. Here is my original patch with some
modification (see commit log).

Lukas


From 88495e0e6a3fb9ff95a28a65c22b3b55e21c14fa Mon Sep 17 00:00:00 2001
From: Lukas Nykryn lnyk...@redhat.com
Date: Mon, 14 Jan 2013 18:16:50 +0100
Subject: [PATCH] systemctl,loginctl,cgls: do not ellipsize cgroup members
 when --full is specified

New file output.h with output flags and modes.

--full parameter also for cgls and loginctl.

Include 'all' parameter in flags (show_cgroup_by_path, show_cgroup,
show_cgroup_and_extra, show_cgroup_and_extra_by_spec).

get_process_cmdline with max_length == 0 will not ellipsize output.

Replace LINE_MAX with 0 in some calls of get_process_cmdline.
---
 Makefile.am   |  3 +-
 man/loginctl.xml  |  7 
 man/systemctl.xml |  2 +-
 man/systemd-cgls.xml  |  8 +
 src/cgls/cgls.c   | 16 ++---
 src/core/selinux-access.c |  4 +--
 src/journal/coredump.c|  2 +-
 src/journal/journald-server.c |  2 +-
 src/login/loginctl.c  | 13 +--
 src/shared/cgroup-show.c  | 49 +
 src/shared/cgroup-show.h  | 10 +++---
 src/shared/logs-show.h| 23 +---
 src/shared/output.h   | 44 +++
 src/shared/util.c | 84 +--
 src/systemctl/systemctl.c | 14 
 15 files changed, 178 insertions(+), 103 deletions(-)
 create mode 100644 src/shared/output.h

diff --git a/Makefile.am b/Makefile.am
index 3318829..f4f9f34 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -809,7 +809,8 @@ libsystemd_shared_la_SOURCES = \
 	src/shared/time-dst.c \
 	src/shared/time-dst.h \
 	src/shared/calendarspec.c \
-	src/shared/calendarspec.h
+	src/shared/calendarspec.h \
+	src/shared/output.h
 
 libsystemd_shared_la_LIBADD = libsystemd-daemon.la
 
diff --git a/man/loginctl.xml b/man/loginctl.xml
index 5dbc1f6..8a20d18 100644
--- a/man/loginctl.xml
+++ b/man/loginctl.xml
@@ -110,6 +110,13 @@
 set or not./para/listitem
 /varlistentry
 
+varlistentry
+termoption--full/option/term
+
+listitemparaDo not ellipsize cgroup
+members./para
+/listitem
+/varlistentry
 
 varlistentry
 termoption--no-pager/option/term
diff --git a/man/systemctl.xml b/man/systemctl.xml
index 2f33e0c..0289200 100644
--- a/man/systemctl.xml
+++ b/man/systemctl.xml
@@ -156,7 +156,7 @@
 termoption--full/option/term
 
 listitemparaDo not ellipsize unit
-names and truncate unit descriptions
+names, cgroup members and truncate unit descriptions
 in the output of
 commandlist-units/command and
 commandlist-jobs/command./para/listitem
diff --git a/man/systemd-cgls.xml b/man/systemd-cgls.xml
index 4b6ee93..b280b87 100644
--- a/man

[systemd-devel] [PATCH] bootchart: make sure that every read buffer is null terminated

[Lukáš Nykrýn]

Hello,
I am not sure about this one. There is a probability that bufgetline
during first call in src/bootchart/log.c:265 can get string which is not
null-terminated.

Lukas
From bb19a933eee9bad3f67d3069bfea6c4f476a840a Mon Sep 17 00:00:00 2001
From: Lukas Nykryn lnyk...@redhat.com
Date: Thu, 10 Jan 2013 14:36:42 +0100
Subject: [PATCH] bootchart: make sure that every read buffer is null
 terminated

---
 src/bootchart/log.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/src/bootchart/log.c b/src/bootchart/log.c
index eda001a..78f0cab 100644
--- a/src/bootchart/log.c
+++ b/src/bootchart/log.c
@@ -182,8 +182,10 @@ schedstat_next:
 
 if (e_fd) {
 n = pread(e_fd, buf, sizeof(buf) - 1, 0);
-if (n  0)
+if (n  0) {
+buf[n] = '\0';
 entropy_avail[sample] = atoi(buf);
+}
 }
 }
 
@@ -256,6 +258,7 @@ schedstat_next:
 close(ps-sched);
 continue;
 }
+buf[s] = '\0';
 
 if (!sscanf(buf, %s %*s %*s, key))
 continue;
@@ -337,8 +340,8 @@ schedstat_next:
 if (ps-schedstat == -1)
 continue;
 }
-
-if (pread(ps-schedstat, buf, sizeof(buf) - 1, 0) = 0) {
+s = pread(ps-schedstat, buf, sizeof(buf) - 1, 0);
+if (s = 0) {
 /* clean up our file descriptors - assume that the process exited */
 close(ps-schedstat);
 if (ps-sched)
@@ -347,6 +350,8 @@ schedstat_next:
 //fclose(ps-smaps);
 continue;
 }
+buf[s] = '\0';
+
 if (!sscanf(buf, %s %s %*s, rt, wt))
 continue;
 
@@ -401,7 +406,8 @@ catch_rename:
 if (ps-sched == -1)
 continue;
 }
-if (pread(ps-sched, buf, sizeof(buf) - 1, 0) = 0) {
+s = pread(ps-sched, buf, sizeof(buf) - 1, 0);
+if (s = 0) {
 /* clean up file descriptors */
 close(ps-sched);
 if (ps-schedstat)
@@ -410,6 +416,7 @@ catch_rename:
 //fclose(ps-smaps);
 continue;
 }
+buf[s] = '\0';
 
 if (!sscanf(buf, %s %*s %*s, key))
 continue;
-- 
1.7.11.7

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

Re: [systemd-devel] [Patch] build issues on ppc

[Lukáš Nykrýn]

Lennart Poettering píše v Út 18. 12. 2012 v 18:20 +0100:
 On Tue, 18.12.12 17:56, Lukáš Nykrýn (lnyk...@redhat.com) wrote:
 
  Hello,
  systemd-196 won't build on ppc
  https://bugzilla.redhat.com/show_bug.cgi?id=888255. I think that
  sufficient patch would be:
  
  diff --git a/Makefile.am b/Makefile.am
  index 804cc04..acbb12b 100644
  --- a/Makefile.am
  +++ b/Makefile.am
  @@ -1068,7 +1068,8 @@ libsystemd_core_la_SOURCES = \
  src/core/syscall-list.c \
  src/core/syscall-list.h \
  src/core/audit-fd.c \
  -   src/core/audit-fd.h
  +   src/core/audit-fd.h \
  +   src/libsystemd-daemon/sd-daemon.c
 
 Hmm, but libsystemd_core_la_LIBADD already pulls in
 libsystemd-daemon.la. So why pull the .c file in too? This doesn't look
 like the right fix to me.
 
 Lennart
 
Sorry I overlooked it. But then I am not sure, why the build is failing.

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

[systemd-devel] [Patch] build issues on ppc

[Lukáš Nykrýn]

Hello,
systemd-196 won't build on ppc
https://bugzilla.redhat.com/show_bug.cgi?id=888255. I think that
sufficient patch would be:

diff --git a/Makefile.am b/Makefile.am
index 804cc04..acbb12b 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1068,7 +1068,8 @@ libsystemd_core_la_SOURCES = \
src/core/syscall-list.c \
src/core/syscall-list.h \
src/core/audit-fd.c \
-   src/core/audit-fd.h
+   src/core/audit-fd.h \
+   src/libsystemd-daemon/sd-daemon.c

 if HAVE_KMOD
 libsystemd_core_la_SOURCES += \

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

Re: [systemd-devel] PrivateTmp and systemd-tmpfiles

[Lukáš Nykrýn]

Kay Sievers píše v St 17. 10. 2012 v 18:28 +0200:
 On Wed, Oct 17, 2012 at 6:10 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Wed, 17.10.12 14:16, Lukáš Nykrýn (lnyk...@redhat.com) wrote:
 
  Hello,
  Today I have read this bug
  https://bugzilla.redhat.com/show_bug.cgi?id=866693 and described
  systemd-tmpfiles behavior look pretty wrong to me, but I am not sure how
  to fix it. Some ideas cross my mind; moving systemd-namespace-*
  elsewhere, adding some option to exclude dirs in tmpfiles conf files,
  stop cleaning /tmp, hardcode some excludes to tmpfiles, but I don't like
  any of these solutions.
 
  We already allow files to be excluded from clean up by setting the
  sticky bit on them. We can't do that for dirs however, since the sticky
  bit for dirs has a different meaning. One possible way to solve this
  issue otherwise might be by introducing an xattr for this. The one thing
  blocking this right now however is that tmpfs still can't handle xattrs
  properly. There were multiple attempts to get xattrs for tmpfs into the
  kernel, not sure what the latest state on this is.
 
  The best would probably be to exclude these dirs from clean-up via
  explicit tmpfiles lines. Unfortunately x is probably not going to do
  it here, since we actually want recursive clean-up inside the dir, just
  not of the dir... So maybe introduce a new type of X that excludes the
  dir itself from clean-up but does not exclude recursively?
 
 Pre-create and protect a  /tmp/systemd-namespace/ subdir?
 
 Kay

What about saving private tmp and var/tmp paths to service struct when
service is started and then systemd-tmpfiles can obtain all currently
used paths and skip them (but not their content)?

I don't think that simply skip /tmp/systemd-privat-XXX would be a good
idea because these dirs would be never deleted even if the service is
already dead.

Lukas

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

[systemd-devel] PrivateTmp and systemd-tmpfiles

[Lukáš Nykrýn]

Hello,
Today I have read this bug
https://bugzilla.redhat.com/show_bug.cgi?id=866693 and described
systemd-tmpfiles behavior look pretty wrong to me, but I am not sure how
to fix it. Some ideas cross my mind; moving systemd-namespace-*
elsewhere, adding some option to exclude dirs in tmpfiles conf files,
stop cleaning /tmp, hardcode some excludes to tmpfiles, but I don't like
any of these solutions.

Smaller reproducer:
/usr/lib/tmpfiles.d/tmp.conf
d /tmp 1777 root root 20s

a.service
[Unit]
Description=unit %n

[Service]
Type=simple
ExecStart=/root/test.sh
StandardOutput=syslog
PrivateTmp=yes

/root/test.sh
#!/bin/bash
sleep 40
echo hello world  /tmp/xxx
exit 0

and then run something like
systemctl start a.service 
watch 'systemd-tmpfiles --clean tmp.conf; ls -al /tmp; systemctl status
a.service'

Regards
Lukas

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

Re: [systemd-devel] [PATCH] do not ellipsize cgroup members in full status

[Lukáš Nykrýn]

Lennart Poettering píše v Pá 21. 09. 2012 v 12:22 +0200:
 On Thu, 20.09.12 16:30, Lukáš Nykrýn (lnyk...@redhat.com) wrote:
 
  Hello,
  From bug report: https://bugzilla.redhat.com/show_bug.cgi?id=858693
  There is no easy way how to force systemctl status not to crop long
  lines with ellipsis in a virtual terminal. -a or --full options
  doesn't help (and they even shouldn't help, according to the man page)
  
  I am not sure if there should be additional parameter or extend --full,
  but systemctl has already enough parameters.
 
 Using --full for this sounds like a good idea.
 
 Insted of using UINT_MAX here as special value I'd prefer if we could
 follow the semantics of logs-show.h here more closely and introduce a
 bit field?
 
 Lennart
 

I think that in this case we can use the OutputFlags so here is reworked
patch.

Regards
Lukas
From 4d5427101094a29a125176d0010842b3093184fb Mon Sep 17 00:00:00 2001
From: Lukas Nykryn lnyk...@redhat.com
Date: Tue, 25 Sep 2012 15:30:03 +0200
Subject: [PATCH] systemctl: do not ellipsize cgroup members in full status

---
 man/systemctl.xml |2 +-
 src/cgls/cgls.c   |6 ++--
 src/core/selinux-access.c |4 +-
 src/journal/coredump.c|2 +-
 src/journal/journald.c|2 +-
 src/login/loginctl.c  |4 +-
 src/shared/cgroup-show.c  |   36 ++--
 src/shared/cgroup-show.h  |9 +++--
 src/shared/logs-show.h|   20 ---
 src/shared/util.c |   81 +++--
 src/shared/util.h |   22 -
 src/systemctl/systemctl.c |   14 
 12 files changed, 110 insertions(+), 92 deletions(-)

diff --git a/man/systemctl.xml b/man/systemctl.xml
index fedc588..eacd2ed 100644
--- a/man/systemctl.xml
+++ b/man/systemctl.xml
@@ -151,7 +151,7 @@
 termoption--full/option/term
 
 listitemparaDo not ellipsize unit
-names and truncate unit descriptions
+names, cgroup members and truncate unit descriptions
 in the output of
 commandlist-units/command and
 commandlist-jobs/command./para/listitem
diff --git a/src/cgls/cgls.c b/src/cgls/cgls.c
index b2cd968..c7c368d 100644
--- a/src/cgls/cgls.c
+++ b/src/cgls/cgls.c
@@ -132,7 +132,7 @@ int main(int argc, char *argv[]) {
 int q;
 printf(%s:\n, argv[i]);
 
-q = show_cgroup_by_path(argv[i], NULL, 0, arg_kernel_threads, arg_all);
+q = show_cgroup_by_path(argv[i], NULL, 0, arg_kernel_threads, arg_all, 0);
 if (q  0)
 r = q;
 }
@@ -148,7 +148,7 @@ int main(int argc, char *argv[]) {
 
 if (path_startswith(p, /sys/fs/cgroup)) {
 printf(Working Directory %s:\n, p);
-r = show_cgroup_by_path(p, NULL, 0, arg_kernel_threads, arg_all);
+r = show_cgroup_by_path(p, NULL, 0, arg_kernel_threads, arg_all, 0);
 } else {
 char *root = NULL;
 const char *t = NULL;
@@ -163,7 +163,7 @@ int main(int argc, char *argv[]) {
 t = root[0] ? root : /;
 }
 
-r = show_cgroup(SYSTEMD_CGROUP_CONTROLLER, t, NULL, 0, arg_kernel_threads, arg_all);
+r = show_cgroup(SYSTEMD_CGROUP_CONTROLLER, t, NULL, 0, arg_kernel_threads, arg_all, 0);
 free(root);
 }
 
diff --git a/src/core/selinux-access.c b/src/core/selinux-access.c
index 8513634..c4a0901 100644
--- a/src/core/selinux-access.c
+++ b/src/core/selinux-access.c
@@ -236,7 +236,7 @@ static int bus_get_audit_data(
 if (r  0)
 return r;
 
-r = get_process_cmdline(pid, LINE_MAX, true, audit-cmdline);
+r = get_process_cmdline(pid, LINE_MAX, true, audit-cmdline, 0);
 if (r  0)
 return r;
 
@@ -372,7 +372,7 @@ static int get_audit_data(
 if (r  0)
 return r;
 
-r = get_process_cmdline(ucred.pid, LINE_MAX, true, audit-cmdline);
+r = get_process_cmdline(ucred.pid, LINE_MAX, true, audit-cmdline, 0);
 if (r  0)
 return r;
 
diff --git a/src/journal/coredump.c b/src/journal/coredump.c
index a507fc6..8dfadbd 100644
--- a/src/journal/coredump.c
+++ b/src/journal/coredump.c
@@ -205,7 +205,7 @@ int main(int argc, char* argv[]) {
 IOVEC_SET_STRING(iovec[j++], core_exe);
 }
 
-if (get_process_cmdline(pid, LINE_MAX, false, t) = 0) {
+if (get_process_cmdline(pid, LINE_MAX, false, t, 0) = 0) {
 core_cmdline = strappend

[systemd-devel] [PATCH] missing va_end

[Lukáš Nykrýn]

Hello,
coverity scan 189-190 only complained about three missing va_ends.
See attached patches.

Regards
Lukas
From 8b5667702257bc561ba7a67301080f0092538333 Mon Sep 17 00:00:00 2001
From: Lukas Nykryn lnyk...@redhat.com
Date: Fri, 21 Sep 2012 10:22:46 +0200
Subject: [PATCH 1/2] shared: call va_end in all cases

---
 src/shared/log.c  |2 +-
 src/shared/util.c |4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/shared/log.c b/src/shared/log.c
index 7b0a914..b618458 100644
--- a/src/shared/log.c
+++ b/src/shared/log.c
@@ -719,7 +719,6 @@ int log_struct_internal(
 
 format = va_arg(ap, char *);
 }
-va_end(ap);
 
 zero(mh);
 mh.msg_iov = iovec;
@@ -731,6 +730,7 @@ int log_struct_internal(
 r = 1;
 
 finish:
+va_end(ap);
 for (i = 1; i  n; i += 2)
 free(iovec[i].iov_base);
 
diff --git a/src/shared/util.c b/src/shared/util.c
index be94515..97f766c 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -5024,8 +5024,10 @@ char *strjoin(const char *x, ...) {
 break;
 
 n = strlen(t);
-if (n  ((size_t) -1) - l)
+if (n  ((size_t) -1) - l) {
+va_end(ap);
 return NULL;
+}
 
 l += n;
 }
-- 
1.7.6.5

From 2f0091c2b0991e6d689fb9ea83a310874b2c0467 Mon Sep 17 00:00:00 2001
From: Lukas Nykryn lnyk...@redhat.com
Date: Fri, 21 Sep 2012 10:23:08 +0200
Subject: [PATCH 2/2] core: call va_end in all cases

---
 src/core/selinux-access.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/src/core/selinux-access.c b/src/core/selinux-access.c
index 8a84071..8513634 100644
--- a/src/core/selinux-access.c
+++ b/src/core/selinux-access.c
@@ -276,6 +276,7 @@ static int log_callback(int type, const char *fmt, ...)
 vsnprintf(buf, sizeof(buf), fmt, ap);
 audit_log_user_avc_message(audit_fd, AUDIT_USER_AVC,
buf, NULL, NULL, NULL, 0);
+va_end(ap);
 return 0;
 }
 #endif
-- 
1.7.6.5

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

[systemd-devel] [PATCH] do not ellipsize cgroup members in full status

[Lukáš Nykrýn]

Hello,
From bug report: https://bugzilla.redhat.com/show_bug.cgi?id=858693
There is no easy way how to force systemctl status not to crop long
lines with ellipsis in a virtual terminal. -a or --full options
doesn't help (and they even shouldn't help, according to the man page)

I am not sure if there should be additional parameter or extend --full,
but systemctl has already enough parameters.

Regards
Lukas
From a7f8b7492c273b3878122822f517be7d7e185b5c Mon Sep 17 00:00:00 2001
From: Lukas Nykryn lnyk...@redhat.com
Date: Thu, 20 Sep 2012 16:17:52 +0200
Subject: [PATCH] systemctl: do not ellipsize cgroup members in full status

---
 man/systemctl.xml |2 +-
 src/shared/cgroup-show.c  |   13 ---
 src/shared/util.c |   79 +++-
 src/systemctl/systemctl.c |   15 +---
 4 files changed, 65 insertions(+), 44 deletions(-)

diff --git a/man/systemctl.xml b/man/systemctl.xml
index fedc588..eacd2ed 100644
--- a/man/systemctl.xml
+++ b/man/systemctl.xml
@@ -151,7 +151,7 @@
 termoption--full/option/term
 
 listitemparaDo not ellipsize unit
-names and truncate unit descriptions
+names, cgroup members and truncate unit descriptions
 in the output of
 commandlist-units/command and
 commandlist-jobs/command./para/listitem
diff --git a/src/shared/cgroup-show.c b/src/shared/cgroup-show.c
index 9003a12..1b9f3cd 100644
--- a/src/shared/cgroup-show.c
+++ b/src/shared/cgroup-show.c
@@ -75,11 +75,12 @@ static void show_pid_array(int pids[], unsigned n_pids, const char *prefix, unsi
 /* And sort */
 qsort(pids, n_pids, sizeof(pid_t), compare);
 
-if (n_columns  8)
-n_columns -= 8;
-else
-n_columns = 20;
-
+if (n_columns != UINT_MAX) {
+if (n_columns  8)
+n_columns -= 8;
+else
+n_columns = 20;
+}
 for (i = 0; i  n_pids; i++) {
 char *t = NULL;
 
@@ -217,7 +218,7 @@ int show_cgroup_by_path(const char *path, const char *prefix, unsigned n_columns
 }
 }
 
-show_cgroup_by_path(last, p1, n_columns-2, kernel_threads, all);
+show_cgroup_by_path(last, p1, n_columns == UINT_MAX ? n_columns : n_columns-2, kernel_threads, all);
 free(last);
 }
 
diff --git a/src/shared/util.c b/src/shared/util.c
index 02ee637..570da7c 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -972,10 +972,8 @@ int get_process_comm(pid_t pid, char **name) {
 }
 
 int get_process_cmdline(pid_t pid, size_t max_length, bool comm_fallback, char **line) {
-char *r, *k;
+char *r = NULL, *k;
 int c;
-bool space = false;
-size_t left;
 FILE *f;
 
 assert(max_length  0);
@@ -994,47 +992,66 @@ int get_process_cmdline(pid_t pid, size_t max_length, bool comm_fallback, char *
 
 if (!f)
 return -errno;
+if (max_length != UINT_MAX) {
+bool space = false;
+size_t left;
+r = new(char, max_length);
+if (!r) {
+fclose(f);
+return -ENOMEM;
+}
 
-r = new(char, max_length);
-if (!r) {
-fclose(f);
-return -ENOMEM;
-}
+k = r;
+left = max_length;
+while ((c = getc(f)) != EOF) {
+
+if (isprint(c)) {
+if (space) {
+if (left = 4)
+break;
 
-k = r;
-left = max_length;
-while ((c = getc(f)) != EOF) {
+*(k++) = ' ';
+left--;
+space = false;
+}
 
-if (isprint(c)) {
-if (space) {
 if (left = 4)
 break;
 
-*(k++) = ' ';
+*(k++) = (char) c;
 left--;
-space = false;
-}
-
-if (left = 4)
-break;
+}  else
+space = true;
+}
 
-*(k++) = (char) c;
-left--;
-}  else
-space = true;
+

[systemd-devel] [PATCH] don't check ratelimit on manual start

[Lukáš Nykrýn]

Hello,
I have here a request that systemd should not refuse to start service because 
of start request repeated too quickly when service is started manually.
I have prepared a patch, but I am not sure about my approach.

Regards
Lukas
From b8e14cc91aea183aa21dc9173a44618b70dca190 Mon Sep 17 00:00:00 2001
From: Lukas Nykryn lnyk...@redhat.com
Date: Fri, 17 Aug 2012 14:44:31 +0200
Subject: [PATCH] core: don't check ratelimit on manual start

---
 src/core/automount.c|2 +-
 src/core/dbus-manager.c |2 +-
 src/core/dbus-unit.c|2 +-
 src/core/dbus.c |2 +-
 src/core/job.h  |1 +
 src/core/main.c |2 +-
 src/core/manager.c  |6 +++---
 src/core/manager.h  |2 +-
 src/core/path.c |2 +-
 src/core/service.c  |4 ++--
 src/core/socket.c   |4 ++--
 src/core/timer.c|2 +-
 src/core/transaction.c  |   33 +
 src/core/transaction.h  |4 ++--
 src/core/unit.c |   22 +++---
 src/test/test-engine.c  |   20 ++--
 16 files changed, 56 insertions(+), 54 deletions(-)

diff --git a/src/core/automount.c b/src/core/automount.c
index c4a7528..e9696bd 100644
--- a/src/core/automount.c
+++ b/src/core/automount.c
@@ -598,7 +598,7 @@ static void automount_enter_runnning(Automount *a) {
 
 if (!S_ISDIR(st.st_mode) || st.st_dev != a-dev_id)
 log_info(%s's automount point already active?, UNIT(a)-id);
-else if ((r = manager_add_job(UNIT(a)-manager, JOB_START, UNIT_DEREF(a-mount), JOB_REPLACE, true, error, NULL))  0) {
+else if ((r = manager_add_job(UNIT(a)-manager, JOB_START, UNIT_DEREF(a-mount), JOB_REPLACE, true, false, error, NULL))  0) {
 log_warning(%s failed to queue mount startup job: %s, UNIT(a)-id, bus_error(error, r));
 goto fail;
 }
diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
index c341d36..a389142 100644
--- a/src/core/dbus-manager.c
+++ b/src/core/dbus-manager.c
@@ -1562,7 +1562,7 @@ static DBusHandlerResult bus_manager_message_handler(DBusConnection *connection,
 return bus_send_error_reply(connection, message, error, -EPERM);
 }
 
-if ((r = manager_add_job(m, job_type, u, mode, true, error, j))  0)
+if ((r = manager_add_job(m, job_type, u, mode, true, true, error, j))  0)
 return bus_send_error_reply(connection, message, error, r);
 
 cl = job_bus_client_new(connection, message_get_sender_with_fallback(message));
diff --git a/src/core/dbus-unit.c b/src/core/dbus-unit.c
index ad817d7..d1a548a 100644
--- a/src/core/dbus-unit.c
+++ b/src/core/dbus-unit.c
@@ -508,7 +508,7 @@ static DBusHandlerResult bus_unit_message_dispatch(Unit *u, DBusConnection *conn
 return bus_send_error_reply(connection, message, error, -EINVAL);
 }
 
-if ((r = manager_add_job(m, job_type, u, mode, true, error, j))  0)
+if ((r = manager_add_job(m, job_type, u, mode, true, false, error, j))  0)
 return bus_send_error_reply(connection, message, error, r);
 
 if (!(reply = dbus_message_new_method_return(message)))
diff --git a/src/core/dbus.c b/src/core/dbus.c
index 9db172b..3bb90f0 100644
--- a/src/core/dbus.c
+++ b/src/core/dbus.c
@@ -375,7 +375,7 @@ static DBusHandlerResult api_bus_message_filter(DBusConnection *connection, DBus
 r = -EPERM;
 
 if (r = 0)
-r = manager_add_job(m, JOB_START, u, JOB_REPLACE, true, error, NULL);
+r = manager_add_job(m, JOB_START, u, JOB_REPLACE, true, false, error, NULL);
 }
 
 if (r  0) {
diff --git a/src/core/job.h b/src/core/job.h
index 349fb68..b16e4f1 100644
--- a/src/core/job.h
+++ b/src/core/job.h
@@ -161,6 +161,7 @@ struct Job {
 bool sent_dbus_new_signal:1;
 bool ignore_order:1;
 bool forgot_bus_clients:1;
+bool user_start:1;
 };
 
 JobBusClient* job_bus_client_new(DBusConnection *connection, const char *name);
diff --git a/src/core/main.c b/src/core/main.c
index cdd77c1..151bc17 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -1601,7 +1601,7 @@ int main(int argc, char *argv[]) {
 manager_dump_units(m, stdout, \t);
 }
 
-r = manager_add_job(m, JOB_START, target, JOB_REPLACE, false, error, default_unit_job);
+r = manager_add_job(m, JOB_START, target, JOB_REPLACE, false, false, error, default_unit_job);
 if (r  0) {
 log_error(Failed to start default target: %s, bus_error(error, r));
 dbus_error_free(error);
diff --git a/src/core/manager.c 

[systemd-devel] systemd coverity

[Lukáš Nykrýn]

Hello,
Coverity found some new small issues between releases 185-188. See attached 
patches.

Regards
Lukas

From b258ab8b5fec97e924ba5d3784be9b72d7966118 Mon Sep 17 00:00:00 2001
From: Lukas Nykryn lnyk...@redhat.com
Date: Mon, 20 Aug 2012 14:33:21 +0200
Subject: [PATCH 1/4] load-fragment: initialize bool invert before use

---
 src/core/load-fragment.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/core/load-fragment.c b/src/core/load-fragment.c
index 1068130..47a7f4f 100644
--- a/src/core/load-fragment.c
+++ b/src/core/load-fragment.c
@@ -2028,7 +2028,7 @@ int config_parse_syscall_filter(
 
 ExecContext *c = data;
 Unit *u = userdata;
-bool invert;
+bool invert = false;
 char *w;
 size_t l;
 char *state;
-- 
1.7.6.5

From 72b050672944143d846bc2059e2dec5ea7ad04fb Mon Sep 17 00:00:00 2001
From: Lukas Nykryn lnyk...@redhat.com
Date: Mon, 20 Aug 2012 14:39:08 +0200
Subject: [PATCH 2/4] login: check return of parse_pid and parse_uid

---
 src/login/logind-inhibit.c |   10 --
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/login/logind-inhibit.c b/src/login/logind-inhibit.c
index 96b7c6c..1803f8a 100644
--- a/src/login/logind-inhibit.c
+++ b/src/login/logind-inhibit.c
@@ -220,10 +220,16 @@ int inhibitor_load(Inhibitor *i) {
 i-mode = mm;
 
 if (uid)
-parse_uid(uid, i-uid);
+r = parse_uid(uid, i-uid);
+
+if (r  0)
+goto finish;
 
 if (pid)
-parse_pid(pid, i-pid);
+r = parse_pid(pid, i-pid);
+
+if (r  0)
+goto finish;
 
 if (who) {
 cc = cunescape(who);
-- 
1.7.6.5

From 36642c2aef0c441da508c1bb7ff68d69441f023f Mon Sep 17 00:00:00 2001
From: Lukas Nykryn lnyk...@redhat.com
Date: Mon, 20 Aug 2012 14:52:07 +0200
Subject: [PATCH 3/4] core: free word later in parse_proc_cmdline

---
 src/core/main.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/core/main.c b/src/core/main.c
index cdd77c1..16e8b35 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -727,12 +727,13 @@ static int parse_proc_cmdline(void) {
 }
 
 r = parse_proc_cmdline_word(word);
-free(word);
-
 if (r  0) {
 log_error(Failed on cmdline argument %s: %s, word, strerror(-r));
+free(word);
 goto finish;
 }
+
+free(word);
 }
 
 r = 0;
-- 
1.7.6.5

From e455c40879578901943ce16f000b671449a9fc5a Mon Sep 17 00:00:00 2001
From: Lukas Nykryn lnyk...@redhat.com
Date: Mon, 20 Aug 2012 15:15:40 +0200
Subject: [PATCH 4/4] readahead-analyze: don't call fclose on null

---
 src/readahead/readahead-analyze.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/src/readahead/readahead-analyze.c b/src/readahead/readahead-analyze.c
index 11b2b2d..9a929c0 100644
--- a/src/readahead/readahead-analyze.c
+++ b/src/readahead/readahead-analyze.c
@@ -144,6 +144,7 @@ int main_analyze(const char *pack_path) {
 return EXIT_SUCCESS;
 
 fail:
-fclose(pack);
+if(pack)
+fclose(pack);
 return EXIT_FAILURE;
 }
-- 
1.7.6.5

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

Re: [systemd-devel] [PATCH] service: allow service to inhibit respawn with special return code

[Lukáš Nykrýn]

Lennart Poettering píše v St 08. 08. 2012 v 19:26 +0200:
 On Mon, 06.08.12 17:16, Lukáš Nykrýn (lnyk...@redhat.com) wrote:
 
  Again thanks for review. Here is modified patch.
  If you think that it would be better to add signal stuff before
  accepting this patch I will not disagree.
 
  +r = set_put(*set, INT_TO_PTR(val));
 
 Hmm, so I was about to merge this, but there is a problem here: exit
 code 0 is added to the set as NULL, and that's what we return if
 something is *not* in the set. So we'll always mishandle exit code 0
 like this.
 
 We probably need some code here that just adds one to all exit codes, so
 that we can safely distuingish exit code 0 from not in this set. And
 that probably means the parsing function needs to be renamed a bit, to
 include plus_one or so...
 
 Lennart
 

Sorry for delay. I have rewrote the patch and added posibility to set
successful return statuses and now you can also specify signals.

Lukas 
From 65bc722b758d2906be8e811979eee9a5e0640e28 Mon Sep 17 00:00:00 2001
From: Lukas Nykryn lnyk...@redhat.com
Date: Mon, 13 Aug 2012 13:58:01 +0200
Subject: [PATCH] service: add options RestartPreventExitStatus and
 SuccessfulExitStatus

In some cases, like wrong configuration, restarting after error
does not help, so administrator can specify statuses by RestartPreventExitStatus
which will not cause restart of a service.

Sometimes you have non-standart exit status, so this can be specified
by SuccessfulExitStatus.
---
 man/systemd.service.xml   |   14 +++
 src/core/load-fragment-gperf.gperf.m4 |2 +
 src/core/mount.c  |2 +-
 src/core/service.c|   20 +-
 src/core/service.h|3 +
 src/core/socket.c |2 +-
 src/core/swap.c   |2 +-
 src/remount-fs/remount-fs.c   |2 +-
 src/shared/conf-parser.c  |   69 +
 src/shared/conf-parser.h  |1 +
 src/shared/exit-status.c  |   16 +--
 src/shared/exit-status.h  |   11 -
 src/shared/hashmap.c  |   15 +++
 src/shared/hashmap.h  |1 +
 src/shared/set.c  |4 ++
 src/shared/set.h  |1 +
 src/shared/util.c |2 +-
 src/systemctl/systemctl.c |2 +-
 18 files changed, 153 insertions(+), 16 deletions(-)

diff --git a/man/systemd.service.xml b/man/systemd.service.xml
index 1946d85..c587847 100644
--- a/man/systemd.service.xml
+++ b/man/systemd.service.xml
@@ -580,6 +580,20 @@
 /varlistentry
 
 varlistentry
+termvarnameRestartPreventExitStatus=/varname/term
+listitemparaSpecify exit status list, which
+will prevent service from restart. Codes are
+separated by whitespace (e.g. 1 6 SIGKILL)./para/listitem
+/varlistentry
+
+varlistentry
+termvarnameSuccessfulExitStatus=/varname/term
+listitemparaSpecify exit status list, which
+will be considered as successful exit. Codes are
+separated by whitespace (e.g. 1 6 SIGKILL)./para/listitem
+/varlistentry
+
+varlistentry
 termvarnamePermissionsStartOnly=/varname/term
 listitemparaTakes a boolean
 argument. If true, the permission
diff --git a/src/core/load-fragment-gperf.gperf.m4 b/src/core/load-fragment-gperf.gperf.m4
index e738213..0674fe6 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -158,6 +158,8 @@ Service.PermissionsStartOnly,config_parse_bool,  0,
 Service.RootDirectoryStartOnly,  config_parse_bool,  0, offsetof(Service, root_directory_start_only)
 Service.RemainAfterExit, config_parse_bool,  0, offsetof(Service, remain_after_exit)
 Service.GuessMainPID,config_parse_bool,  0, offsetof(Service, guess_main_pid)
+Service.RestartPreventExitStatus, config_parse_set_status,   0, offsetof(Service, restart_ignore_status)
+Service.SuccessfulExitStatus,config_parse_set_status,0, offsetof(Service, successful_status)
 m4_ifdef(`HAVE_SYSV_COMPAT',
 `Service.SysVStartPriority,  config_parse_sysv_priority, 0, offsetof(Service, sysv_start_priority)',
 `Service.SysVStartPriority,  config_parse_warn_compat,   0

Re: [systemd-devel] [PATCH] service: allow service to inhibit respawn with special return code

[Lukáš Nykrýn]

Lennart Poettering píše v Pá 03. 08. 2012 v 20:46 +0200:
 On Tue, 24.07.12 16:43, Lukas Nykryn (lnyk...@redhat.com) wrote:
 
  In some cases, like wrong configuration, restarting after error
  exit code does not help, so administrator can specify RestartIgnoreCodes
  which will not cause restart of a service.
 
 I am not happy with the term Code here, it's a bit too generic to be
 self explanatory.
 
 And I think I agree with Zbigniew to a certain degree: we might want to
 think about whether we should also allow configuring non-failure exit
 codes or so. I mean, I am not suggesting we should implement that
 right-away, but just keep in mind how that setting would look like so
 that we can keep things uniform if we add it later. (In fact, I'd
 recommend not to implement it right away: adding an option nobody so far
 needed seems like a bad idea if we want to keep our set of options
 minimal).
 
 Also, I think we need to think further than just exit codes,
 i.e. signals and stuff.
 
 Maybe DontRestartExitStatus=? The libc calls the generalization of
 exit code and exit signal the exit status, so that sounds like the
 best term to use here.
 
 And then people could write:
 
DontRestartExitStatus=SIGTERM 1 2 3 4
 
 or something like this?
 
 (Of course, the don't in the name is a negative option, which we try
 to avoid, but it appears weird to have a positive option for this, so i
 think it would be ok...)
 
 One day, if we really need to make the failure/success sets configurable
 too, we could then add:
 
DontFailExitStatus=SIGSEGV 1 2
 
 (But please, don't implement this bit just yet, let's wait for somebody
 actually needing this. Note though, that Upstart actually does have
 functionality like this).
 
  +*ignored = new(int, k);
 
 Maybe use a bitfield here, like we do for the syscalls list?
 
 (Actualy two bitfields, one for the exit codes, one for the exit signals).
 
  +static int check_ignored_rc(Service *s){
 
 Please don't use acronyms in symbols if it's easy to avoid them and no
 strong incentive to use them.
 
  +int n_restart_ignored_codes;
 
 Generally we try to used unsigned rather than int for values where
 negative values really never make sense, like in this case. It gives
 readers a bit of a hint that this field never can be negative and no
 special cases like that are used.
 
 Otherwise looks good.
 
 Lennart
 

Thanks for the feedback. I have altered name of the option to
RestartIgnoreExitStatus, but feel free to change to anything else and I
have also stored the codes to a set instead of an array.

Lukas


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

Re: [systemd-devel] [PATCH] service: allow service to inhibit respawn with special return code

[Lukáš Nykrýn]

Lukáš Nykrýn píše v Po 06. 08. 2012 v 15:26 +0200:
 Lennart Poettering píše v Pá 03. 08. 2012 v 20:46 +0200:
  On Tue, 24.07.12 16:43, Lukas Nykryn (lnyk...@redhat.com) wrote:
  
   In some cases, like wrong configuration, restarting after error
   exit code does not help, so administrator can specify RestartIgnoreCodes
   which will not cause restart of a service.
  
  I am not happy with the term Code here, it's a bit too generic to be
  self explanatory.
  
  And I think I agree with Zbigniew to a certain degree: we might want to
  think about whether we should also allow configuring non-failure exit
  codes or so. I mean, I am not suggesting we should implement that
  right-away, but just keep in mind how that setting would look like so
  that we can keep things uniform if we add it later. (In fact, I'd
  recommend not to implement it right away: adding an option nobody so far
  needed seems like a bad idea if we want to keep our set of options
  minimal).
  
  Also, I think we need to think further than just exit codes,
  i.e. signals and stuff.
  
  Maybe DontRestartExitStatus=? The libc calls the generalization of
  exit code and exit signal the exit status, so that sounds like the
  best term to use here.
  
  And then people could write:
  
 DontRestartExitStatus=SIGTERM 1 2 3 4
  
  or something like this?
  
  (Of course, the don't in the name is a negative option, which we try
  to avoid, but it appears weird to have a positive option for this, so i
  think it would be ok...)
  
  One day, if we really need to make the failure/success sets configurable
  too, we could then add:
  
 DontFailExitStatus=SIGSEGV 1 2
  
  (But please, don't implement this bit just yet, let's wait for somebody
  actually needing this. Note though, that Upstart actually does have
  functionality like this).
  
   +*ignored = new(int, k);
  
  Maybe use a bitfield here, like we do for the syscalls list?
  
  (Actualy two bitfields, one for the exit codes, one for the exit signals).
  
   +static int check_ignored_rc(Service *s){
  
  Please don't use acronyms in symbols if it's easy to avoid them and no
  strong incentive to use them.
  
   +int n_restart_ignored_codes;
  
  Generally we try to used unsigned rather than int for values where
  negative values really never make sense, like in this case. It gives
  readers a bit of a hint that this field never can be negative and no
  special cases like that are used.
  
  Otherwise looks good.
  
  Lennart
  
 
 Thanks for the feedback. I have altered name of the option to
 RestartIgnoreExitStatus, but feel free to change to anything else and I
 have also stored the codes to a set instead of an array.
 
 Lukas

forgotten patch

From 81ffeefb01aa73c3be2b2bba7500df5f8ebcdfc9 Mon Sep 17 00:00:00 2001
From: Lukas Nykryn lnyk...@redhat.com
Date: Mon, 6 Aug 2012 14:54:03 +0200
Subject: [PATCH] service: allow service to inhibit respawn with special
 return code

In some cases, like wrong configuration, restarting after error
does not help, so administrator can specify statuses by RestartPreventExitStatus
which will not cause restart of a service.
---
 man/systemd.service.xml   |7 
 src/core/load-fragment-gperf.gperf.m4 |1 +
 src/core/service.c|7 +++-
 src/core/service.h|1 +
 src/shared/conf-parser.c  |   60 +
 src/shared/conf-parser.h  |1 +
 6 files changed, 76 insertions(+), 1 deletions(-)

diff --git a/man/systemd.service.xml b/man/systemd.service.xml
index f43201d..8533136 100644
--- a/man/systemd.service.xml
+++ b/man/systemd.service.xml
@@ -558,6 +558,13 @@
 /varlistentry
 
 varlistentry
+termvarnameRestartPreventExitStatus=/varname/term
+listitemparaSpecify return codes list, which
+will prevent service from restart. Codes are
+separated by whitespace./para/listitem
+/varlistentry
+
+varlistentry
 termvarnamePermissionsStartOnly=/varname/term
 listitemparaTakes a boolean
 argument. If true, the permission
diff --git a/src/core/load-fragment-gperf.gperf.m4 b/src/core/load-fragment-gperf.gperf.m4
index 2b1cfa0..d077376 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -156,6 +156,7 @@ Service.PermissionsStartOnly,config_parse_bool,  0,
 Service.RootDirectoryStartOnly,  config_parse_bool,  0, offsetof(Service, root_directory_start_only)
 Service.RemainAfterExit, config_parse_bool,  0, offsetof(Service, remain_after_exit)
 Service.GuessMainPID

Re: [systemd-devel] [PATCH] service: allow service to inhibit respawn with special return code

[Lukáš Nykrýn]

Lennart Poettering píše v Po 06. 08. 2012 v 16:52 +0200:
 On Mon, 06.08.12 16:45, Lukáš Nykrýn (lnyk...@redhat.com) wrote:
 
  +if (!*set) {
  +set_free(*set);
  +*set = NULL;
  +}
 
 You probably mean if (*set) here, not (!*set). But honestly I think this
 bit should just go entirely as for most other settings we actually do
 allow adding in additional values later on if it makes sense (example:
 Environment=). 
 
  +
  +*set = set_new(trivial_hash_func, trivial_compare_func);
  +if (!*set)
  +return -ENOMEM;
 
 We probably should start using log_oom() for things like this now that
 it is available.
 
  +
  +FOREACH_WORD(w, l, rvalue, state)
  +{
  +char *temp = new0(char, l + 1);
  +if (!temp)
  +return -ENOMEM;
 
 Please use strndup() here! (And also log_oom() here please).
 
  +
  +strncpy(temp, w, l);
  +r = safe_atoi(temp, val);
  +free(temp);
  +if (r  0) {
  +log_error([%s:%u] Failed to parse numeric value: 
  %s, filename, line, w);
  +set_free(*set);
  +*set = NULL;
 
 I'd leave the hashmap set, as it is freed anyway when the service goes
 away, and makes simpler and easier to read.
 
  +return r;
  +}
  +r = set_put(*set, INT_TO_PTR(val));
  +if (r  0) {
  +log_error([%s:%u] Unable to store: %s, filename, 
  line, w);
  +set_free(*set);
  +*set = NULL;
 
 Same here.
 
 Otherwise looks good.
 
 (We want the signal stuff eventually I guess, but we can easily add this 
 later).
 
 Lennart
 
Again thanks for review. Here is modified patch.
If you think that it would be better to add signal stuff before
accepting this patch I will not disagree.

Lukas
From 986dc67a74a4386e3e95f1b09cfa36dd71b77321 Mon Sep 17 00:00:00 2001
From: Lukas Nykryn lnyk...@redhat.com
Date: Mon, 6 Aug 2012 14:54:03 +0200
Subject: [PATCH] service: allow service to inhibit respawn with special
 return code

In some cases, like wrong configuration, restarting after error
does not help, so administrator can specify statuses by RestartPreventExitStatus
which will not cause restart of a service.
---
 man/systemd.service.xml   |7 
 src/core/load-fragment-gperf.gperf.m4 |1 +
 src/core/service.c|7 -
 src/core/service.h|1 +
 src/shared/conf-parser.c  |   50 +
 src/shared/conf-parser.h  |1 +
 6 files changed, 66 insertions(+), 1 deletions(-)

diff --git a/man/systemd.service.xml b/man/systemd.service.xml
index f43201d..8533136 100644
--- a/man/systemd.service.xml
+++ b/man/systemd.service.xml
@@ -558,6 +558,13 @@
 /varlistentry
 
 varlistentry
+termvarnameRestartPreventExitStatus=/varname/term
+listitemparaSpecify return codes list, which
+will prevent service from restart. Codes are
+separated by whitespace./para/listitem
+/varlistentry
+
+varlistentry
 termvarnamePermissionsStartOnly=/varname/term
 listitemparaTakes a boolean
 argument. If true, the permission
diff --git a/src/core/load-fragment-gperf.gperf.m4 b/src/core/load-fragment-gperf.gperf.m4
index 2b1cfa0..d077376 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -156,6 +156,7 @@ Service.PermissionsStartOnly,config_parse_bool,  0,
 Service.RootDirectoryStartOnly,  config_parse_bool,  0, offsetof(Service, root_directory_start_only)
 Service.RemainAfterExit, config_parse_bool,  0, offsetof(Service, remain_after_exit)
 Service.GuessMainPID,config_parse_bool,  0, offsetof(Service, guess_main_pid)
+Service.RestartPreventExitStatus, config_parse_set_int,   0, offsetof(Service, restart_ignore_status)
 m4_ifdef(`HAVE_SYSV_COMPAT',
 `Service.SysVStartPriority,  config_parse_sysv_priority, 0, offsetof(Service, sysv_start_priority)',
 `Service.SysVStartPriority,  config_parse_warn_compat,   0, 0')
diff --git a/src/core/service.c b/src/core/service.c
index 1c127bd..ae894b7 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -293,6 +293,9 @@ static void service_done(Unit *u

Re: [systemd-devel] [PATCH] service: allow service to inhibit respawn with special return code

[Lukáš Nykrýn]

Zbigniew Jędrzejewski-Szmek píše v St 25. 07. 2012 v 01:19 +0200:
 On 07/24/2012 04:43 PM, Lukas Nykryn wrote:
  In some cases, like wrong configuration, restarting after error
  exit code does not help, so administrator can specify RestartIgnoreCodes
  which will not cause restart of a service.
 Hi,
 
 maybe this should be made more general, not only limited to restarting:
 wouldn't it be better to simply specify, which exit codes are supposed
 to mean success? Before there was a case with java, which would exit
 returning 1, even on success. It would be nice to solve that problem too.
 
 Zbyszek

Thanks for the suggestion, I did it this way, because this should be
solution for https://bugzilla.redhat.com/show_bug.cgi?id=807886. I am
not sure if I should rewrite it in more general way. If I am not
mistaken such behavior would also affect for example systemctl status
and then when service fails with wrong configuration, it would show as
success in status.

But I do not say that specifying concrete return codes as success is not
acceptable feature, but I would rather see this two option separately. 
I am going to rewrite this patch to use set instead of array, so I will
also write the second patch with general approach. 

Lukas

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

[systemd-devel] ctrl-s + shutdown

[Lukáš Nykrýn]

Hello,
A customer had complained about this behavior:
1) login to system
2) press ctrl+s
3) log to this computer from another machine using ssh
4) type shutdown -h now through ssh 
5) ?

Their problem is that in RHEL5(sysvinit) 5) is nothing until user press
ctrl+q, than shutdown but in RHEL6(upstart) system goes to shutdown
immediately. 

I was not sure which one is correct, so I tried what would systemd
(44-12.fc17) do in this case. 

Result are quite inconsistent. In some cases system shutdowns
immediately, sometime shutdown command hanged and system waited for
ctrl-q and few times ssh disconnect and screen went completely black and
system hanged.

Unfortunately I have only one f17 in virtual to test this, so I want to
ask if somebody else can try it and obvious question is: What is correct
behavior?

Regards
Lukas   


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