Posts made by cdutko

@sebastian-roth said in Slow Image Deployment Speeds after Updating BZImage Files:

@cdutko said in Slow Image Deployment Speeds after Updating BZImage Files:

The updated kernel seemed to only effect the performance of my previous, older spec units (https://www.advantech.com/en/products/1-2jkjm3/ppc-3100s/mod_1a0afa16-fab0-4642-aec4-504d02832d28).

Interesting piece of hardware. What kind of hard drive do you use in those?

We should really get into testing the different parts of the hardware to find out what is causing the slowness. Please schedule a debug deploy, boot it up and when you get to the console run the following command: dd if=/dev/zero of=/dev/sda bs=4G count=1 oflag=direct status=progress (depending on the drive you might need to use nvme0n1 instead of sda) - HINT: Be aware this will wipe the data off the drive!

Do this three times in a row and take a picture of the output on screen to post here.

Yeah it is a Panel PC that we use in our printing hardware.

We are using with that particular model, SQF-SMSM2-64G-SBE it is an SQF mSATA 640 64G MLC (40~85°C).

Am I supposed to run this command on a Client that I am deploying to? Sorry I am probably not using FOG in its intended way as I only register the hosts that I capture images from and none of the clients that I deploy images to ever get registered on the system.

Also would it make sense to do this with the Old Kernel? Since that is working… I’m assuming we want to run this Debug command with the new kernel that is ‘not working’ for me.

@sebastian-roth said in Slow Image Deployment Speeds after Updating BZImage Files:

@cdutko Please go back to the questions I posted in my first answer. Do you see the same slowness with every hardware? Have you tried in different models? What kind hardware are we talking about?

Have you checked on the BIOS setting VMD as mentioned before?

The spectre mitigation George mentioned is being discussed here: https://forums.fogproject.org/topic/16508/enable-or-disable-speculation_mitigations-in-the-linux-kernel (Unfortunately the test kernels are long gone.)

I was not seeing the slow speeds with the newer equipment we are imaging. They are 11th gen Intel systems.

I do not have any bios settings with respect to VMD.

The updated kernel seemed to only effect the performance of my previous, older spec units (https://www.advantech.com/en/products/1-2jkjm3/ppc-3100s/mod_1a0afa16-fab0-4642-aec4-504d02832d28).

@sebastian-roth said in Slow Image Deployment Speeds after Updating BZImage Files:

@cdutko said in Slow Image Deployment Speeds after Updating BZImage Files:

Is it possible to set this Kernel on the ‘image’ level instead? Or is Fog ‘smart’ enough to know that for all computers being deployed with this image should be associated with the Host kernel?

No and No. The kernel can only be set for hosts and/or globally.

Hmm… I guess I would have to do quick registration of the newer computers and manually associate them with the newer Kernel?

I’m honestly not really sure what my best course of action is here.

@tom-elliott said in Slow Image Deployment Speeds after Updating BZImage Files:

@cdutko and @george1421 My memory is kind of hazy and I apologize for being so out of the loop lately, but just wanted to give my memory of things a little understanding as to the potential of the issue.

As you stated George, you may remember the whole VMD configuration within the BIOS of the host machine posing a potential issue. This is most likely the culprit though I don’t fully understand what this does exactly. However, this is due to the kernel as well.

If my memory is serving correctly, at some point there was a change in the Kernel’s on how it calculates hard drive partitions which we did have a patch for at some point. Memory is a bit hazy, but it was a patch to the partclone functions because editing a kernel is pretty difficult to do (though again I could be incorrect on my memory here.)

While adjusting the parameters, it was more around Page Sizing and VMD being disabled allowed the speeds to work better. It seems (too me) that the kernel element that brought the slowness issue wasn’t/isn’t really a bug, but rather an improvement to allow the VMD capabilities to be actually used appropriately. This does cause a detriment it seems, but this is semi-intentional.

I hope this makes sense and maybe allows more proper understanding of the issue and potentially a way for us (the FOG Team) to narrow down the issue and maybe come up with a better fix than “adjust this item in your bios for every machine that has the problem”.

Of course you can also simply use the older kernel that doesn’t appear to have this issue.

@Tom-Elliott thank you for the detailed response.

My host system is quite an old build, so I don’t believe I even have those VMD settings to enable/disable even if I wanted to!

@george1421 /@Tom-Elliott what is interesting is that it does seem to be entirely related to the Kernel update causing the slower speeds. I don’t think that my old Celeron computers that I am imaging has enough horsepower to use the new/enhanced features that you guys implemented.

I reverted my bzImage files to the old Kernel that I was using ( 4.19.145) and my speeds have returned to the “FAST” speeds that I am expecting.

I need some way now to be able to use both the old Kernel for my (for lack of a better term) Legacy computers and then use the new Kernel for my Win10 11th/12th gen builds.

@george1421 said in Slow Image Deployment Speeds after Updating BZImage Files:

@cdutko said in Slow Image Deployment Speeds after Updating BZImage Files:

Does my question make sense? About associating the Kernel to an image versus a host?

FOG currently doesn’t have that capabilities. The kernel is assigned to the host and the image is assigned to the host. If there is no host record then there is nothing to link the two values to. Its missing the linking pin.

But again we haven’t confirmed that its the kernel at fault yet have we? I find its hard to believe that it IS the kernel, but anything is possible so we shouldn’t rule it out until we test it.

Other levels of debugging we can do is run a iperf test between the target computer and fog server. We can test network throughput. I also have tests for testing local hard drive (or ssd) speeds. Its possible that something is causing a slowness in writing to disk (the kernel would probably be at fault here). Right now we don’t know a lot other than it was fast at one time and now its slow.

Understood. Thank you George. I will take some time and do some testing with some different kernels and see where I end up.

I honestly think it is hardware/software related, but I am going to work through the steps to prove it today. My network setup hasn’t changed , the server itself is using a SATA SSD, so read/write speeds shouldn’t be an issue either. All cabling is CAT5e or better.

Pic of switch setup:

Pic of “station”

Power supply on the back is used to power the screens, have KVM switch for USB Mouse/keyboard for navigating Fog menu (pre deployment).

@george1421 said in Slow Image Deployment Speeds after Updating BZImage Files:

@cdutko Well we’d really like to know what changed your speed. There maybe something else (other than FOG that is causing this). So the idea is to keep everything the same except for changing the kernel to see if that has an impact. I know with the 5.15 version some vulnerability mitigation code was enabled. So its unclear of that is having a speed impact on deployment. Also partclone changing might have an impact on speed. I’m leaning towards an impact on capture speed over deployment speed, but anything is possible.

From a real world experience I would expect normal imaging, on a solid 1GbE network with contemporary hardware to run in the 5.5 to 6.3 GB/minute range. The to note is that 668MB/min is suspicious. 668MB/min == 11.13MB/sec. 100Mb networking runs at 12.5MB/sec (theoretical). It may just be a numeric anomaly but your imaging speeds might indicate there is a 100MB network link somewhere in your imaging path.

I would like to know as well. Currently I am still stuck with the slower speeds. I can send a picture of my network setup, but it is beyond simple really. The Fog Server is completely disconnected from the rest of my network, so it doesn’t get impacted by the other devices on my network. I have a 5-port unmanaged 10/100/1000 Switch that sits between the Fog server and the 1 or 2 devices we have being deployed to.

Does my question make sense? About associating the Kernel to an image versus a host?

@cdutko said in Slow Image Deployment Speeds after Updating BZImage Files:

@george1421 said in Slow Image Deployment Speeds after Updating BZImage Files:

@cdutko I’d like to see a bit more scientific results than the new kernels appear slow. My personal experience is with linux 5.5 there was a major improvement in speed over 4.19 series kernels in general linux distributions.

In my mind its not clear if your slowness is related to the kernel, the new version of partclone, target hardware, network infrastructure. Just as a point of reference on a well designed 1GbE network FOG should image at or about 6.1GB/min. Understand there can be some variances in the network design but 5.5-6.5GB/min are what I would say is normal.

I would like to devise an experiment here. You can download previous kernels from here: https://fogproject.org/kernels/ and here: https://fogproject.org/kernels/old/

What I would like to see you do is download the latest 64 bit kernel in the 4.19 series, 5.6 series, and 5.10 series. Place these files in /var/www/html/fog/service/ipxe directory. Rename the images as you place them there as bzImage4.19.x, bzImage5.6.x, bzImage5.10.x

The actual name doesn’t matter, just so they are different. Now pick a target system that is circa 2017-2018, or just old enough where the 4.19.x series kernels will run. Now go into the host definition for that target computer. Update the kernel field to bzImage4.19.x save the setting and then deploy an image to the computer. Note the speed on the partclone screen after about 1.5 minutes of deploying the c drive image. Now from the same computer on the same network port, test the 5.6 and 5.10 (you could/should test the 5.15 series kernel too, because you say is about 500Mb/min). The idea is to keep all of the variables the same and only change the kernel to see if the kernel is at fault here.

Thank you George for your detailed response. I 100% agree with you and I want to have a more scientific approach than “I changed this now speeds are bad”. There is definitely something strange going on now that I updated.

I should have some time later this week to test this out.

I’ll make sure to update you on where I end up.

I have uploaded some screenshots of my Partclone speeds.

This picture is the current speeds that I am seeing today.

The second picture is an older one from 2020 before the update. It is using a much older version of partclone.

I also found the old Kernels that I was using before I updated as well. I was using version :
bzImage32: Linux kernel x86 boot executable bzImage, version 4.19.145 (sebastian@Tollana) #1 SMP Sun Sep 13 05:43:10 CDT 2020, RO-rootFS, swap_dev 0x7, Normal VGA

So now I am at the point where I would like to try and run two different Kernels. One for my newer equipment and one for the older.

For this process, you are suggesting to modify the host hardware inventory and add the name of the specific Kernel into this menus here?

I can do some modifications just for the sake of the test, but for production rollout I typically don’t register any of the computers to the Fog server unless they are a ‘master’ PC which we use to capture the images. Is it possible to set this Kernel on the ‘image’ level instead? Or is Fog ‘smart’ enough to know that for all computers being deployed with this image should be associated with the Host kernel?

@george1421 said in Slow Image Deployment Speeds after Updating BZImage Files:

@cdutko I’d like to see a bit more scientific results than the new kernels appear slow. My personal experience is with linux 5.5 there was a major improvement in speed over 4.19 series kernels in general linux distributions.

In my mind its not clear if your slowness is related to the kernel, the new version of partclone, target hardware, network infrastructure. Just as a point of reference on a well designed 1GbE network FOG should image at or about 6.1GB/min. Understand there can be some variances in the network design but 5.5-6.5GB/min are what I would say is normal.

I would like to devise an experiment here. You can download previous kernels from here: https://fogproject.org/kernels/ and here: https://fogproject.org/kernels/old/

What I would like to see you do is download the latest 64 bit kernel in the 4.19 series, 5.6 series, and 5.10 series. Place these files in /var/www/html/fog/service/ipxe directory. Rename the images as you place them there as bzImage4.19.x, bzImage5.6.x, bzImage5.10.x

The actual name doesn’t matter, just so they are different. Now pick a target system that is circa 2017-2018, or just old enough where the 4.19.x series kernels will run. Now go into the host definition for that target computer. Update the kernel field to bzImage4.19.x save the setting and then deploy an image to the computer. Note the speed on the partclone screen after about 1.5 minutes of deploying the c drive image. Now from the same computer on the same network port, test the 5.6 and 5.10 (you could/should test the 5.15 series kernel too, because you say is about 500Mb/min). The idea is to keep all of the variables the same and only change the kernel to see if the kernel is at fault here.

Thank you George for your detailed response. I 100% agree with you and I want to have a more scientific approach than “I changed this now speeds are bad”. There is definitely something strange going on now that I updated.

I should have some time later this week to test this out.

I’ll make sure to update you on where I end up.

@sebastian-roth said in Slow Image Deployment Speeds after Updating BZImage Files:

@cdutko said:

In the past I have always seen close to 4GB transfer speeds and now we are only seeing around 500mb.

The transfer speed seen on the blue partclone screen is a combination of throughput of disk and network IO. So the plain number does not tell us which one is the bottleneck in your case.

Is it possible to have two different sets of bzimage files? One that works for the new equipment (albeit slower) and one that works with the old equipment (fast) ?

Yes it is. Set the old bzImage as default kernel in FOG Settings but apply the newer kernel through individual host settings for all the newer machines.

Or should I investigate something else entirely. I’m not really sure where to begin. I am on the latest version of fog project release, Ubuntu base.

It’s not “either/or” from my perspective. Use the different kernels now but let’s start to dig in to what is causing the slowness. First off I need to ask a few questions:

1. Which version of FOG did you use before the update and which version do you use now (lower right corner of the web UI)?
2. Which FOS kernel is currently installed (command file /var/www/{,html/}fog/service/ipxe/bzImage*)?
3. Can you see different speeds when comparing different models? Please use unicast deployments on single machines with different hardware to see if they’re all at the same slow speed or if speeds vary. I highly recommend you take notes when testing the different machines and share the stats here. It’s very hard to help finding a solution if we don’t have the details.

The forum is full of these kind of “slowness” topics and usually it’s related to specific hardware on the clients or a major issue within the network. Sure there also were issues in the FOS init/kernel at times but I am not aware of this kind of issues with the latest FOG versions (be it the official 1.5.9 release or current dev-branch version).

Here is on topic talking about a major speed impact because of a specific BIOS setting. Please check the BIOS settings on VMD: https://forums.fogproject.org/post/141675

I appreciate the detailed response. I should have the ability to test some of the things you suggested on this later this week. I’ll keep you update on the results of my test.

All,

Would anyone have a clue as to why I have seen a major performance hit after moving my FogProject’s bzimage files to the latest and greatest?

I needed to move to the newer files to be able to deploy images to some newer equipment.

In the past I have always seen close to 4GB transfer speeds and now we are only seeing around 500mb.

Is it possible to have two different sets of bzimage files? One that works for the new equipment (albeit slower) and one that works with the old equipment (fast) ?

Or should I investigate something else entirely. I’m not really sure where to begin. I am on the latest version of fog project release, Ubuntu base.

@george1421 I might give that a shot.

https://wiki.fogproject.org/wiki/index.php?title=Ubuntu_16.04

Have the installation procedures changed much since this article was written? I assume most if not all of it is the same, but I figured I would ask now rather than run into issues later.

As always thank you for your prompt response and information given.

Since 16.04 is no longer supported, I was curious if it was worth the effort to update my FOG Server from 16.04 to 20.04.

Is Fog Project still supported on the newer versions? I don’t want to break my current server. I’d rather just disconnect it from the internet permanently than update it and break the software.

@sebastian-roth Thank you for your suggestions. My team and I were able to start from scratch with a new Win10 Pro image and we captured/deployed this new revision without issues. There must have been some sort of driver or configuration issue on the actual host image that was causing this.

Thank you for helping me double check that everything in my Fog settings were properly configured.

@sebastian-roth I am using version FOG 1.5.8. I have updated the Kernel to be the latest as well. This is a 10th gen intel system, so the original Kernel for 1.5.8 did not have the correct Ethernet driver for the new motherboard.

For my host image, I have no “Host Bios EXT Type or Host EFI Exit Type” selected. The OS type is set to Windows 10 -(9), and the image type is “Single Disk Resizable”. Partition selection is “Everything”.

The compression slider is left to the default level, and the Image Manager is Partclone Gzip.

The system after deployment, will attempt to boot into windows. It fails 2 times, then boots into startup repair. Once you are in the startup repair menu, you can simply continue to Windows 10 and it works as expected.

I did some research on my own and came across the ‘sysprep’ feature. This is something that I have never done for my clients in the past and I have never seemed to have an issue. I don’t really know if it is necessary for me to do this as on my other Windows 10 images, I don’t have this issue.

All,

I am having a strange issue that I hope someone might be able to help me with. I just recently created a new fog image for a Win10 Pro pc. We have this host PC registered to the fog, and we captured the image fine. This host computer has no issues booting, restarting, or shutting down.

We have identical machines that we configure (hardware wise) and we use the host image to deploy this image to multiple PCs. Then we change the product key and re-activate windows. On the initial deployment, the fog server attempts to reboot the client that was just fog’d. On this first reboot, the system will immediately BSOD. We power down, enter the BIOS and change no settings. On the next boot, we get the startup repair screen - if you select continue to Windows it will boot without issues.

Is there something that I have configured on my host image incorrectly that is causing the new clients to fail on that first boot? Or is this strange, but expected behavior?

Any help or insight would be greatly appreciated.

@george1421 You are an absolute legend George. It works now and I was able to PXE boot from my client PC and upload it to the Hosts screen. I can view it on the network and everything is working correctly.

Thank you so much!

@george1421 Ok so I think I see what to do, but correct me if I’m wrong.

ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:0b:ab:af:09:e7 brd ff:ff:ff:ff:ff:ff inet 192.168.1.1/24 brd 192.168.1.255 scope global enp1s0 valid_lft forever preferred_lft forever inet6 fe80::908d:13ce:d900:bf02/64 scope link valid_lft forever preferred_lft forever
3: enp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 00:0b:ab:af:09:e8 brd ff:ff:ff:ff:ff:ff
4: wlp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether bc:30:7e:bc:0b:b6 brd ff:ff:ff:ff:ff:ff

192.168.1.1 is applied to enp1s0 so that is what my interface=‘__’ should be.

My original .fogsettings file gives me this:

## Start of FOG Settings
## Created by the FOG Installer
## Find more information about this file in the FOG Project wiki:
## https://wiki.fogproject.org/wiki/index.php?title=.fogsettings
## Version: 1.4.4
## Install time: Wed 12 Jul 2017 10:53:49 AM EDT
ipaddress='192.168.0.170'
copybackold='0'
interface='wlp3s0'
submask='255.255.255.0'
routeraddress=''
plainrouter=''
dnsaddress=''
username='fog'
password='7bSbm0EL2zZGqFaAfb0tW3axI5+/h7cNDi03YpMW4pk='
osid='2'
osname='Debian'
dodhcp='y'
bldhcp='1'
dhcpd='isc-dhcp-server'
blexports='1'
installtype='N'
snmysqluser='root'
snmysqlpass=''
snmysqlhost='localhost'
installlang='0'
storageLocation='/images'
fogupdateloaded=1
docroot='/var/www/html/'
webroot='/fog/'
caCreated='yes'
startrange='192.168.0.10'
endrange='192.168.0.254'
bootfilename='undionly.kpxe'
packages='apache2 bc build-essential cpp curl g++ gawk gcc gzip htmldoc isc-dhc$
noTftpBuild=''
notpxedefaultfile=''
sslpath='/opt/fog/snapins/ssl/'
backupPath='/home/'
php_ver='7.1'
php_verAdds='-7.1'
sslprivkey='/opt/fog/snapins/ssl//.srvprivate.key'
## End of FOG Settings

However if I wish to correct my problems with the adapter and my DHCP range my .fogsettings file should read:

## Start of FOG Settings
## Created by the FOG Installer
## Find more information about this file in the FOG Project wiki:
## https://wiki.fogproject.org/wiki/index.php?title=.fogsettings
## Version: 1.4.4
## Install time: Wed 12 Jul 2017 10:53:49 AM EDT
ipaddress='192.168.1.1'
copybackold='0'
interface='enp1s0'
 ...
startrange='192.168.1.10'
endrange='192.168.1.254'
 ...
## End of FOG Settings

Is this correct?

Also, I would like to thank you in advance for assisting me with all of this.

@george1421 Ok.

So what would my “interface” be considered in this case? ETH0?

& How would I fix that subnet issue. I don’t plan on using a router for this setup.

@george1421 wlp3s0 I believe is a wireless adapter. I originally was connected to the internet via WLAN and that is how the server was originally configured. Is there a way for me to switch that to a wired network adapter?

Here is the contents of that file.

# DHCP Server Configuration file\n#see /usr/share/doc/dhcp*/dhcpd.conf.sample
# This file was created by FOG
#Definition of PXE-specific options
# Code 1: Multicast IP Address of bootfile
# Code 2: UDP Port that client should monitor for MTFTP Responses
# Code 3: UDP Port that MTFTP servers are using to listen for MTFTP requests
# Code 4: Number of seconds a client must listen for activity before trying
# to start a new MTFTP transfer
# Code 5: Number of seconds a client must listen before trying to restart
# a MTFTP transfer
option space PXE;
option PXE.mtftp-ip code 1 = ip-address;
option PXE.mtftp-cport code 2 = unsigned integer 16;
option PXE.mtftp-sport code 3 = unsigned integer 16;
option PXE.mtftp-tmout code 4 = unsigned integer 8;
option PXE.mtftp-delay code 5 = unsigned integer 8;
option arch code 93 = unsigned integer 16;
use-host-decl-names on;
ddns-update-style interim;
option space PXE;
option PXE.mtftp-ip code 1 = ip-address;
option PXE.mtftp-cport code 2 = unsigned integer 16;
option PXE.mtftp-sport code 3 = unsigned integer 16;
option PXE.mtftp-tmout code 4 = unsigned integer 8;
option PXE.mtftp-delay code 5 = unsigned integer 8;
option arch code 93 = unsigned integer 16;
use-host-decl-names on;
ddns-update-style interim;
ignore client-updates;
# Specify subnet of ether device you do NOT want service.
# For systems with two or more ethernet devices.
# subnet 136.165.0.0 netmask 255.255.0.0 {}
subnet 192.168.0.0 netmask 255.255.255.0{ option subnet-mask 255.255.255.0; range dynamic-bootp 192.168.0.10 192.168.0.254; default-lease-time 21600; max-lease-time 43200; #option routers 0.0.0.0
next-server 192.168.0.170; class "Legacy" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:$ filename "undionly.kkpxe"; } class "UEFI-32-2" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:$ filename "i386-efi/ipxe.efi"; }
class "UEFI-32-1" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:$ filename "i386-efi/ipxe.efi"; } class "UEFI-64-1" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:$ filename "ipxe.efi"; } class "UEFI-64-2" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:$ filename "ipxe.efi"; } class "UEFI-64-3" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:$ filename "ipxe.efi"; } class "SURFACE-PRO-4" { match if substring(option vendor-class-identifier, 0, 32) = "PXEClient:$ filename "ipxe7156.efi"; }
class "Apple-Intel-Netboot" { match if substring(option vendor-class-identifier, 0, 14) = "AAPLBSDPC/$ option dhcp-parameter-request-list 1,3,17,43,60; if (option dhcp-message-type = 8) { option vendor-class-identifier "AAPLBSDPC"; if (substring(option vendor-encapsulated-options, 0, 3) = 01:01:01)$ # BSDP List option vendor-encapsulated-options 01:01:01:04:02:80:00:07:04:8$ filename "ipxe.efi"; }}

@george1421 Alright, so I ran both of those commands. I’m not really sure how to interpret them though.

netstat -an|grep 67 results:

netstat -an|grep 67
udp 0 0 0.0.0.0:67 0.0.0.0:*
unix 3 [ ] STREAM CONNECTED 25673 @/tmp/.X11-unix/X0
unix 3 [ ] STREAM CONNECTED 26753 @/tmp/dbus-PzeIwiOksF
unix 3 [ ] STREAM CONNECTED 24267 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 26752
unix 3 [ ] STREAM CONNECTED 22867
unix 3 [ ] STREAM CONNECTED 26785
unix 2 [ ] DGRAM 26067
unix 3 [ ] STREAM CONNECTED 26755
unix 3 [ ] STREAM CONNECTED 26756 @/tmp/dbus-PzeIwiOksF
unix 3 [ ] STREAM CONNECTED 26710
unix 3 [ ] STREAM CONNECTED 26735 @/tmp/dbus-PzeIwiOksF
unix 3 [ ] STREAM CONNECTED 26744
unix 3 [ ] STREAM CONNECTED 29967
unix 3 [ ] STREAM CONNECTED 26745 @/tmp/dbus-PzeIwiOksF
unix 3 [ ] STREAM CONNECTED 26751 @/tmp/dbus-PzeIwiOksF
unix 3 [ ] STREAM CONNECTED 26718
unix 3 [ ] STREAM CONNECTED 24967 @/tmp/dbus-PzeIwiOksF
unix 3 [ ] STREAM CONNECTED 26717
unix 3 [ ] STREAM CONNECTED 26567 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 23867
unix 3 [ ] STREAM CONNECTED 26714

ps aux|grep dhcp results:

ps aux|grep dhcp
dhcpd 2167 0.0 0.3 35488 13180 ? Ss 14:06 0:00 dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf
fogserv+ 2932 0.0 0.0 14236 1016 pts/2 S+ 14:10 0:00 grep --color=auto dhcp