[systemd-devel] option to wait for pid file to appear

[Jonathan de Boyne Pollard]

Mantas Mikulėnas:
Maybe socket-activation would work for you? (With Nginx it's also a 
hack though.)


Accept=No
Environment=NGINX=3;

It is not terrifically complex.  The documented way to stop the forking 
is "daemon off", but an inherited listening socket also does it.


* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728015

* 
https://github.com/nginx/nginx/blob/8e8734ec82cde91a02d0cbfaae0d0df6b5aaab14/src/core/nginx.c#L347

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

[systemd-devel] forking PIDFile question

[Jonathan de Boyne Pollard]

st...@goodey.org:

[Service]

Type=forking



Your program has an -f option to stop it from vainly trying to 
re-daemonize itself.  Use it; and do not use Type=forking in the first 
place.


* 
http://jdebp.eu./FGA/unix-daemon-design-mistakes-to-avoid.html#DoNotBackgroundise


The supplied systemd service unit that comes packaged by Ubuntu/Debian 
does this.  You can ignore its use of -s 1 , as systemd will log the 
program's standard output and -s 0 will do quite well.


* 
https://sources.debian.org/src/lcdproc/0.5.9-2/debian/lcdproc.LCDd.service/


st...@goodey.org:


[server]

User=nobody


Also, do not abuse nobody for dæmons.  Use a dedicated unprivileged user 
account, such as (for example) lcdproc.  Name the unprivileged user 
account in the service unit in a User= setting, and using filesystem 
ACLs or otherwise grant it nothing except the permission to open 
/dev/ttyUSB0 for writing and to open the configuration file for reading.


* http://jdebp.eu./FGA/dont-abuse-nobody-for-daemons.html

Currently, you are running your program as the superuser with a 
configuration file owned by an unprivileged user.  This is a backdoor 
into your system, as anyone who compromises that unprivileged user 
account (which is the one that you run your WWW browser as, and that you 
use to run software build systems and other programs downloaded from 
other people that you do not know, ne?) can rewrite the configuration 
file and thereby persuade a superuser-privileged process to open an 
arbitrary file and write stuff (which it does before it attempts to 
detect whether it is running as the superuser).

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

[systemd-devel] Disabling tomcat8

[Jonathan de Boyne Pollard]

  
  

  Cecil Westerhof:


  

  Other services I can enable and disable.

  

And with chmod a-x /etc/init.d/tomcat8 you should
  be able to disable this one, too.  (-:
Read https://unix.stackexchange.com/a/394191/5132 for why.

  

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

[systemd-devel] Disabling tomcat8

[Jonathan de Boyne Pollard]

  
  

  Tom H:


  The usual reason for not having a native unit is that you can't
force developers to do that work.

Psst!  This discussion is predicated upon a falsehood.  There is
  an abundance of service units for Tomcat, and has been for years. 
  They are part
of the systemd House of Horror.  Sad to say: M. Westerhof
  has already found two of those.

  

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

[systemd-devel] Is this list still active? Where can I get basic help with systemd

[Jonathan de Boyne Pollard]

 Lennart Poettering:

Uh, I am not sure what celery is, but if celery is started but exitson 
its own then I am not sure I can help you very much.


Does it detach on its own? i.e. double fork? if yes, then type=forking 
is the right choice, otherwise you need a different Type=.




A tip from one of my service bundles:

# As of version 3.1, by default Celery does not "backgroundize" and logs 
to standard error, and one stops it with SIGKILL.

# See also https://github.com/celery/celery/issues/3459 .

Note in particular that Celery has its own %n%I system, as explained there.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] New reboot flag: -c for 'power cycle'

[Jonathan de Boyne Pollard]

Warner Losh, FreeBSD and embedded systems developer, has just invented a 
new shutdowngoal, in addition to the ones that we already know.  In 
addition to the conventional reset, power off, halt, and kexec goals; xe 
has added a power-off-and-then-on-again goal.  Xe has named it power 
cycle, and its use case is systems with hardware that can trigger a full 
power cycle under the kernel's controland where an ACPI reset or even an 
EFI ResetSystem() of type EfiResetColdjust do not cutthe mustard.


It involvesanew flag to the FreeBSD reboot() system call, RB_POWERCYCLE; 
new FreeBSD kernel functionality for enacting this with hardwares that 
support it; new -c (for "cycle") flags to the various reboot, halt, 
poweroff, and shutdown commands; and a new signal sent to process #1.


* https://marc.info/?l=freebsd-arch=150886821625848=2

* https://reviews.freebsd.org/D12777

This of course impacts those of us who write process #1 programs.

Since SIGWINCH to process #1 is already taken by Linux, I have adjusted 
my softwares to use SIGRTMIN+7 and SIGRTMIN+17 for the signals to 
process #1 for this, ready for when Linux eventually catches up with 
this idea.  (-:


(There is an on-going discussion of whether FreeBSD's old init program 
should use real-time signals, too.  It currently does not.But that is a 
side issue here. I have also added to my softwares powercycle and 
fastpowercycle commands and subcommands, a "c" or "C" argument to the 
compatibility telinit program (by analogy to the existing letters, 
although I might have to pick another letter), a powercycle target 
(again by analogy to existing targets), and a --powercycle long option 
equivalent for -c .)


Please do not use SIGRTMIN+7 and SIGRTMIN+17 for an incompatible purpose.

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

Re: [systemd-devel] Github systemd issue 6237

[Jonathan de Boyne Pollard]

Reindl Harald:
> at least fall back to “nobody”

Jonathan de Boyne Pollard:
> That idea is wrong.
>
> https://news.ycombinator.com/item?id=14681377#14682059

Reindl Harald:
> better than a stupid [...]

Not really, no.  It's the same category of error, in fact: substituting an
account other than the one that the system administrator explicitly said to drop
privileges to.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Github systemd issue 6237

[Jonathan de Boyne Pollard]

Reindl Harald:

> 
> at least fall back to "nobody"
> 

That idea is wrong.

https://news.ycombinator.com/item?id=14681377#14682059___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Service Type for Tomcat

[Jonathan de Boyne Pollard]

"Igal @ Lucee.org" <i...@lucee.org>:

> Examples I see online use forking [...]

Jonathan de Boyne Pollard:

> ... because they are bad examples. 
> Read http://jdebp.eu./FGA/systemd-house-of-horror/tomcat.html .

Andrei Borzenkov:

> Service type simple is the worst possible type as it does not provide 
> for any synchronization between started process and dependent 
> services.  So examples that recommend forking are correct (as long 
> as forking is implemented correctly).

... which it isn't.  Read
http://jdebp.eu./FGA/systemd-house-of-horror/tomcat.html again, properly this
time, and then read
http://jdebp.eu./FGA/unix-daemon-readiness-protocol-problems.html#NooneSpeaksForking
.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Service Type for Tomcat

[Jonathan de Boyne Pollard]

"Igal @ Lucee.org" :
> Examples I see online use forking [...]

... because they are bad examples.  Read
http://jdebp.eu./FGA/systemd-house-of-horror/tomcat.html .
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] General question about dbus-activatable services

[Jonathan de Boyne Pollard]

Christian Rebischke:
> I would like to start ibus-daemon automatically on login in my user session.

The person who told you that this was unnecessary because ibus already has a way
to run the daemon via "bus activation" is wrong.  There are various good reasons
to avoid bus activation, especially if one has a proper service management
subsystem available.  You are actually a fair portion of the way there.  You are
missing a couple of things, though.  Your systemd service unit is wrong, and
your DBus service definition is incomplete.

The goal is to connect the DBus broker with service management.  The way that
this all hangs together (in the wider world outwith systemd and Linux, as well)
is that a service client tells the DBus broker to auto-start the DBus service,
the DBus broker tells the service manager to start the service process, and the
service is marked as "ready" when it has registered a specific name with the
broker.

* http://jdebp.eu./Softwares/nosh/avoid-dbus-bus-activation.html
* http://jdebp.eu./Softwares/nosh/guide/per-user-dbus-demand-start.html

To achieve this, you first need to correct your systemd service unit.  The type
should be "bus", not "forking".  This tells systemd that the service is "ready"
when it has registered a particular name.  You also need to tell systemd this
name.  Moreover, you need to tell the daemon program not to erroneously fork in
a vain attempt to "daemonize" itself.  Hence:

> [Service]
> Type=bus
> ExecStart=/usr/bin/ibus-daemon --xim
> BusName=org.freedesktop.IBus

You also need to tell the DBus broker not to attempt to directly run the daemon,
but rather to run it indirectly by telling the service manager to start it.
 Your ibus/bus/org.freedesktop.IBus.service.in needs to read:

> [D-BUS Service]
> Name=org.freedesktop.IBus
> Exec=@bindir@/ibus-daemon --replace --xim --panel disable
> SystemdService=ibus.service

The DBus broker, as long as it has been invoked in such a way that it "knows"
that there's a service manager there, talks to the service manager to activate
the service.  There's nothing stopping you from enabling and starting it
yourself in the normal way (using the --user option to systemctl, remember) if
you don't want to rely upon on-demand activation by DBus service clients.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl status and service unit configuration with startup script that exits

[Jonathan de Boyne Pollard]

Owens, Stephen:

The start script calls other scripts to start two application 
components and then the start script exits.


One of the application components also spawns a couple of child processes.

There ends up being two pid files, one for each component, describing 
the state of the application.




You have two services.


Owens, Stephen:


Environment=JAVA_HOME=/opt/xxx/jre

ExecStart=/bin/bash -l /opt/xxx/bin/startApp.sh

ExecStop=-/bin/bash -lc "/opt/xxx/bin/stopApp.sh -np"



Java, again.  Java is for some reason a magnet for this sort of stuff.

* http://jdebp.eu./FGA/systemd-house-of-horror/


Owens, Stephen:

Is there some way I can have systemd monitor the component pids to 
show ACTIVE status?


You have two services.  Make two service units.  Forget the nutty 
startApp and stopApp scripts.  When you look into them you'll almost 
certainly find that they are a process supervisor in shell script, 
written badly as such things always are.  The systemd House of Horror 
has examples of running Java programs directly from service units (It 
isn't hard.) without the intermediate badly written shell script process 
supervisors.  Stack Exchange has stuff on this, too, and more besides.


* http://unix.stackexchange.com/a/320319/5132

* http://unix.stackexchange.com/a/245038/5132

* http://unix.stackexchange.com/a/322778/5132

* http://unix.stackexchange.com/a/229525/5132

* http://unix.stackexchange.com/a/324286/5132

* http://unix.stackexchange.com/a/321716/5132

* http://unix.stackexchange.com/a/280399/5132


Owens, Stephen:


I'm stuck with 3rd party startup scripts.



No, you are not.  This is just a belief and a self-imposed restriction, 
and it is groundless when it comes down to it.  Look into it, as other 
people have, and you'll find the world is quietly, and finally, coming 
around to the daemontools idea, that has been around since 1996, of 
letting the service manager do this.  The MariaDB world, for example, 
has finally officially let go of its wrapper process supervisor shell 
scripts and documented how to just run the daemon directly under a 
service manager, 13 years after daemontools users asked for this.


* http://jdebp.eu./Softwares/nosh/mariadb-and-mysql.html#Prompt

The irony is that if you actually look at your scripts that start/stop 
two services you will probably find that they are wrappers for wrappers, 
like the startdb.sh and stopdb.sh that these people wrote:


* http://itdadao.com/articles/c15a369637p0.html

* 
https://mohamedazar.com/2015/08/27/oracle-applications-r12-auto-start-on-linux/


Even if you hang on to the incorrect belief that these wrapper scripts 
are set in stone, there's a glaringly obvious decomposition into two 
parts in such cases.  You have two services.


Whenever you see the patterns ...


ExecStart=/opt/example/bin/something.sh start
ExecStop=/opt/example/bin/something.sh stop


or


ExecStart=/opt/example/bin/startSomething.sh
ExecStop=/opt/example/bin/stopSomething.sh


... the Oracle camelCase and the "stop"/"start" arguments are strong 
indicators that in fact those scripts will turn out to be process 
supervisors written badly in shell script, grepping the process tree, 
using PID files, doing their own service restarts with while loops and 
wait, creating private log files that only ever expand indefinitely, and 
running the actual service processes as a grandchild or even a 
great-grandchild of the main process.  (Some of the most stupid cases 
are when one strips away one unnecessary shell script badly written 
process supervisor, only to find that the process that it is supervising 
is itself *another* shell script badly written process supervisor.)


Another giveaway is the "I had to add RemainAfterExit=yes because 
otherwise it didn't work." as exemplified in the ridiculous edifice 
(that clearly hasn't been tested otherwise the invalid attempts at 
redirection would have been spotted, like they were in three of the 
Stack Exchange questions mentioned earlier) recommended by Oracle 
consultant Tim Hall here:


* 
https://oracle-base.com/articles/linux/linux-services-systemd#creating-linux-services


M. Hall had to add RemainAfterExit=yes because xe is running shell 
scripts that in turn fork and execute programs such as "lsnrctl" and 
"sqlplus", some of which in turn fork and execute further processes and 
exit the parent processes.  The shell scripts aren't necessary at all.  
Xe actually has two services, just like you.  In contrast: this person 
has, at least (the "something start/stop" layer that forks still being 
there), decomposed having two services into having two service definitions:


* https://server-world.info/en/note?os=CentOS_7=oracle12c=6

If one has to add RemainAfterExit=yes in order to bodge things, then its 
quite likely that one has built such a ridiculous edifice, too. The 
shell scripts are forking subprocesses to run non-builtin commands, 
which are in turn probably *more* shell scripts that *also* fork, 

Re: [systemd-devel] systemctl status and service unit configuration with startup script that exits

[Jonathan de Boyne Pollard]

Owens, Stephen:


UMask=0764



This is almost certainly wrong, by the way.

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

Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

[Jonathan de Boyne Pollard]

Lennart Poettering:

"nofail" has been around as long as fstab has been around really.


This is a falsehood.  /etc/fstab has a history that goes back to the 
20th century.  It was in UNIX System 5 Release 3, 4.2BSD, and OSF/1, for 
examples.  In contrast,  the "nofail" option was invented in December 
2007 for the Linux mount command by Matthias Koenig, Kay Sievers, and 
Karel Zak.


* http://marc.info/?l=util-linux-ng=118425639718187=2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Started process not attach to its related service.

[Jonathan de Boyne Pollard]

Benoit SCHMID:

 echo -n "Starting Oracle Listener: "
 su - $ORA_OWNR -c "env ORACLE_HOME=/oracle/XXX/12102 
/oracle/XXX/12102/bin/lsnrctl start LISTENER_XXX"


Don't abuse su for dropping privileges.

* http://jdebp.eu./FGA/dont-abuse-su-for-dropping-privileges.html


It's now 2016, and the first rule for migrating to systemd applies even 
to Oracle softwares.


* http://jdebp.eu./FGA/systemd-house-of-horror/daemonize.html#first-rule

* http://www.server-world.info/en/note?os=CentOS_7=oracle12c=6

* 
https://lists.freedesktop.org/archives/systemd-devel/2014-October/thread.html#24663


* https://www.realdbamagic.com/automatic-db-startup-linux-part-oel-6-7-2/

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

Re: [systemd-devel] autostart processes based on tty

[Jonathan de Boyne Pollard]

I would like to start different processes in different ttys on boot,


What you need is a Q WWW site.  (-:

* http://unix.stackexchange.com/questions/211544/
* http://askubuntu.com/questions/770673/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Support for large applications

[Jonathan de Boyne Pollard]

Avi Kivity:


We are using systemd to supervise our NoSQL database [...]

Sometimes [it needs] to perform expensive operations during startup 
(log replay, rebuild from network replica) before we can start 
serving. Rather than configure a huge start timeout, I'd prefer to 
have the service report progress to systemd so that it knows that 
startup is still in progress.


That's something for your database software to address, not systemd.  
Perhaps you will have better luck than the person who tried to get this 
with MySQL for four years, and instead merely received a tweak of the 
server exit code and a closure of the bug.  At least xe managed with 
MariaDB, though.  (-:


 *

   MariaDB Server: MDEV-5713: RFE: Add support for systemd notify
   feature 

 *

   MariaDB Server: MDEV-5536: Support systemd socket activation
   

 *

   MySQL Bugs: #65809: RFE: send a notify message to systemd daemon
   

 *

   MySQL :: WL#7895: Add systemd support to server
   

 *

   6 thoughts on “MySQL 5.7 — Native Systemd Support”
   

 *

   better systemd integration
   
   pgsql-hackers, Peter Eisentraut, 2015
   

 *

   pgsql: Add support for systemd service notifications
   


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

Re: [systemd-devel] No maintenance shell on local fs failure (/bin/sh: no such file or directory)

[Jonathan de Boyne Pollard]

Frank Steiner:


[...] I see such messages:


About to execute: /bin/echo -e 'Welcome to emergency mode! After logging in, ...
Forked /bin/echo as 4290
Failed at step CHDIR spawning /bin/echo: No such file or directory



[...] But |/usr/lib/systemd/system/emergency.service| contains:


[Service]
Environment=HOME=/root
WorkingDirectory=/root
...
ExecStartPre=-/bin/echo -e 'Welcome to emergency mode! After logging in, ...
ExecStart=-/bin/sh -c "/sbin/sulogin; /usr/bin/systemctl --fail --no-block 
default"
...



[...] That was caused by |/root| being a symbolic link to 
|/local/home/root| [...]




Andrei Borzenkov:


[...] So I would vote for changing it to |/| as well.


|
/bin/echo| certainly doesn't care what its working directory is.

When it comes to the later |ExecStart|, which hasn't yet been reached in 
the scenario at hand, the convention is that the "userinit" part of the 
procedure (i.e. the part that sets up the environment variables like 
|HOME|||and changes working directory) is the responsibility of the 
login program.  The |@SULOGIN@| that is Miquel van Smoorenburg's 
|sulogin| (as exemplified above) is no exception to this.


It /itself/ reads the home directory out of the password database, and 
changes directory to it and sets the |HOME| environment variable to it; 
without need for the invoking systemd unit to do so, and with less 
drastic failure modes in the absence of root's home directory or when 
the system administrator has decided that it isn't |/root|.  Witness:



if (chdir(pwd->pw_dir) < 0) {
if (chdir("/") < 0)
fprintf(stderr, "sulogin: change of working directory 
failed: %m\n\r");
}
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] The sixth field (fs_passno) should be zero

[Jonathan de Boyne Pollard]

Dimitri John Ledkov: > Most filesystems support destructive operations, 
with a goal to recover data via some-sort check/repair functionality 
e.g. btrfs check/rescue, xfs_repair etc. > Some filesystems also require 
periodic maintenance calls, e.g. something like the `harmless' fsck on 
each mount. > Some filesystems support both destructive recovery and 
periodic maintainance via fsck interface. > However most filesystems in 
use today, have their own native tooling for destructive recovery and 
don't need periodic maintenance calls. If you'd described this in terms 
of "preen mode", I think that it would have been clearer to other people 
what you are getting at. Dimitri John Ledkov: > At the moment stable 
debian releases configure (well partman, or partman-$foo) mountpoints in 
/etc/fstab with passno set to 1 or 2, which means run "fsck" in a 
priority order. > This leads to a following chain of events on 
filesystems that do not require periodic maintenance and only have their 
own destructive recovery tooling:


(... "that have no-op for preen mode and only have a full interactive, 
non-preen, mode of checking" ...)


Dimitri John Ledkov: > - debian-install sets passno to 1|2 > - 
initramfs-tools includes fsck.$foo scripts > - on each boot these are 
called > - $foo-progs packages ship these fsck.$foo scripts > - and said 
fsck.$foo scripts do nothing > > This is currently the case for xfs and 
btrfs, which imho is silly. > > I'm proposing to do following, for 
filesystems that require no periodic maintainance:


(... "whose fsck tools do nothing for boot-time 'preening' anyway"... )

Dimitri John Ledkov: > - d-i to set passno to 0 > - initramfs-tools to 
not include fsck.$foo tools for passno=0 mountpoints > - not spend time 
on each boot, forking shell scripts that do nothing > - $foo-progs 
packages to stop shipping dummy wrapper scripts fsck.$foo > - on upgrade 
force set passno to zero for filesystems in question > - $foo-progs 
packages to still ship initramfs-tools hooks that include/update 
initramfs with latest disaster recovery tooling (e.g. btrfs 
check/rescue, xfs_repair, e2fsck etc.)


The main thing that this is gaining you is the second bullet point: not 
spending tine forking the fsck.btrfs and xfs_fsck shell scripts that 
print messages and exit 0. Whether that's a major objective is 
debateable, but on the presumption that it is you're spending a lot of 
effort there for something that is achieved more simply.


Don't change anything with the installer or upgrade, and just replace 
the no-op fsck.$fstype scripts with symbolic links to /bin/true . 
systemd has an undocumented mechanism that checks for that, and when it 
is detected as the case both makes systemd-fsck do nothing and doesn't 
bring in the systemd-fsck@.service for the volume in the first place.


* 
http://lists.freedesktop.org/archives/systemd-devel/2014-June/020714.html * 
http://lists.freedesktop.org/archives/systemd-devel/2014-June/020737.html


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

[systemd-devel] RFC: removing initctl support

[Jonathan de Boyne Pollard]

Daniel P. Berrange:
> Maybe it wasn't actually upstart, but one of the other init systems.
> I just recall getting a patch from Debian folks to support it via
> the /run/initctl path, rather than /dev, and assumed that was upstart
> related.

It wasn't upstart or one of the other init systems.  It was the System 5 init
(clone) people deciding to move the FIFO into /run in response to a bug report
against it.  Their position, exemplified at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657990#57 , was that it was
their private non-SVID interface that they weren't expecting anyone to use
directly and that they could do that at whim. See
http://superuser.com/a/888936/38062 for more of the story.

Lennart Poettering:
> A simple fall back could be to send SIGRTMIN+4 to PID 1, if
> /dev/initctl is not around.

Daniel P. Berrange: 
> Yep, though we'd have to actually check that PID 1 is systemd, since
> if you run a container with a non-init program as PID 1, we don't
> want to be sending it SIGRTMIN+4 :-)

In an ideal world you would be able to have a routine that detected the running
system manager, and then did whatever was appropriate to that system manager to
power off, from sending signals to process #1 through running the System 5
init/rc clone's "shutdown -h -P now" command to sending requests to upstart's
Desktop Bus API.  In the real world, all of the problems that make detecting the
running system manager really difficult to do that are described at
http://unix.stackexchange.com/a/196252/5132 rear their ugly heads.  (A further
problem not mentioned there: Joachim Nilsson's finit also responds to "initctl
version".)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] What I think is really wrong with systemd

[Jonathan de Boyne Pollard]

dott...@gmail.com:

If systemd keeps going the way it does, it will eventually get forked, 
[...]




Psst!  This already happened, a year ago.   Read 
http://uselessd.darknedgy.net/ to learn what happened.



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

Re: [systemd-devel] xinetd REMOTE_IP (feature request)

[Jonathan de Boyne Pollard]

Fisher, Charles J.:


The xinetd server from previous versions of RedHat defined a REMOTE_IP 
environment variable.


Lennart Poettering:

I wonder though whether it wouldn't be nicer to follow the variable naming used 
by CGI here, and introduce $REMOTE_ADDR and $REMOTE_PORT instead of $REMOTE_IP.


Or you could implement an existing more comprehensive protocol, of long 
standing (coming up to 20 years) in the world of spawning TCP services 
on Unix and already implemented almost a decade ago in GNU inetd (and by 
some other inetds a few years later) and available right now in inetd on 
systems like Ubuntu 14 LTS:


* http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/UCSPI.html
___
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

[Jonathan de Boyne Pollard]

Lesley Kimmel:
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.   [...] It looks like I may be able to use the 
'forking' type with the 'pidfile' parameter to somewhat mimic what the 
scripts to today.


You don't do such migration.  You understand how your daemons are 
started, and you write service (and other) units to describe that. You 
do not start with the assumption that you migrate straight from one to 
the other, particularly if your existing mechanisms involve the 
dangerous and rickety things (e.g. PID files) that proper service 
management is designed to avoid in the first place, or things such as 
subsystem lock files which proper service management has no need of by 
its very nature.  Type=forking specifies a quite specific readiness 
protocol that your daemon has to enact, lest it be regarded as failed.  
It's isn't a catch-all for anything that might fork in any possible 
way.  And service managers know, by dint of simply remembering, what 
processes they started and whether they've already started them.


I've been collecting case studies of people who have migrated to systemd 
exceedingly badly, and constructed some quite horrendous systems, 
because they've done so without either consideration of, or 
understanding of, how their sytems actually work.  Here's one candidate 
that I have yet to add, because I'm hoping that now they've been told 
that they are going wrong they will correct themselves, whose errors are 
good to learn from.


There's a computer game called ARK: Survival Evolved.  It's daemon is 
a program named ShooterGameServer.  To run this program continually as a 
daemon, someone named Federico Zivolo and a couple of other unidentified 
people came up with the somewhat bizarre idea of running it under 
screen, and using screen's commands to send its pseudo-terminal an 
interrupt character, in order to send a SIGINT to the daemon when it 
came time to shut it down.  They wrapped this up in a System 5 rc 
script, taking the conventional start and stop verbs, named 
arkmanager.  Its prevent-multiple-instances system was not lock files, 
but grepping the process table.


Wrapped around this they put another System 5 rc script, named 
arkdaemon, which also took the conventional start and stop verbs, 
and which treated the wrapper arkmanager script as the daemon, 
recording the process ID of the shell interpreter for the arkmanager 
script in a PID file, as if it were the actual daemon's process ID.  It 
also did various other bad things that proper service managers 
eliminate, including grepping the process table (again), abusing su to 
drop privileges, using arbitrary 5 second sleeps to make the timing 
almost work, and (sic) hardwired ECMA-48 SGR sequences to change the 
colour of output that isn't going to a terminal in the first place.


Then they wrote a systemd service unit file, arkdeamon.service (sic), 
that did this:


 ExecStart=/etc/init.d/arkdaemon start
 ExecStop=/etc/init.d/arkdaemon stop
 Type=forking

A couple of days ago, I pointed out the errors of even starting down 
this route to them, and wrote a systemd unit file for them that actually 
starts the daemon directly from systemd; no PID files, abuses of su, 
racy grepping of the process table, abritrary sleeps, or incorrect 
forking readiness protocol necessary.  Set the account with User= ; 
set the environment with Environment= ; and run the program with 
ExecStart=/home/steam/ARK/ShooterGame/Binaries/Linux/ShooterGameServer 
plus some options.  Other stuff, like software upgrades, one then builds 
on top of the service management layer, not beneath it.  I also pointed 
out to them that I had been beaten in this regard by some 4 days by the 
(again unfortunately unidentified) people who wrote 
http://ark.gamepedia.com/Dedicated_Server_Setup#Automatic_Startup , 
whose service unit was pretty much the same as the one that I had 
independently written (as one would expect, indeed).


If you understand how your daemon is run in the first place, then you 
end up with what I and the gamepedia people did.  If you just think that 
you wrap what you already have, using forking to imperfectly paper 
over the cracks, you oftentimes end up with an utterly horrendous mess.

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

[systemd-devel] systemd-consoled: invoking login shells

[Jonathan de Boyne Pollard]

In your terminal_run_child() function you invoke the (login) shell for the
terminal as, effectively, $SHELL -il.  Don't do that.  Distributions such
as Debian have spent a fair while getting rid of bashisms from the init system
and here you are putting more of them in.  (-:

  https://wiki.debian.org/BootProcessSpeedup#Using_a_faster_system_shell

-l is not supported by the Korn shell for starters; and the irony is that you
don't need either it or -i at all.

The purpose of -i is to force a shell to think that it is interactive if it
doesn't automatically detect that it is.  Shells automatically detect that
they are interactive by looking at their standard file descriptors and using
isatty()/tcgetattr().  You're running your shells with standard input, output,
and error attached to the slave side of a pseudo-terminal.  Of course they are
going to be autodetected as interactive.  There's no need at all to use -i.

Moreover the universal protocol, that all shells support because they have to,
for telling a shell that it is a login shell is the one that is used by
login(1): prepend a dash to the value of argv[0].  So do that.  You can
probably nick the code right out of login.c from util-linux.  (Beware that it
isn't portable, because it uses PATH_MAX unconditionally, and won't work on
operating systems such as Debian Hurd where there is no maximum path length.
But you're only targetting Linux distributions and not worrying about Debian
FreeBSD, Arch Hurd, or Debian Hurd, you say.)  When invoking a login shell, you
in fact only need an argv[0] and NULL.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd-consoled: terminal hangup misconceptions

[Jonathan de Boyne Pollard]

I'll patch the comment.  The code is up to you.  (-:

--- consoled-pty-old.c 2013-12-05 12:53:24.0 +
+++ consoled-pty.c 2013-12-05 12:53:11.0 +
@@ -40,26 +40,45 @@
 #include sd-event.h

 /*
- * PTY
- * A PTY object represents a single PTY connection between a master and a
- * child. The child process is fork()ed so the caller controls what program
- * will be run.
- *
- * Programs like /bin/login tend to perform a vhangup() on their TTY
- * before running the login procedure. This also causes the pty master
- * to get a EPOLLHUP event as long as no client has the TTY opened.
- * This means, we cannot use the TTY connection as reliable way to track
- * the client. Instead, we _must_ rely on the PID of the client to track
- * them.
- * However, this has the side effect that if the client forks and the
- * parent exits, we loose them and restart the client. But this seems to
- * be the expected behavior so we implement it here.
- *
- * Unfortunately, epoll always polls for EPOLLHUP so as long as the
- * vhangup() is ongoing, we will _always_ get EPOLLHUP and cannot sleep.
- * This gets worse if the client closes the TTY but doesn't exit.
- * Therefore, the fd must be edge-triggered in the epoll-set so we
- * only get the events once they change.
+A PTY object represents a single PTY connection between a master and a child.
+The library function to create a new PTY returns after fork() rather than
+exec()ing directly itself, so the caller has control of what program will be
+run.
+
+The correct way to detect that the slave-side session has terminated is to
+detect hangup in the terminal line discipline.  The line discipline hangs up a
+terminal when all open file descriptors for the terminal have been closed, i.e.
+when all open file descriptors to the slave side of a pseudo-terminal have been
+closed.  On a true remote terminal device, the serial device control
lines would
+change causing the modem to drop carrier.  On a pseudo-terminal, this simply
+becomes a hangup condition on the master side, which can be detected by polling
+a file descriptor for the master for POLLHUP.
+
+This is partly why nohup(1) closes all open file descriptors to a terminal.  If
+it didn't, the final file descriptors would never be closed and the line
+discipline would not hang up at logout (also hence vhangup() et al.).
+
+/bin/login (the util-linux one, at least, in its init_tty() function) closes
+all open file descriptors and re-opens them, which would normally trigger the
+line discipline to hang up.  So polling whilst /bin/login is in the process of
+doing this would continually return POLLHUP and we'd either never sleep (if we
+ignored POLLHUP) or erroneously think the session to be terminated (if we
+processed POLLHUP).  We would have to bodge around it by using edge-triggered
+events in epoll(), which would have consequences for how we respond to
+POLLIN and POLLOUT.
+
+HOWEVER, /bin/login is smart enough to clear the HUPCL flag in the terminal
+attributes (see tcsetattr(3)) whilst it is closing and re-opening the
+(slave-side) terminal device.  This tells the line discipline to NOT hang up
+when the last open file descriptor is closed.  So this situation never occurs
+and we don't need to employ edge-triggering bodges to work around it.
+
+One can see that this situation never occurs by observing that running
+/bin/login on a serial device connected to a modem doesn't hang up the
+connection before one even gets a chance to log on.  (-:
+
+It's also worth noting on the gripping hand that systemd-consoled doesn't
+even invoke /bin/login anyway.
  */

 static void pty_dispatch_write(Pty *pty) {
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd-consoled: agetty+login

[Jonathan de Boyne Pollard]

The way that you're going right now, you're going to surprise a lot of
people, possibly not pleasantly, in a little while.  You've presented this as
a replacement of agetty and login.  But the use cases of getty+login and what
you're doing are somewhat different.  People expecting to get a
systemd-consoled system that behaves the same as virtual terminals with
gettys on them are going to instead get a system that operates somewhat
differently, the way that you're going.

What you're looking at doing follows the GUI model of a single greeter
session that spawns other user sessions running systemd-consoled after the
greeter has completed a login dialogue.  The TUI model of VTs+gettys, even
as modified by systemd-logind, in contrast has multiple greeter sessions that
(conceptually) exec into user sessions once /bin/login has spawned a login
shell.

In other words: What people expect from the TUI system is multiple
(systemd-logind) sessions, each with an individual login dialogue, and each of
which, serially, can comprise multiple login sessions (switch to
systemd-logind session #3, log in as user A, do things in a user A login
session, log out, log in as user B, do things in a user B login session, log
out).  What you're actually going to give them instead is one single login
dialogue in a greeter, which spawns a new (systemd-logind) session that
can only comprise a single login session.

There's nothing inherently wrong with this.  In fact I did a similar design
myself some years ago, for that non-Linux system that I mentioned.  But you
are going to surprise people who think that you're going to give them an
it-works-just-like-init+getty+login-did TUI login system.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd-consoled: architecture

[Jonathan de Boyne Pollard]

There's an adage that holds that the best design is a stolen design.  On that
basis, I recommend reading about how the Hurd console system works.

  
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/hurd-daemons.html#console
  http://gnu.org./software/hurd/hurd/console.html

The Hurd people have, as I have, already been through the process that you're
going through, although their console client daemon doesn't render to
graphics mode.

Two notes:

 * We all steal from screen(1).  Hurd has a server that maintains the
   state of multiple virtual consoles, and a client that gathers raw input
   and that displays the text contents of the console on an output device.
 * Good old conservative Hurd goes with CTRL+ALT+F1 meaning switch to
   virtual terminal #1.  Decide to go with something different, and you
   will open up a can of worms.  Or at least a can of questions from
   system administrators who ask why you didn't make the system extensible
   enough so that they could use WINKEY+L and CTRL+ALT+DEL as their
   switch to the screenlock/greeter session hotkeys.  (-:
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel